Architecture
Pre-Built Connector Directory
The platform connects to loyalty, identity, retargeting, retail media, commerce, digital wallet and voice-of-customer platforms. Some are natively supported, pre-built connectors; others are integrated via the general-purpose API or the Partner Integration Framework. This brief sets out which is which, so integration effort can be scoped accurately.
This page answers
- Which platforms have a native connector today?
- What does an API or PIF integration involve?
- How is Yahoo integrated?
- How are Apple Wallet and Google Wallet supported?
Two paths, both supported
A pre-built connector and an API integration both result in working, supported integrations; the difference is setup effort and maintenance, not whether the integration is possible. A native connector is pre-configured and off the shelf; an API or PIF integration is built against the general-purpose integration surface, tailored to the partner's endpoints and data model.
Connector status directory
| Platform | Category | Integration path |
|---|---|---|
| Criteo | Retargeting | Native, pre-built connector |
| Eagle Eye | Loyalty / offer management | Native, pre-built connector |
| LiveRamp | Identity | API / PIF integration |
| Zitcha | Retail media network | API / PIF integration |
| Salesforce | E-commerce | API / PIF integration |
| Adobe Target / Analytics | Personalization / analytics | API / PIF integration |
| Medallia | Voice of customer | API / PIF integration |
| Yahoo | Media / audience activation | API / PIF integration |
| Apple Wallet / Google Wallet | Digital wallet passes | API / PIF integration |
Two ready today, seven by scoped build
Of the nine platforms listed, Criteo and Eagle Eye are ready-made connectors today. The remaining seven are supported through the API or the Partner Integration Framework, a supported and proven path, but one that requires a scoped build rather than a toggle-on setup.
What an API or PIF integration means in practice
- Data governance and user data APIs: send and receive attributes, events, identifiers and consent status to and from the partner platform.
- Webhook and call-an-API steps in journeys: trigger outbound calls to a partner's endpoint from a journey, or receive inbound events in real time.
- Analytics APIs: retrieve or send campaign and engagement performance data for cross-platform reporting.
- Once built, an API integration behaves downstream like a native connector: the data is available for segmentation, journey triggers and reporting through the same surfaces marketers already use.
Yahoo
Yahoo is integrated via API rather than a native connector: audience data and campaign events are exchanged through the data governance and analytics APIs, following the pattern of the other media and audience-activation partners. Exact fields, direction and refresh frequency are scoped against the specific Yahoo product surface involved, audience export or conversion feedback.
Digital wallet passes
- Connected partnerThe pass provider issuesThe provider or in-house pass service the customer uses for Apple Wallet and Google Wallet issuance.
- PlatformPass creation is triggeredThrough the integration, using customer and loyalty attributes already held in the platform.
- PlatformPass fields are pushedBalance, membership tier or receipt details are updated through the integration.
- Connected partnerPass-side events returnEvents from the pass are received back into the platform.
- PlatformPreferences propagateAn opt-out recorded in email, SMS or the app suppresses promotional wallet push through the integration.
- PlatformUtility updates are preservedBalances, receipts and tier status are classified separately from promotional push, so suppression does not disable them.
How wallet passes are supported
| Capability | How it is supported |
|---|---|
| Pass creation | Triggered via the integration, using customer and loyalty attributes already held in the platform. |
| Bi-directional updates | Pass field updates (balance, tier, receipt) pushed out; pass-side events received back. |
| Preference propagation to promotional push | An opt-out or preference change in a core channel can suppress promotional wallet push notifications. |
| Utility services preserved | Utility content is classified separately from promotional push; suppressing promotions does not remove functional pass updates. |
Before you start
- Pass provider or service: identify the provider or in-house service used or planned for Apple Wallet and Google Wallet issuance.
- Data and update direction: which pass fields need updating, which data the platform sends, which pass-side events it receives.
- Preference mapping: how preference changes in email, SMS or the app affect promotional wallet push, keeping promotional preferences separate from functional pass updates.
- Scope the data exchanged, the direction and the expected latency with the implementation team ahead of go-live, so effort is estimated rather than assumed equal to a native connector's setup time.
In TemasCRM
Every claim is compared with this product: what is live, what is partial, what is planned and what is not applicable by this product's design.
2 Live3 Planned
- An integrations screen with keys and requestsLive
The integrations screen lists API keys, mints new ones and records integration requests through the API's own routes; its Webhooks section stores the https endpoints that receive the one signed outbound event, lead.created, which carries the lead's id and nothing of the person.
Integrations - Data governance and user data APIsLive
Leads, profiles, consents and sends are readable and writable through the API with a workspace-scoped key; the send history and the consent ledger are the same records a partner would read.
- Webhook and call-an-API steps in journeysPlanned
Journeys are read-only here and have no outbound call step; the scheduler itself is off by the filed default. The one outbound webhook, lead.created, follows the lead form route and a Meta lead forms sync and is not a journey step.
- Native connectors such as Criteo and Eagle EyePlanned
None of the nine named platforms has a connector in this product; an integration request records the need. Four connectors are built, three of Shopify's and Meta lead forms, each reading a source the workspace itself connected. Of the Shopify ones: the catalogue connector reads a shop's products and nothing of a person; the customers connector brings its customers in as profiles, four fields each (the two names, the e-mail address and the phone number), writes no consent, and keeps a keyed-hash link per customer so a person erased here is not brought back by the next sync; the orders connector writes the shop's orders of the last sixty days as purchases on the profiles that link points to, reading of a buyer the customer's id and nothing else, no name, address or payment detail, and puts nothing new on a person erased here. None of the three writes anything to the shop, and no personal data is sent to Shopify. The Meta lead forms connector, offered only to a commercial workspace that holds the capability marketing.leadAds, reads the leads of a Facebook page's lead forms with a Page access token the administrator pasted: it makes Meta a source of the names, e-mail addresses and phone numbers of the people who filled a form, keeps five answers of each and stores none of the others, keeps Meta's lead id only as a keyed hash, writes each lead on the person's profile with no consent recorded from the form, does not bring back a person erased here, and sends nothing of a person to Meta.
- Apple Wallet and Google Wallet passesPlanned
No pass provider is connected; the service versus commercial classification that would govern wallet push already exists on templates.