Skip to main content
All validation failures on the Cards API are returned synchronously. Business logic errors are returned as 422 responses with an invalid_parameters array that identifies which fields failed and why, so you can correct the request before retrying.
Every mutating request (POST, PATCH, and the action endpoints) requires an Idempotency-Key header. Omitting it returns 400 operation_not_allowed (reason: parameter "Idempotency-Key" in header has an error: value is required but missing). A request body that is not valid JSON returns 400 bad_request with The request body contains malformed JSON.

POST /v0/cards

Creates a card. The card is always created in active status.

Required Fields

Field Validations

Reference Validations

Creating a card against a closed account is rejected with 400 operation_not_allowed (title “This operation cannot be done on this object.”) rather than a 422, because it is an operation that cannot be performed on the object.

GET /v0/cards/{id}

Retrieves a card by its server-generated ID.

GET /v0/cards?client_card_id={client_card_id}

Retrieves a card by the client-provided client_card_id (for cards created via file ingestion).

PATCH /v0/cards/{id}

Partial update. Only details.card_product_name and metadata are mutable.
Unlike a create, non-mutable fields sent on a PATCH are ignored rather than rejected (consistent with the Accounts API). A PATCH that changes nothing (empty body, or only non-mutable fields) returns 200 without bumping updated_at.
The status of a card is system-managed and changes only through the three action endpoints below (each takes an Idempotency-Key header):

POST /v0/cards/{id}/activate

Reactivating a closed card clears its closed_at and status_reason.

POST /v0/cards/{id}/deactivate

Deactivating a closed card clears its closed_at and sets the new status_reason.

POST /v0/cards/{id}/close

Authentication

Authentication and scope are enforced at the gateway.