Skip to main content
Cards add two webhook event types on top of Grid’s existing webhook infrastructure. Signature verification (X-Grid-Signature) and retry behavior are identical to the rest of Grid — see Authentication and Webhooks for the underlying mechanics. Card-transaction lifecycle events are not card-specific webhooks — they ride on the generic transaction webhook stream (a follow-up extends the Transaction model with a card destination type).

Event types

All card webhooks carry the standard envelope:
The id is unique per delivery and safe to use for idempotency.

CARD.STATE_CHANGE

The data payload is the post-change Card resource. Example — activation after issuance:
Common branches to handle in your consumer:
  • state: "ACTIVE" after PROCESSING — the card is live. To reveal the full card details, request a reveal with POST /cards/{id}/reveal right before rendering its short-lived panEmbedUrl in an iframe — webhook payloads never carry a reveal URL.
  • state: "CLOSED", stateReason: "ISSUER_REJECTED" — the issuer rejected provisioning; offer to issue a new card.
  • state: "FROZEN" / state: "ACTIVE" — reflect the freeze toggle in your UI.
  • state: "CLOSED", stateReason: "CLOSED_BY_PLATFORM" — close confirmed; stop showing the card.

CARD.FUNDING_SOURCE_CHANGE

Fires whenever a PATCH /cards/{id} call changes the fundingSources array. The data payload is the full Card resource with the post-change fundingSources, so a consumer that only cares about the current set of bindings can replace state wholesale.

CARD_TRANSACTION.*

Card-transaction lifecycle events fire on every state transition of a CardTransaction. The data payload is the full CardTransaction resource after the transition. See Reconciliation for the underlying event model and the over-auth and exception paths.

Idempotency & retries

Webhook deliveries are at-least-once. Track processed id values and return 200 on duplicates, or return 409 and let Grid stop retrying. Both shapes are accepted by Grid’s webhook infrastructure.