Jeeves Public API

Jeeves Public API (1.0.0)

Introduction

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.

Download OpenAPI description

index.json

index.yaml

Servers

https://public-sandbox.tryjeeves.com/

https://public-api.jeev.es/

Boletos

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

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.

Operations