The Stripe Issuing API is one of 57 APIs that Stripe publishes on the APIs.io network, and it does one specific, high-stakes thing: it lets businesses instantly create, manage, and distribute payment cards. Where most of Stripe’s surface is about accepting money, Issuing is about handing out the instruments that spend it.
Operations and artifacts
The catalog indexes three artifacts for this API in its properties: Documentation, an OpenAPI specification, and an Overlay. The OpenAPI contract is the substance. It defines the resource families you would expect from a card program:
- Cardholders — create, retrieve, update, and list the individuals or companies a card is issued to, filterable by status (
active,inactive,blocked) and type (individualorcompany). - Cards — create and manage
Cardobjects, filterable by cardholder, expiration, last four digits, status, and type (virtualorphysical). - Authorizations — list and retrieve
Authorizationobjects, and respond to them in the real-time authorization flow.
Tagged areas on the network are Cards and Issuing.
One sharp observation
The most revealing detail in the contract is what Stripe has deprecated. The Issuing API still documents POST /v1/issuing/authorizations/{authorization}/approve and /decline endpoints — but both are marked deprecated, with the spec explicitly steering you to respond directly to the webhook request instead. That is a meaningful design shift: real-time card authorization has moved off request/response polling and onto webhook-driven handling, where your endpoint decides to approve or decline inside the timeout window. If you integrate against the deprecated endpoints, you are building on a path Stripe is walking away from.
The security model is stated in the spec: the API accepts basicAuth or bearerAuth, the standard Stripe secret-key pattern. And these are genuinely mutating operations — creating a cardholder and issuing a card are POST calls with required: true request bodies that spin up real financial objects, complete with spending controls passed as deep-object parameters. This is not a read-only reporting API. It provisions the ability to spend money.
Takeaway
Stripe Issuing is a clean example of a contract that tells you how to build correctly and how not to: real card objects, real cardholders, spending controls as first-class parameters, and a deliberate move from deprecated approve/decline endpoints to webhook-based authorization handling. Read the OpenAPI and Overlay artifacts before you write a line of integration code, and see where it sits alongside Stripe’s other 56 APIs at apis.io/providers/stripe.