docs: rewrite the ramp pages for the unified order API

[santy311]

Independent of the SDK stack (separate repo), but describes the same change.
Pairs with anagrambuild/swig-developer-sdk#14, #15, #16.

Why

Both ramp pages describe a backend surface that no longer exists. The ten
/wallet/api/ramp/{onramp,offramp}/* routes were removed; ramp.v1 serves both
directions from six routes, with direction carried by the order rather than the
path.

What changes

• developer-api/ramp.mdx — the six routes, configurationId instead of
  organizationMeldConfigurationId, a ramp environment instead of the MELD
  enum, and orders instead of sessions.
• developer-sdk/ramp.mdx — the single swig.ramp client, dropping the
  direction-split framing and the claim that there is no generic ramp client.
• Documents what the old surface had no equivalent for: the twelve order
  statuses, requestId idempotency, that quotes carry no id and must never be
  cached, integer amounts in minor and base units, the two-case crypto asset,
  the sell-side prepare/sign/submit leg, and that refunded can follow
  settled.
• Sweeps the cross-references that still described on-ramp and off-ramp as
  separate surfaces, in both overview pages and both area index pages.

Format

Follows the house pattern rather than introducing one: title/sidebarTitle
frontmatter only, a ## Routes table, per-endpoint sections, field tables with
| :--- |, fenced ```json request bodies on the API page, and
<CodeGroup dropdown> with TypeScript and Python on the SDK page. Both keep
their closing cross-link and trust-boundary paragraph.

Validation

Nav is unchanged — both pages keep their existing paths, so no docs.json edit
and no redirects are needed. Every internal link in the two rewritten pages was
resolved against the tree:

/developer-api/errors  OK
/developer-api/ramp    OK
/developer-sdk/ramp    OK

This repo has no CI and no build tooling, so mint dev and mint broken-links
are worth running locally before merge — nothing here will catch a broken link
automatically.

The launch-URL logging guidance in developer-api/errors.mdx still holds
(launchUrl survives in ramp.v1) and is deliberately left alone.

Not yet reviewed

Unlike the SDK stack, this branch has not had an independent review pass. Draft
until it does.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
Swig	🟢 Ready	View Preview	Sep 11, 2026, 1:27 PM

💡 Tip: Enable Automations to automatically generate PRs for you.

[edo-chan]

Two documentation corrections from the SDK stack and API contract review.

[edo-chan]

[P2] Complete the sell checkout before preparing its transfer

This example passes order.id, but the preceding createOrder / create_order examples create a buy order. Following the page in order therefore reaches FAILED_PRECONDITION (only a sell needs a transfer). Please show a separate sell order, explicitly using a mainnet wallet/context, take the customer through that order's launch URL, and poll until its deposit is available before preparing the transfer. This also makes the required sell checkout step explicit instead of leaving the reader waiting for a deposit without engaging with the provider. The same gap appears in the TypeScript and Python READMEs in SDK #14 and #15.

[santy311]

Fixed in 7419238. The section is now "Sell: create, check out, transfer" and walks the whole flow: a sell quote, a second order created with a mainnet order context, the customer through that order's launch URL, and a poll until the order reaches awaiting-transfer with a deposit — then prepare, sign, submit against sellOrder.id / sell_order.id. The refusals are named inline so the reader sees why each step is required, and the Prepare a transfer route on the API page now lists every precondition it enforces.

[edo-chan]

[P2] Describe submission errors and recovery instead of successful pending responses

The backend does not return the listed transfer states as successful submit responses: resolve_claimed returns UNAVAILABLE while the transfer is still confirming and FAILED_PRECONDITION after a dead or reverted attempt. Both SDKs deliberately disable automatic retries for this endpoint. Please document retaining the order/transfer IDs, retrying resolution of the same attempt after a transient confirmation error, and preparing a replacement only after the prior attempt is confirmed failed. Polling getOrder alone reconciles the provider order; it does not resolve the transfer's chain state, so the current guidance can leave an attempt stuck as submitted. Source: backend transfer resolution.

[santy311]

Fixed in 7419238. Submit a transfer now says a successful response is always TRANSFER_STATE_LANDED, and carries a table of the actual failures — UNAVAILABLE while the attempt is still confirming or the claim was interrupted, FAILED_PRECONDITION once it is dead, expired, claimed by a racer, or already settled — each with what to do. It also states that retaining the order and transfer ids is what lets you resolve the same attempt, that reading the order reconciles the provider record without resolving the transfer's chain state, and that a replacement is prepared only after the previous attempt is reported failed, never on a confirmation timeout. The transfer-state enum moved to the order-read section, where a transfer is actually read.

[edo-chan]

Approved. Documentation corrections are recorded in the inline review comments.