Changelog

How to read this

Additive changes (new fields, new endpoints, new event kinds) ship without notice and are always safe, so build your parsers to ignore unknown fields. Anything breaking gets an entry here with a migration note before it reaches the live environment, and rides the Api-Version header. Omitting that header pins you to the oldest supported version, so a deploy can never move you onto a breaking change.

2026-08-26: the product is Rasto Business

The API and every object, field, status, and error code are unchanged. Only the name is.

• Rasto Business is the product name across this site and in the API Reference, whose info.title now reads Rasto Business API. The company is still Rasto, so anything referring to us by company name is unchanged, and no endpoint, id prefix, or field name moved.
• Descriptions throughout the reference were reworded to drop internal vocabulary. Where a page previously said a third party did something, it now says what we do, which matches the contract you actually integrate against: every status, code, and message you receive is one we defined.

Nothing here requires a change on your side.

2026-08-26: documentation rewrite, corrections, and a restructure

These docs were rewritten against the live API surface and reorganized. Nothing in the API changed, so this entry is a map for anyone who bookmarked a page or built against the earlier text.

Pages moved

The mechanics of calling the API now live in the API Reference tab, beside the endpoints, rather than in the Documentation tab.

Pages added

• Quickstart is now five short guides run in order: get set up, onboard a customer, receive a payment, send from a wallet, set up webhooks.
• Use cases has a page each for contractor payouts, B2B invoicing, dollar accounts, and treasury.
• Verifying signatures carries the full verification procedure with runnable Python and TypeScript.
• MCP Server: these docs now expose a Model Context Protocol endpoint at https://docs.rasto.co/_mcp, so a coding agent can search the current documentation while it works. No authentication, read only, and the page carries install commands for Claude Code, Cursor, VS Code, Claude Desktop, Codex CLI, Gemini CLI, Windsurf, and Cline.
• Amounts & Precision, FAQ, Building with AI, Implementation Overview, and two help-center entries covering virtual-account gating and expired operations.

Corrections

Several pages had drifted from the code. Every item below is a fix.

• Verification submission is explicit. Documents sent on customer create or PATCH are staged, never submitted. The only call that starts a review is POST /api/customers/{id}/verifications/submit. Earlier pages described automatic submission, which does not happen. Submitting with inputs still outstanding returns 422 verification_incomplete naming them.
• The sandbox verification decision is request_for_information, not awaiting_info. Accepted values are approved, rejected, and request_for_information.
• Corrected error codes: invalid_signed_tos_id (not signed_tos_id_invalid), no_rate_available (not no_route_available), missing_idempotency_key is a 400. New codes documented: endorsement_not_approved, customer_name_required, virtual_account_exists, unsupported_rail, amount_out_of_range, unknown_endorsement, document_rejected, invalid_signature, keys_required, keys_already_registered, invalid_public_key, activation_rejected, invalid_cursor, unsupported_api_version.
• Corrected ids: payouts are pay_, webhook events are wev_.
• Corrected defaults: list limit defaults to 25.
• Business customers use controllers, one array with role flags (has_ownership, has_control, is_signer, is_director), not parallel owner, representative, and director lists. The business discriminator field is business_kind.
• Virtual account destinations can target a held wallet: {"kind": "wallet", "asset": "usdc", "wallet_id": "wal_..."}.
• Wallet objects publish signing_reference, the immutable derivation reference your verifier compares against. Store it at creation.
• Corridor fees are {bps, spread_bps, min, collection}.
• Virtual account statuses are pending, active, frozen, closed.
• New pages: What You Can Build, Implementation Overview, Amounts & Precision, and two help-center entries covering virtual-account gating and expired operations.

2026-08-22: wallets

Customer-held stablecoin wallets, non-custodial. Additive: nothing in the existing surface changed.

• Wallets: chain-scoped wallets, as many per customer as you need. We hold no key that can move the funds. Every address derives from your own Recovery Key, so a full compromise of our systems still cannot spend from one.
• Funded by a plain on-chain send: no transfer object to create first, and balances are read from the chain, so directly received funds are immediately spendable. Create, list, read balances (single GET plus a total_balances roll-up), and paginate history.
• Register two keys first: a Primary Signing Key (hot, rotatable) and a Recovery Key (cold, permanent, and the identity your addresses derive from). You send us only the public halves, and wallet creation returns 400 public_keys_required until they are on file.
• One address across EVM chains: address_wallet_id reuses an existing wallet's derivation so the same address extends onto another EVM chain. EVM only on both sides.
• Sending funds: every send is an operation you verify and authorize with your own key. We build the exact transaction and hand back an authorization carrying the full intent plus everything needed to rebuild it independently, never a bare hash to sign blind.
• New lifecycles: wallet and wallet_operation, both in Statuses & Lifecycles.
• New events: wallet.created, wallet.deposit_received, wallet.withdrawal_created, wallet.deposit_returned, wallet.operation_confirmed, wallet.operation_failed.

2026-08-13: endorsements as the one KYC channel

• Endorsements are requested explicitly: endorsements: ["endo_usd"] on customer create or PATCH. Requesting endo_usd needs email, phone, economic_profile.tin, and economic_profile.tax_residence_country in the same request, otherwise 422 endorsement_profile_required.
• Decisions arrive as endorsement.approved, endorsement.request_for_information, and endorsement.rejected. There are no verification.* events.
• Every ask is a bare documented code in one of five requirements buckets. The customer's requirements_due, the issues object list, and profile_due are all gone: one channel, not three.
• Payloads are lean on PII. The customer object no longer echoes phone, date of birth, nationality, id documents, economic profile, or controllers. The address trims to state and country, and verification payloads drop every internal name and all extracted data.

2026-08-08: USD launch shape

• USD first: launch fiat-in is USD over ACH and Fedwire. currency and rail are both required on every virtual-account create, and deposit_instructions carry account_number and routing_number. EUR over SEPA returns later. Coverage is the live matrix.
• Solana first: wallets and deliveries launch on Solana. Base, Ethereum, and Polygon are built and enable next, returning 400 unsupported_chain until then.

2026-07-29: initial API surface

• Onboarding: hosted terms links and programmatic attestations. Customers (individuals and businesses) with API document sharing as the verification intake.
• Accounts and money: virtual accounts with versioned stablecoin destinations. Deposits, conversions, and payouts with itemized fee_lines and a frozen exchange_rate. A unified transactions feed and ledger-truth balances.
• Pricing: per-account partner fees (partner_fee_bps and partner_fee_flat) settled to your balance in real time. Two-directional fee-itemized quotes/estimate. Account-scoped corridors.
• Platform: Api-Key auth with split sandbox and live hosts. Mandatory idempotency on every POST with byte-for-byte replays. One error envelope. Cursor pagination. Signed webhooks with a delivery portal and replay.
• Sandbox: verification-decision, treasury-funding, and fiat-deposit simulators, with magic amounts 666.00 (returned) and 777.00 (on hold).