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 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 |
/llms.txt | An index of every page, with titles, descriptions, and .md links. Use it when a client cannot speak MCP |
<page>.md | Any page as raw Markdown. Add .md to the end of its URL |
curl -s https://docs.rasto.co/llms.txt
curl -s https://docs.rasto.co/concepts/wallets.md
Connect the MCP server first. An agent that can search the docs mid-task stops guessing at field names. That page has the install command for each major coding tool.
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 docs, 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/{customer_id}/verifications makes the first submission. After it, a PATCH that changes something resubmits by itself, so generated code should not call submit again |
| 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 is required on a virtual account | There is no default currency. payment_rails is optional: omit it to receive over every rail the currency is served on |
| Amounts are decimal strings | Models reach for floats. Send amounts as JSON strings: a fractional JSON number is refused with 422 invalid_parameter. Responses carry no trailing zeros, so parse into a decimal type and compare as decimals |
| Idempotency keys are per request | Generated code often hoists one key into a constant, which fails with 422 idempotency_key_reused on the second endpoint that uses it |
Never let an assistant write a signing flow that skips verification. An
implementation that signs signing.digest without first rebuilding the
transaction passes every sandbox test and gives up the non-custodial
guarantee in live. The verifier exists to protect you if we are
compromised, and no test exercises that case. Read the
Signing Guide and write that code yourself.
Give it the sandbox, not live
Start with an sk_test_ key. Sandbox runs the full product on testnets
with simulated bank rails and verification, so an assistant can create
customers, approve them, land deposits, and read the results without moving
real money. 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.