Building with AI
These docs are machine-readable by design. Point your coding assistant at them, and check what it writes against the rules on this page.
These docs, and the OpenAPI spec behind the API Reference, are structured so an AI coding assistant can read them. That is useful for exploring the API and drafting an integration. It is not a substitute for reading the Signing Guide yourself.
Machine-readable formats
| Format | What it is |
|---|---|
| MCP server | https://docs.rasto.co/_mcp. Your agent searches these docs while it works. The best option by a distance |
/llms.txt | An index of every page, with titles, descriptions, and .md links. Good when a client cannot speak MCP |
<page>.md | Any page as raw Markdown. Add .md to the end of its URL |
| API Reference | Generated from the running application rather than written by hand, so it cannot drift from what the API actually accepts |
curl -s https://docs.rasto.co/llms.txt
curl -s https://docs.rasto.co/concepts/wallets.md
Connecting the MCP server is worth doing before anything else. An agent that can search the docs mid-task stops guessing at field names, and takes install commands for every major coding tool from one page.
Prompts that work
Be specific about the object and the flow. The model does much better with "create a virtual account for an existing customer" than with "help me receive money".
Using the Rasto Business OpenAPI spec, write a Python function that onboards an
individual customer for endo_usd, including the profile fields that
endorsement requires, and then submits them for verification.
I got 422 endorsement_profile_required. Read the errors page and tell me
which fields are missing and which call I should have sent them on.
Write the webhook handler: verify the signature against the raw body,
dedupe by event id, order by sequence, and return 2xx before processing.
Check what it writes
Generated integrations get the same five things wrong, because they are the places where our API differs from the obvious guess. Check each one before you ship.
| What to check | Why it goes wrong |
|---|---|
| Verification is submitted explicitly | Assistants assume creating a customer with documents starts the review. It does not: POST /api/customers/{id}/verifications/submit is the only call that starts one |
| Endorsements are requested explicitly | A customer without endorsements: ["endo_usd"] never reaches USD verification, and the failure surfaces much later at virtual-account creation |
currency and rail are both required | There is no default rail. Generated code often omits it |
| Amounts are decimal strings | Models reach for floats. Parse into a decimal type, and send strings |
| Idempotency keys are per request | Generated code often hoists one key into a constant, which fails loudly on the second endpoint that uses it |
Never let an assistant write a signing flow that skips verification. A
plausible-looking implementation that signs signing.digest without
rebuilding the transaction first will work perfectly in testing and forfeit
the entire non-custodial guarantee in production. The verifier exists to be
correct when we are compromised, which is a property no test will show you.
Read the Signing Guide and write that code
deliberately.
Give it the sandbox, not production
Start with an sk_test_ key. Sandbox is the full product with everything
behind the API simulated, so an assistant can create customers, approve
them, land deposits, and read the results without any real money existing.
See Sandbox Testing.
If you let an agent call the API directly, give it a read_only key until
you have watched what it does. A read-only key can call every GET and no
mutation.