Travel cards

One VCN per booking: metadata, booking references, and travel reconciliation.

What "travel" means here: every virtual card created through this API is a travel card — the product was built for travel platforms, and the name stuck. Their transactions live under source: "travel"; your company's regular Jeeves corporate cards report under source: "cards".

Travel platforms issue one virtual card per reservation so every supplier charge reconciles to exactly one booking. Three pieces make that work: card metadata, the booking-details endpoint, and travel-source transactions.

The pattern

Booking confirmed ──► POST /v1/cards (metadata + tight restrictions)
                          │
                          ▼
                  Supplier charges the VCN
                          │
                          ▼
        PATCH /v1/travel/cards/{id}/booking (itinerary, reference)
                          │
                          ▼
     POST /v1/cards/transactions {"source": "travel"} — reconcile

Issue the card with booking metadata

Give the card the reservation identifiers as metadata, a spend limit at (or slightly above) the booking amount, a single-use count, and an active window around the charge date:

curl -X POST \
  'https://public-sandbox.tryjeeves.com/v1/cards' \
  -H "Authorization: Bearer $JEEVES_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Travel Card",
    "metadata": {
      "reservation_code": "abc123",
      "passenger_name": "John Doe"
    },
    "expectedChargeDateUTC": "2026-10-02",
    "restrictions": {
      "spendLimit": 1000,
      "maxTransactionCount": 1,
      "activeDateRangeUTC": {
        "startDate": "2026-10-01 00:00:00",
        "endDate": "2026-10-15 23:59:59"
      }
    }
  }'

expectedChargeDateUTC tells Jeeves when the supplier is expected to charge; it requires the cards:multiple:write scope, enabled on request — contact Jeeves support.

Attach booking details

PATCH /v1/travel/cards/{id}/booking (scope cards:write) records the itinerary, booking reference, and transaction ID on the card — including custom fields:

curl -X PATCH \
  'https://public-sandbox.tryjeeves.com/v1/travel/cards/123e4567-e89b-12d3-a456-426614174000/booking' \
  -H "Authorization: Bearer $JEEVES_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "itineraryId": "ITIN-993235",
    "bookingReference": "BREF-334234",
    "transactionId": "TRX-673829"
  }'

The response is the travel card with its merged metadata and restrictions.

Reconcile travel transactions

Completed travel-card transactions come back through the unified transactions endpoint with source: "travel" — each row carries the card's metadata, MCC, authorization code, and restrictions:

curl -X POST \
  'https://public-sandbox.tryjeeves.com/v1/cards/transactions' \
  -H "Authorization: Bearer $JEEVES_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "source": "travel", "startDate": "2026-10-01", "endDate": "2026-10-15" }'

See Reconciliation for pagination and date-window defaults.

GET /v1/travel/transactions is deprecated — it returns the same data as POST /v1/cards/transactions with source: "travel". Migrate to the unified endpoint.