Overview

A packaged integration is a campaign whose component tree connects Extole to an outside system. Extole supports four categories, and the category decides the component model, the resources the integration needs, and which build sequence to follow in Build a Packaged Integration with the Management API.

This page is for packaging a partner platform as a reusable integration. Launching a program does not require it — see Who Packages an Integration for the paths that connect your own systems, and Build with Extole AI Tools for the recommended way to run a build.

When You Would Choose Each Category

Read the platform’s developer documentation and its partner page, when one exists. These signals place a platform quickly:

Signal	Category
The platform documents webhooks, plugins, or extensions that post order or account activity, or the request describes a lifecycle to track — purchases, shipments, cancellations, account openings	Inbound
The platform documents an ingestion API for customer events, attributes, or subscriptions, or the request describes triggering messages, building audiences, or enriching profiles from Extole activity	Outbound
The request describes the platform deciding who is eligible and sending that membership to Extole	Inbound, as audience membership rather than events
The platform sells gift cards, prepaid cards, points, or payouts that Extole orders when a reward is earned, or the request names card products, denominations, program numbers, or funding terms	Reward fulfillment
The platform both sends activity and receives rewards or coupons	Bidirectional
A maintained integration component already exists for the platform in the duplicatable listing	Library install of that source’s category, unless the request adds inbound scope
The request is a CSV, SFTP, or inbound event-file feed, or to create a file integration	Not this guide — install the File Integration extension

A request can match more than one row. A maintained library source covers only what it was built for; when the request includes something the source does not — inbound membership on an otherwise outbound partner, for example — install the source and build the rest on top of it.

Category Summary

Category	Direction	Platform types	What you create
Inbound	Platform to Extole	Commerce, core banking, account opening, subscription, point of sale	Business events, trigger rules, and data capture, in a campaign built from the custom integration template
Outbound	Extole to platform	Marketing automation, messaging, customer data platforms, analytics	A reshaped duplicate of the maintained library source, with webhooks and a credential
Reward fulfillment	Extole to platform	Gift card, prepaid card, points, and payout providers	A supplier type, a support campaign of supplier templates, `REWARD` webhooks, and a fourth view
Bidirectional	Both	Commerce and loyalty platforms that also accept rewards or coupons	The inbound model first, then outbound resources gated on an approved use case

Inbound needs no reward supplier, webhook, or client key, unless it receives audience membership from the partner. Outbound needs no business events. Every category carries the same three views — configuration, report-runner, and event-stream — built from Add the Activity and Event Views. The category decides what the report counts and what the feed filters to; reward fulfillment adds a fourth.

Inbound Integrations

An inbound integration turns a platform’s own event names into canonical Extole business events, mapping each arriving event to a reusable business-event component. Send Platform Events to Extole covers the sending half that runs in the platform. The component tree is the same whichever way events reach it:

A platform with an extension or plugin you can write sends Extole-shaped events directly.
A platform that emits only its own fixed webhook — a payment processor, or a SaaS product with a webhook page and no plugin — needs a prehandler to reshape the payload inside Extole.
Incoming CSV or SFTP event files are not this tree. Install File Integration.

root
└── integration                 integration-v10.x
    ├── partner configuration settings
    ├── businessEvents          MULTI_SOCKET → business-event-v10.0
    │   └── canonical event
    │       ├── triggerRules    → input_event rule carrying the event names that reach it
    │       └── data            → one component per captured field
    └── views                   MULTI_SOCKET → view-v10.0
        ├── configuration       config-view-v10.0
        ├── report-runner-view  report-runner-view-v10.0
        └── event-streams       event-stream-view-v10.0

Keep the two event vocabularies separate. The trigger rule carries the name that reaches it: the platform’s wire event name, or the integration-owned name a prehandler produced. The business event carries the canonical name bundled programs already use — converted, shipped, canceled, account_opened. Never rename a business event to match a platform’s wire name. Map every field you persist into the data socket. Map Inbound Partner Events covers the mapping.

Audience Membership from a Partner

A partner platform that decides which customers are eligible can sync that group to an Extole audience over the API. This is inbound, but it carries no business events and is the one inbound shape that needs a credential. It is distinct from an audience Extole builds out of program activity. The integration adds an audience it owns, a server access token the partner authenticates with, and setup instructions naming the endpoints. See Receive Audience Membership from a Partner.

Outbound Integrations

An outbound integration forwards Extole program activity to the platform. Child controllers listen for Extole events and call the platform’s endpoints through webhooks, authenticated with a webhook client key that holds the platform’s API credential.

root
└── integration                 integration-v10.x
    ├── one child per forwarded Extole event
    ├── data-item template      partner data component type (when marketing campaigns attach partner actions)
    └── views                   MULTI_SOCKET → configuration, report-runner, event-stream views

Most outbound platforms ship as maintained library sources an account can duplicate — the same action the Install button performs on the Partners page. Reshape the install against the partner page’s product description, which specifies the children, the webhooks, and any typed data template. The integration component holds a WEBHOOK_ID setting per webhook, resolved by the webhook’s purpose tag, and marketing campaigns attach partner actions through those settings. Build an Outbound Library Integration covers the reshape. An outbound integration reports program activity rather than producing it, so installing one never supersedes a marketing program’s own converted or shipped business event.

Reward Fulfillment Integrations

A reward fulfillment integration orders something of value from the platform when a participant earns a reward: a gift card, a prepaid card, points, or a payout. Extole calls the platform’s order endpoint, the platform returns an order result, and the reward moves to fulfilled or fails and is retried. The direction is outbound, and the model is distinct because the platform sells products. Each product a client can offer becomes a reward supplier — a configured source of rewards carrying its own value, program identifiers, and payment terms. A client offering two card types has two reward suppliers drawn from the same integration. That takes two campaigns:

integration campaign
└── integration                 integration-v10.x
    ├── credential and account settings
    ├── rewardSuppliers         MULTI_SOCKET → the partner's own supplier type
    ├── views                   MULTI_SOCKET → config, report-runner, event-stream views
    │   ├── configuration       credential and account settings
    │   ├── reward suppliers    surfaces the rewardSuppliers socket
    │   ├── reward activity     report-runner-view-v10.0
    │   └── reward events       event-stream-view-v10.0
    └── one REWARD webhook per order endpoint, plus a status check

support campaign                CONFIGURATION
└── one supplier template per product variant
    └── a reward supplier element tagged with its product variant

Supplier templates live in the support campaign, of type CONFIGURATION, because a client installs them repeatedly and each install is its own configured supplier. The rewardSuppliers socket accepts only this partner’s own supplier type, and the fourth view surfaces that socket, reporting itself incomplete while no supplier exists. Build a Reward Fulfillment Integration covers the supplier type, the templates, and the REWARD webhooks.

Bidirectional Integrations

A platform that both sends outcomes and receives rewards or coupons combines both models. Build the inbound half first and prove it, then add outbound resources once the destination endpoint, authentication contract, retry and idempotency behavior, configuration surface, and a program action that produces the outbound event all exist.

Integration Overview

Extole AI Tools

Platform Integrations

Partners

Building Packaged Integrations

Solutions

Operational Tasks

Troubleshooting

Integration Categories

Overview

When You Would Choose Each Category

Category Summary

Inbound Integrations

Audience Membership from a Partner

Outbound Integrations

Reward Fulfillment Integrations

Bidirectional Integrations

​Overview

​When You Would Choose Each Category

​Category Summary

​Inbound Integrations

​Audience Membership from a Partner

​Outbound Integrations

​Reward Fulfillment Integrations

​Bidirectional Integrations

​Related Documentation

Overview

When You Would Choose Each Category

Category Summary

Inbound Integrations

Audience Membership from a Partner

Outbound Integrations

Reward Fulfillment Integrations

Bidirectional Integrations

Related Documentation