The virtual card API for business, built to issue cards programmatically.

A virtual card API for business lets your software issue a capped, locked virtual Visa card by sending one request, instead of a person filling out a form for every new vendor. Set the amount, an optional merchant or category lock, and an expiration in that same call, and the card is ready to send.

If your team already builds internal tools, the question is rarely whether Virtual Card Maker can issue a card. It can, from the dashboard, in a couple of clicks. Virtual Card Maker cards are wallet-funded, with no credit check required, whether you issue them by hand, from a spreadsheet, or through this API. The real question is whether that issuing logic can live inside your own system, so a card gets created because your code decided it should. This guide covers what a typical request and response look like, when the API beats a spreadsheet upload, and where it sits next to the dashboard. For the authoritative endpoint list, authentication, and SDKs, see the API documentation.

How the virtual card API actually works

A card-issuing API call replaces a form with a function. Instead of a person opening the dashboard, typing a card name, a limit, and a lock, then clicking issue, your system sends one request carrying the same information: how much the card can spend, where it can be used where supported, and how long it should stay active. The card that comes back is the same kind a person would create by hand, ready to email to the recipient.

What changes is who does the clicking: your integration, on a trigger you define, instead of a person doing it once per vendor or contractor. That is why teams reach for the API once issuing a card stops being a one-off event and becomes a recurring step.

Why a business reaches for the API instead of the dashboard

The dashboard works well for one card at a time: a single new hire, a single vendor, a one-off travel card. It gets slower once card issuing stops being a one-off event and becomes a recurring step in a bigger process. A staffing company onboarding contractors every week, a marketplace issuing a payout card per seller, or an internal tool that already tracks vendors in its own database all run into the same problem: someone still has to remember to create the card by hand.

The API removes that manual step. Your system already knows the moment a new contractor is approved or a new vendor record is created. Wiring the card-issuing call into that same event means the card exists as soon as the condition is met, with the same spend cap and lock rules you would set by hand.

What a card-issuing request and response actually look like

The exact endpoint names, fields, and authentication details for your account live in the API documentation, since those can vary by plan. What follows is a typical shape for a card-issuing API like this one, so you know roughly what to expect before you open the real reference. A request generally needs three things: how much the card can spend, what it can be used for where supported, and how long it should last.

curl -X POST https://api.example.com/v1/cards \
  -H "Authorization: Bearer {API_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "label": "Denholm Freight Partners - Vendor Card",
    "amount_limit": 500.00,
    "merchant_category": "home_improvement_supply",
    "expires_at": "2026-08-01",
    "recipient_email": "ap@denholmfreight.example"
  }'

And a typical response, returning a card identifier and the last four digits rather than the full card number, looks something like this.

{
  "id": "card_8f3ac1",
  "status": "active",
  "last4": "4482",
  "amount_limit": 500.00,
  "amount_available": 500.00,
  "merchant_category": "home_improvement_supply",
  "expires_at": "2026-08-01",
  "created_at": "2026-07-01T09:14:00Z"
}

Field names above are illustrative of a typical card-issuing API shape, not a guaranteed literal spec for your account. Confirm exact endpoints and fields in the API documentation before you build against them.

Notice what the response leaves out: a card identifier, the last four digits, and a status, the same limited detail you would see glancing at a card in the dashboard, not a full card number or a CVV rendered for display. Full card details for an authorized user typically come through a separate, more tightly secured call, not the create response itself. Check the API documentation for what your account actually returns.

Manual entry, Excel bulk upload, or API integration: which one fits your team

Most businesses do not pick one of these forever. They start manual, move to a bulk upload as volume grows, and add API access once issuing ties into another system. Here is how the three stack up.

A five-person shop issuing two cards a month has no reason to build against an API. A platform onboarding contractors daily has every reason to. See how to issue virtual cards in bulk for the spreadsheet side of that decision.

A real example: auto-issuing a vendor card the moment a new vendor is added

Denholm Freight Partners runs its subcontractor list in an internal tool its operations team already uses to approve new vendors. Before the integration, adding a subcontractor meant a second step: Priya Anand, the company's controller, had to log into Virtual Card Maker and issue a card by hand. Denholm wired its internal tool to call the card-issuing endpoint the moment a record is marked approved instead.

Do API-issued cards show up in your normal dashboard?

Yes. A card created by an API request is the same kind of card as one created by clicking issue in the dashboard, and it appears in the same card list with the same controls to view balance, freeze, or cancel it. Your integration does not create a separate, hidden pool of cards; it uses the same issuing engine a person would use by hand, so whoever reviews spend has one place to look regardless of how a given card was created.

That matters most for a mixed rollout. You can keep issuing one-off cards manually while your integration handles the recurring ones, and see all of it in one dashboard instead of reconciling two separate systems at month-end.

Getting API access: sandbox, tokens, and your first call

You do not need a developer to try Virtual Card Maker, but you generally do need one to build against the API, since that means writing code that calls an endpoint rather than clicking through a screen. Most teams that adopt the API already have an internal tool, a vendor database, or an onboarding system in place and want card issuing to plug into it.

Card-issuing APIs of this kind typically offer a sandbox or test mode so your developer can build and test against fake cards before switching to production, and authentication generally works on an API key or token you generate once API access is turned on. Exact steps for token generation and any sandbox details for your account are covered in the API documentation; treat the above as the general shape to expect, not a substitute for that reference.

1. Get API access. Turn on API access for your account so your developer has something to build against.
2. Generate a token. Create the API key or token you'll send with each request.
3. Build the request. Specify the spend cap, an optional merchant or category lock, and an expiration.
4. Send the request. Call the card-issuing endpoint from your own system, in a sandbox first where offered.
5. Read the response. Confirm the card identifier, last four digits, and status came back as expected.

Mistakes to avoid when automating card issuance

People also ask