canonical: https://jentic.com/apis/aptopayments.com/aptopayments

# Apto Payments Card Issuance API

Jentic publishes the only available OpenAPI specification for Apto Payments Card Issuance API, keeping it validated and agent-ready. Apto Payments is a card-issuing platform that lets fintechs and embedded-finance products issue branded debit and prepaid cards to end users. The API exposes endpoints for managing cardholders, issuing and activating cards, and listing card transactions. It uses bearer-token authentication and is structured around three primary resources: cardholders, cards, and transactions.

## For AI agents

Create cardholders, issue cards, activate them, and read transaction history for an Apto Payments programme.

## Scope

Does not handle merchant payment acceptance, KYC verification, or treasury accounts - use for cardholder and card issuance management only.

## Capabilities

- Register a new cardholder with KYC details for an issuance programme
- Issue a debit or prepaid card linked to an existing cardholder
- Activate a freshly issued card so it can be used for transactions
- Retrieve cardholder records and card details by ID for support flows
- List the transactions posted against a specific card for reconciliation

## Use cases

### Issue Cards to New Cardholders

Onboard a new user, create their cardholder record, then issue a card linked to that record so they can start spending. Embedded-finance products use this to bundle a payment card into a broader product experience without becoming a card issuer themselves. Apto handles the network, BIN sponsor, and compliance plumbing in the background.

Example prompt: Create a cardholder via POST /cardholders with the user's KYC fields, then call POST /cards with that cardholder_id to issue a card and return the card_id.

### Activate Cards Post-Delivery

When a physical card arrives at the cardholder's address, mark it active so the card network will authorise transactions. Issuance products use this as the trigger for activation flows in a mobile app or IVR. Apto's POST `/cards/{card_id}/activate` endpoint is the single call that flips the card from issued to live.

Example prompt: Call POST `/cards/{card_id}/activate` for the card the user has confirmed they received, then verify the activation succeeded.

### Transaction History for Customer Support

When a cardholder calls support about a charge, look up the transactions on their card to confirm what posted, when, and from which merchant. Support agents and chatbots use this to triage disputes and refunds before escalating. The list-transactions endpoint returns the transaction stream for a specific card.

Example prompt: Call GET `/cards/{card_id}/transactions` to retrieve the transaction list for the card and return the most recent 10 entries.

### AI Agent Card Issuance via Jentic

An onboarding agent that creates a fintech account end-to-end can call Apto through Jentic to issue and activate a card without the developer wiring up the bearer-token flow. The agent searches for the issuance operation, loads the schema, and executes the create-cardholder and create-card calls in sequence. Jentic resolves the bearer token from its credential vault.

Example prompt: Use Jentic search 'issue a debit card to a new cardholder', load the schemas for POST /cardholders and POST /cards, then execute both calls and return the new card_id.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/cardholders` | Create a new cardholder |
| GET | `/cardholders` | List cardholders |
| GET | `/cardholders/{cardholder_id}` | Get a cardholder by ID |
| POST | `/cards` | Issue a card |
| GET | `/cards/{card_id}` | Get card details |
| POST | `/cards/{card_id}/activate` | Activate a card |
| GET | `/cards/{card_id}/transactions` | List transactions for a card |

## Key resources

- **Cardholders** — Create, list, and fetch cardholder records that own one or more issued cards
- **Cards** — Issue cards to existing cardholders, fetch card details, and activate cards
- **Transactions** — List the transactions posted against a specific card

## Why Jentic

- **Setup:** Wiring Apto Payments by hand means learning its bearer auth and threading cardholder and card ids through its issuance paths yourself. Through Jentic you install once, import the Apto Payments Card Issuance API from the API Directory, store the token once, and your agent calls it.
- **Permission scoping:** Apto puts cardholder and card ids in the URL path (`/cardholders/{cardholder_id}`, `/cards/{card_id}`), so a rule can pin your agent to a specific card: it can read that card and its transactions. You choose the operations it may call, so state changes like activating a card are not included unless you add them.
- **Credential handling:** Your Apto Payments bearer token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'issue a debit card to a new cardholder', and Jentic returns the matching Apto operation with its input schema so the agent calls the right endpoint without browsing docs.

## Related APIs

- **Stripe API** — Stripe Issuing offers card issuance alongside payments, accounts, and treasury - broader scope than Apto's specialist focus.
- **Stripe API** — Pair Apto card issuance with Stripe to accept inbound funding payments before loading the issued card.
- **Shopify Admin API** — When card issuance powers a merchant rewards card, Shopify exposes order and customer data that drives the load amount.

## FAQ

### Why is there no official OpenAPI spec for Apto Payments Card Issuance API?

Apto Payments does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Apto Payments Card Issuance API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Apto Payments Card Issuance API use?

Apto Payments uses HTTP bearer authentication. The bearer token is sent in the Authorization header on every request. Through Jentic, the bearer token is stored encrypted in the vault and never enters the agent's context.

### Can I issue a physical debit card with this API?

Yes. Call POST /cards with a valid cardholder_id and card configuration; Apto handles the BIN sponsor and network-side issuance. After delivery, call POST `/cards/{card_id}/activate` to make the card live.

### How do I list transactions for a specific card?

Call GET `/cards/{card_id}/transactions` with the card identifier returned by the issuance step. The endpoint returns the transaction stream that has posted against that card.

### What are the rate limits for the Apto Payments API?

The OpenAPI spec does not define explicit rate limits. Apto Payments enforces programme-level limits negotiated as part of your card-issuing agreement; check your Apto contract or programme manager for the exact thresholds.

### How do I issue a card through Jentic?

Install Jentic with pip install jentic, search for 'issue a debit card to a new cardholder', load the schemas for POST /cardholders and POST /cards, then execute both calls in sequence. Jentic resolves the bearer token automatically.

### Can I limit what my agent is allowed to do with the Apto Payments Card Issuance API?

Yes. Because you run Jentic One yourself, your own rules decide which Apto operations and credentials the agent may use. Apto puts the cardholder and card ids in the URL path (`/cardholders/{cardholder_id}`, `/cards/{card_id}`), so a rule can pin the agent to a single card and let it only read that card and call GET `/cards/{card_id}/transactions.` You pick the operations it may invoke, so state-changing calls such as POST `/cards/{card_id}/activate` or POST /cards stay off-limits unless you explicitly allow them.