The Jeeves API is built around REST principles. Our API accepts JSON-encoded request bodies, returns JSON-encoded responses, and uses standard HTTP response codes.
Looking for money movement? Quotes, payments, beneficiaries, and funding accounts live in the separate Payments API reference (guides: Payments). This reference covers cards, boletos, transactions, travel, and webhook subscriptions.
Authentication
The Jeeves API uses mTLS and OAuth 2.0 to authenticate requests. You can request your mTLS certificate and OAuth 2.0 credentials in both sandbox and production environments by reaching out to our support team.
All API requests will only work over HTTPS. Calls made over plain HTTP will fail. API requests without authentication will also fail.
Errors
The Jeeves API uses standard HTTP response codes to indicate the success or failure of an API request. In general: codes in the 2XX range indicate success; codes in the 4XX range indicate an error in the information provided; codes in the 5XX range indicate an internal error with Jeeves application/server.
Currently, the Jeeves API has the following HTTP responses:
Code
Response
Description
200
Ok
Object was returned as expected.
201
Ok
Object was created as expected.
202
Accepted
Request was accepted and will be processed asynchronously.
204
Ok
No return, but request was processed as expected.
400
Bad request
At least one argument is wrong or missing.
401
Unauthorized
No valid API token provided.
403
Forbidden
The API token doesn't have permission to perform the request.
404
Not found
The requested resource doesn't exist.
409
Conflict
The request conflicts with an operation already in progress — retry once it completes. In the Payments API, also returned when an Idempotency-Key is reused with a different body.
422
Unprocessable entity
The request is well-formed but the resource's current state rejects it — in the Payments API, an expired quote, a corridor validation failure, or insufficient funds.
429
Rate limited
Too many requests — honor Retry-After (Payments API).
500
Server error
An internal error at Jeeves.
In this reference, 409 and 422 are returned by the boleto discount and rebate endpoints; 429 is returned today only by the Payments API — full semantics in Errors & rate limits.
The Boleto API supports the full boleto lifecycle, enabling clients to create, retrieve, extend, and cancel boletos, and to configure early-payment discounts and reduce the amount owed (abatimento), via secure integration. It also supports Bolepix, which adds a Pix QR code to the boleto for instant settlement through Pix rails. For boletos paid via barcode or digitable line, the API provides an early payment notice before final settlement - offering visibility of the payment up to one day in advance, with guaranteed settlement. For boletos paid via Pix (via Bolepix), the boleto is marked as paid directly, as settlement is immediate.
Operations
Pix Charges
The Pix Charges API lets clients create dynamic Pix charges: a single-use Pix QR code that the payer can scan or paste into their banking app. Each charge carries pixCopyPaste (the copy-and-paste payload) and qrCodeImage (a base64-encoded JPEG of the QR code).
Charges are not pushed to you: poll GET /v1/pix-charges/{id} to follow a charge until it reaches a final status.
A charge has one of these statuses:
Status
Meaning
active
The charge can be paid. Only active charges can be canceled.
under_review
The charge is under review.
paid
The charge was paid. paymentDetails is present. Final status.
canceled
The charge was canceled with POST /v1/pix-charges/{id}/cancel. Final status.
expired
The charge was not paid before payableUntil. Final status. It can be set 1 to 3 days after payableUntil, not right at the end of that day.
Due date and payable period. Without dueDate, the charge is due 365 days from today (Brasilia time) and daysPayableAfterDue is 0. daysPayableAfterDue can only be sent together with dueDate; when dueDate is sent without it, it defaults to 180. The response always carries the effective dueDate and daysPayableAfterDue, and payableUntil, the last day the QR code can be paid.
Your own reference.externalId is unique per organization. Reusing one returns a 409 whose errorData.chargeId is the id of the existing charge.
Operations
Cards
The Card API supports the full card lifecycle, enabling clients to create, retrieve, and update cards via secure integration. Use POST /v1/cards/transactions with the source field to query card or travel transactions in a single endpoint.
Operations
List all cards
Request
You can see a list of cards belonging to the owner of the client credentials.
Set of key-value pairs that you can attach to the card. Limitations: maximum of 10 key-value pairs, keys cannot exceed 50 characters, values cannot exceed 255 characters.
Set of key-value pairs that you can attach to the card. Limitations: maximum of 10 key-value pairs, keys cannot exceed 50 characters, values cannot exceed 255 characters.
The date when the card is expected to be charged (UTC). Must not be a past date. Requires the cards:multiple:write scope, which is enabled on request — contact Jeeves support.
Set of key-value pairs that you can attach to the card. Limitations: maximum of 10 key-value pairs, keys cannot exceed 50 characters, values cannot exceed 255 characters.
Retrieve settled card transactions or completed travel card transactions through a single endpoint. The source field selects which transactions you get and determines the response shape: cards returns your company's regular Jeeves corporate-card transactions; travel returns transactions from the virtual cards created through this API.
Response shape by source
source
Response schema
Description
cards
TransactionResponse
Settled card transactions for your company
travel
TravelTransactionResponse
Completed transactions from virtual travel cards
Both responses include a pagination object with pageSize, totalCount, nextCursor, and hasNext.
Pagination
Because this is a POST endpoint, links.next is always null — the request body cannot be encoded in a URL. To page forward, send a new request with the same filters and set pageCursor to the value from pagination.nextCursor. Repeat until pagination.hasNext is false.
Default date window
When cardIds is not provided, startDate and endDate both default to yesterday (D-1, yyyy-MM-dd).
When cardIdsis provided, no default dates are applied — all transaction history is returned unless you set startDate and/or endDate explicitly.
travel — completed transactions from virtual travel cards created via API.
Enum"cards""travel"
Example: "cards"
cardIdsArray of strings(uuid)non-empty
Optional list of card UUIDs (v4) to filter transactions. Must contain at least one element when provided. When provided without dates, all transaction history is returned for those cards.
Example: ["c8ddf33f-6244-4218-af7e-7a6fe0b13528"]
startDatestring(date)
Start date (inclusive) for filtering transactions, in yyyy-MM-dd format. Must not be a future date. Must not be after endDate when both are set. Defaults to yesterday (D-1) when cardIds is not provided.
Example: "2025-01-01"
endDatestring(date)
End date (inclusive) for filtering transactions, in yyyy-MM-dd format. Must not be a future date. Defaults to yesterday (D-1) when cardIds is not provided.
Example: "2025-01-31"
pageSizeinteger[ 1 .. 100 ]
Number of transactions returned per page. Defaults to 20 when omitted. Maximum 50 when source=cards; maximum 100 when source=travel.
Default 20
Example: 20
pageCursorstring
Opaque cursor for the next page, returned in pagination.nextCursor from a previous response. Omit on the first request.
Paginated transactions. Response shape depends on source in the request body.
Bodyapplication/json
One of:
linksobject(TransactionResponseLinks)required
links.nextstring or nullrequired
Link to the next page; null if there is no next page. For deprecated GET transaction endpoints, this may contain a URL with query parameters. For POST /v1/cards/transactions, this field is always null — use pagination.nextCursor in the next request body instead.
The card's funding model: credit_line (spend on your Jeeves credit line) or self_funded (spend from your own pre-funded balance). Same concept as productAccountType in the Payment API.
Enum"credit_line""self_funded"
Example: "credit_line"
data[].companyobjectrequired
data[].company.idstringrequired
Company identification within Jeeves.
Example: "361c697b-8d82-11ec-a51a-0ea06e4de10b"
data[].company.namestringrequired
Company name within Jeeves.
Example: "Acme Corporation"
data[].userobjectrequired
data[].user.idstringrequired
User identifier within Jeeves.
Example: "d5d5c940-3c58-4ecc-b772-fe20e764ed70"
data[].user.namestringrequired
User full name.
Example: "John Doe"
data[].user.emailstringrequired
User email address.
Example: "john.doe@acmecorp.com"
data[].cardobjectrequired
data[].card.idstringrequired
Card identifier within Jeeves.
Example: "c8ddf33f-6244-4218-af7e-7a6fe0b13528"
data[].card.namestringrequired
Card label defined by the user.
Example: "Travel Card"
data[].card.typestringrequired
Card type.
Enum"Physical""Virtual"
Example: "Physical"
data[].card.numberstringrequired
Last 4 digits of the card number.
Example: "9876"
data[].card.metadataobject or null
Additional metadata associated with the card. Structure varies by transaction type and processor.
Set of key-value pairs that you can attach to the card. Limitations: maximum of 10 key-value pairs, keys cannot exceed 50 characters, values cannot exceed 255 characters.
You can update card configuration by the card unique id.
Path
idstring[^\/#\?]+?required
Unique identifier of a card.
Headers
Accept-Languagestring
Language code for localization.
Default en-US
Enum"en-US""es-MX""pt-BR"
Example: en-US
Bodyapplication/jsonrequired
CardUpdateDto
namestring<= 60 characters^[a-zA-Z0-9\s]+$
Name given to the card.
Example: "Travel Card"
metadataobject
Set of key-value pairs that you can attach to the card. Limitations: maximum of 10 key-value pairs, keys cannot exceed 50 characters, values cannot exceed 255 characters.
Set of key-value pairs that you can attach to the card. Limitations: maximum of 10 key-value pairs, keys cannot exceed 50 characters, values cannot exceed 255 characters.
List of merchant categories with their associated merchant category codes.
Bodyapplication/json
rowsArray of objects(MccCategoryDto)
countnumber
Example: 100
Response
application/json
{
"rows": [
{ … }
],
"count": 100
}
Transactions
The Transactions API enables clients to retrieve card and payment transactions via secure integration. Supports filtering by date range and pagination for efficient data retrieval.
Operations
Travel
The Travel API covers the virtual cards created through this API (originally built for travel platforms, hence the name): retrieve their completed transactions and attach booking details to a card.
Operations
Webhooks
The Webhooks API provides access to webhook subscription management and event tracking, enabling you to receive real-time HTTP notifications the moment a card transaction is approved, declined, settled, or fails. These subscriptions cover card events only — payment.status.updated for the Payments API is delivered separately and has no subscription endpoint, see the Payments API reference.