generated: '2026-08-12' method: searched source: - https://docs.cardlytics.com/ads/v2/developer-tools/notifications-webhook.html - https://docs.cardlytics.com/ads/v2/developer-tools/rtm.html - https://docs.cardlytics.com/poweredby/api-reference-notify-transaction.html - https://docs.cardlytics.com/poweredby/api-reference-notify-reward.html - https://docs.cardlytics.com/poweredby/api-reference-notify-enrollment.html - https://docs.cardlytics.com/poweredby/api-reference-notify-transaction-ach.html spec_type: Webhooks asyncapi: false asyncapi_note: >- Cardlytics publishes NO AsyncAPI document. Searched the developer hub (platform.cardlytics.com, both child projects), the legacy docs snapshot (docs.cardlytics.com), /asyncapi.yaml and /asyncapi.json on every host, and there is no public GitHub organization to search. The event surface below is documented in prose only. Nothing here is fabricated — it is transcribed from the provider's own webhook and real-time-messaging pages. summary: >- Cardlytics has a genuine event surface, but it is inverted relative to most API providers: Cardlytics does not host webhook subscriptions. The PARTNER builds and hosts an endpoint, and Cardlytics posts to it. Endpoint URLs are configured out-of-band with an implementation consultant — there is no self-service subscription API, no signing-secret rotation endpoint, no delivery-retry policy, and no replay or dead-letter surface published. direction: cardlytics -> partner (provider-initiated, partner-hosted receiver) delivery: transport: HTTPS POST, application/json configuration: >- Out-of-band. "Contact your designated Cardlytics implementation consultant" to have events routed to your endpoint. authentication: scheme: HS256 JWT bearer detail: >- Powered by Cardlytics webhooks are authenticated with an Authorization Bearer JWT signed with the shared secretKey, where sub is the hex-encoded MD5 digest of the JSON request body and exp is at most 60 minutes out. Each configured webhook gets its own applicationId. source: https://docs.cardlytics.com/poweredby/api-reference-authentication.html retries: documented: false signature_header: documented: false note: Body integrity is bound into the JWT sub claim rather than a separate signature header. status_codes: Standard HTTP; receivers are expected to honor the same code table as the REST APIs. channels: - name: publisher-notification-webhook description: >- Redemption close-the-loop and activity-based notifications. Cardlytics ingests authorization data through the Transaction API, matches it to a merchant and one or more valid offers, determines the qualifying event, and posts the result to the publisher-managed webhook so the publisher can message the customer. payload_fields: - {field: transactionIdentifier, type: string, description: Unique id for the authorization transaction record. Must not be the account number.} - {field: transactionType, type: integer, description: '0 = Auth, 1 = Cleared'} - {field: externalAccountIdentifier, type: string(120), description: Unique id for the account. Must not be the account number.} - {field: notificationType, type: EventType, description: Type of notification} - {field: merchantName, type: string(350), description: Transaction description as it appears on the customer statement.} - {field: brandingURL, type: string, description: Name of the merchant logo associated with an offer.} - {field: brandingURLFileTypeName, type: string(4), description: File extension of the offer logo.} - {field: sourceCustomerID, type: string, description: Unique id for the customer. Must not be the account number.} caveat: >- The sourceAccountId Cardlytics returns is the id received during transaction import, which is not necessarily the account id used elsewhere in publisher systems. source: https://docs.cardlytics.com/ads/v2/developer-tools/notifications-webhook.html - name: real-time-messaging description: >- Real-Time Messaging (RTM) posts certain platform events to a publisher-hosted endpoint as soon as they become available, to drive marketing workflows. events: - name: Redemption Notification example_event_type: REDEMPTION_CONFIRMED payload_fields: - {field: event, type: RealtimeMessagingEventType, description: Type of RTM event} - {field: eventId, type: string, description: Unique uuid for the RTM event} - {field: eventTimestamp, type: string, description: ISO 8601 timestamp of the redemption event} - {field: redemptions, type: 'Redemption[]', description: List of redemptions} redemption_fields: - redemptionId - adId - amount - redemptionDate - sourceCustomerId - sourceAccountId - redeemingTransactionAmount - transactionId - rewardSettlementRunDate enumeration_reference: https://docs.cardlytics.com/ads/v2/objects/enumerations/realtime-messaging-event-type.html source: https://docs.cardlytics.com/ads/v2/developer-tools/rtm.html - name: powered-by-notify-endpoints description: >- The Powered by Cardlytics marketplace integration defines a matching set of partner-hosted notify endpoints Cardlytics calls. endpoints: - {name: notify-transaction, source: https://docs.cardlytics.com/poweredby/api-reference-notify-transaction.html} - {name: notify-transaction-ach, source: https://docs.cardlytics.com/poweredby/api-reference-notify-transaction-ach.html} - {name: notify-reward, source: https://docs.cardlytics.com/poweredby/api-reference-notify-reward.html} - {name: notify-enrollment, source: https://docs.cardlytics.com/poweredby/api-reference-notify-enrollment.html} - {name: sandbox-notify-transactions, source: https://docs.cardlytics.com/poweredby/api-reference-sandbox-notify-transactions.html} - {name: test-sandbox-notify-reward, source: https://docs.cardlytics.com/poweredby/api-reference-test-sandbox-notify-reward.html} - {name: test-sandbox-notify-enrollment, source: https://docs.cardlytics.com/poweredby/api-reference-test-sandbox-notify-enrollment.html} - name: client-events description: >- The inbound complement to the outbound events: publishers POST customer activity (impressions, offer activation, redemption-history browsing) back to Cardlytics through the Events API so the platform can model interactions. direction: partner -> cardlytics enumeration_reference: https://docs.cardlytics.com/ads/v2/objects/enumerations/client-event-type.html source: https://docs.cardlytics.com/ads/v2/api/data/post-customer-event.html gaps: - No AsyncAPI, no event schema registry, and no machine-readable event catalog. - No published subscription/registration API; endpoints are configured by a human. - No documented retry, backoff, replay or dead-letter behavior for failed deliveries. - Event type enumerations are documented on the legacy docs host only.