AI-assisted integration

If you use a coding assistant while working with this API, you can give it the same documentation we use instead of relying on generated or rendered pages.

Available files

File	Contains	Approximate size
/llms.txt	Documentation index, following the llmstxt.org convention	15 KB
/llms-full.txt	Full prose documentation	355 KB
/llms-api.txt	Compact reference for every endpoint, generated from the API specification	50 KB
/openapi.yaml	Full OpenAPI specification	100 KB

The sizes are approximate and may change as the documentation is updated.

Each documentation page is also available as raw Markdown. Just add .md to the URL:

/docs/get-started/quickstart.md

You can also send Accept: text/markdown with a request to receive the Markdown source instead of the rendered HTML.

Which file should I use?

For most tasks, start with /llms.txt. It provides an index of the documentation and links to the pages relevant to a particular topic.

For endpoint-specific questions, use /llms-api.txt. It's generated from the API specification, so the endpoint details stay consistent with the reference documentation. It's useful for questions such as "How do I create a card?" or "What does this error mean?"

For broader questions about how the API works, use /llms-full.txt. It covers things like the object model, authorization lifecycle, and balance model. Since it's much larger, it's better suited to questions that involve several parts of the API rather than a single request.

Note: llms-full.txt doesn't include the generated endpoint pages. Those pages are MDX built from React components, so including them would add a lot of markup without much useful context. The OpenAPI specification and llms-api.txt contain the endpoint information in a more useful format.

Using the files with a coding assistant

Most coding assistants can read a URL directly. For example:

Read https://<this site>/llms-api.txt and write a Node.js function that issues a virtual card with an idempotency key and retries correctly on 5xx.

If you're going to use the documentation repeatedly, it's usually better to download the files into your repository. That way the assistant can work from the local copy without fetching the documentation every time, and the version used by your project stays reproducible.

A couple of things to watch for

There are two mistakes we see fairly often in generated code.

The first is idempotency keys. Generate the key before the first request, not inside the retry loop. The same key must be reused for every retry. Generating a new key for each attempt defeats the purpose of idempotency.

See idempotency for details.

The other is handling money as a floating-point number. Amounts in the API are represented as integer minor units. Don't divide them by 100 and store the result as a float just to make them easier to work with. Floating-point arithmetic can introduce rounding errors that eventually show up in production.

See timestamps and money.

Both mistakes are easy to miss because the resulting code will usually compile and may even pass a basic smoke test.

Client libraries

There are no server-side client libraries, and we don't currently plan to provide them.

The API uses standard HTTP with a bearer token, so you can use whatever HTTP client fits your stack, including curl, httpx, requests, OkHttp, axios, or Go's net/http.

If you'd prefer a typed client, you can generate one from the OpenAPI specification. You can also give /llms-api.txt or the specification to your coding assistant and have it generate a client for your language.

Generated clients only cover the server-side API. They don't handle device-side operations such as displaying a full card number or working with a PIN. Those flows require platform-specific cryptography on the cardholder's device, and the guides include examples for iOS, Android, and the browser.

See security for more information.