Cardlytics Publisher Webhooks

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.