> ## Documentation Index
> Fetch the complete documentation index at: https://docs.etherfuse.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Changelog
> API updates, new features, and improvements
**Week of November 2, 2026**
v2 embedded wallets, and POST .../claim now returns 202 with the claim on the order.
## New: Embedded wallets in v2
Register a P-256 signer key as an `embeddedWallet` payment account, and we create a wallet the key holder controls. Quote and order with it like any other account. When an order moves the wallet's funds, the key holder signs the order's `authorization` and you submit it with [`POST /organization/{organizationId}/order/{id}/authorization`](https://docs.etherfuse.com/v2/api-reference/orders/submit-authorization). In sandbox, ask your Etherfuse contact to turn embedded wallets on for your organization. See [Embedded Wallets](https://docs.etherfuse.com/v2/guides/embedded-wallets.md).
## Breaking: Claims arrive on the order
[`POST /organization/{organizationId}/order/{id}/claim`](https://docs.etherfuse.com/v2/api-reference/orders/prepare-claim) now returns `202` with no body. It used to return `{kind: "stellarTransaction", xdr}`. The claim arrives a few seconds later in an `orderUpdated` webhook and on [`GET .../order/{id}`](https://docs.etherfuse.com/v2/api-reference/orders/get-order): a self-held wallet's in `claimInstructions.preparedTransaction` with `transaction` and `expiresAt`, and an embedded wallet's as the order's `authorization` with `reason` `claim`. `claimInstructions` still holds the balance id, asset, amount and claimant, so you can build the claim yourself. See [Stellar](https://docs.etherfuse.com/v2/guides/chains/stellar.md#onramps-wallets-without-a-trustline).
**Week of October 26, 2026**
Mexican customers give CURP and RFC as text; the tax document upload is no longer accepted.
## Breaking: Tax document no longer accepted in verification uploads
Mexican customers no longer upload a Constancia de Situación Fiscal. Send CURP as `additionalInfo.curp` and RFC as `taxId` through [`POST /ramp/customer/{customer_id}/verification`](https://docs.etherfuse.com/api-reference/kyc/submit-verification-data), or let the customer enter them in the [`/idv` launch](https://docs.etherfuse.com/guides/kyc-websdk). If you import a shared session, send the CURP as `additionalInfo.curp` on [`POST /ramp/customer/{customer_id}/verification/import`](https://docs.etherfuse.com/api-reference/kyc/import-a-verified-session). The `tax_document` part of [`POST /ramp/customer/{customer_id}/verification/documents`](https://docs.etherfuse.com/api-reference/kyc/upload-verification-documents) is no longer accepted. See [Deprecations](https://docs.etherfuse.com/changelog/deprecations.md#tax-document-in-verification-uploads).
**Week of October 19, 2026**
Wallet agreement status and monthly statements now require authentication.
## Improved: Wallet agreement status and monthly statements now require authentication
`GET /wallet/{id}/agreements`, `GET /statement/wallet/{id}/date/{year}-{month}`, and its `.pdf` variant now return `401` without an `Authorization` header. Send your API key the same way you do for `/ramp` calls. A key reads its own organization and the customers it created, by organization ID or by a wallet registered to one of them. A wallet that is not registered to an organization returns `401` to an API key. See [Authentication](https://docs.etherfuse.com/authentication.md).
**Week of October 12, 2026**
v2 docs in beta, and webhook URLs must use a public domain name.
## New: v2 API docs in beta
The docs now open on v2 (beta); v1 stays under the version selector at the same URLs. In v2, bank accounts and wallets are payment accounts, and onramps, offramps, swaps and cross-chain transfers share one set of quote and order endpoints. Your API key works with both versions. See [V1 to V2](https://docs.etherfuse.com/v2/migration-guide.md) and [Transaction Fees](https://docs.etherfuse.com/v2/fees.md).
## Breaking: Webhook URLs must use a public domain name
[`POST /ramp/webhook`](https://docs.etherfuse.com/api-reference/webhooks/create-webhook) and v2 webhook subscriptions return `400` for an IP address host, a non-`https` scheme (sandbox also allows `http`), or an Etherfuse domain. We deliver only to public IPv4 addresses, so the host needs an A record.
**Week of October 2, 2026**
Avalanche wallets, onramps, and offramps, including MEXe, and KYC requirements unlock one stage at a time.
## New: Avalanche wallets, onramps, and offramps
Avalanche C-Chain is now a supported ramp chain. Register Avalanche wallets with `blockchain: "avalanche"` through [`POST /ramp/wallet`](https://docs.etherfuse.com/api-reference/wallets/register-wallet), then onramp MXN to stablebonds such as CETES and to MEXe, and offramp them back to MXN. Avalanche assets are ERC-20 contracts identified by the raw `0x...` address, like Base and Polygon. Get them from [`GET /ramp/assets?blockchain=avalanche`](https://docs.etherfuse.com/api-reference/assets/list-assets). In sandbox, Avalanche assets are on the Fuji testnet.
Offramps require AVAX in the customer's wallet for gas. Swaps are not available on Avalanche. See [Avalanche](https://docs.etherfuse.com/guides/chains/avalanche.md), [Onramps](https://docs.etherfuse.com/guides/testing-onramps.md), and [Offramps](https://docs.etherfuse.com/guides/testing-offramps.md).
## Improved: KYC requirements unlock stage by stage
[`GET /ramp/customer/{customer_id}/kyc?requirements=true`](https://docs.etherfuse.com/api-reference/kyc/get-kyc-status) lists the current stage and what is already satisfied. `customer_agreement` appears after the identity stage clears, and `proof_of_address` appears too when the identity document had no address. Send what is `pending` or `action_required`, then read the list again after each `kyc_updated` webhook. See [Requirements unlock in stages](https://docs.etherfuse.com/guides/onboarding.md#requirements-unlock-in-stages).
**Week of September 25, 2026**
Single-stablebond lookup, and the KYC requirements breakdown rejects business customers.
## New: Look up a single stablebond
`GET /lookup/stablebond/{identifier}` returns one stablebond with its current price, supply, and per-chain breakdown, from the same snapshot as [`GET /lookup/stablebonds`](https://docs.etherfuse.com/api-reference/lookup/list-stablebonds). Pass the bond's symbol or name (case-insensitive), its Solana mint, a chain token identifier, or a Stellar asset such as `CETES-GCRYUGD5NVARGXT56XEZI5CIFCQETYHAPQQTHO2O3IQZTHDH4LATMYWC`. Etherfuse bonds on Stellar share an issuer, so pass the full asset rather than the issuer alone. Like the other lookup endpoints, it is public and needs no API key. See [Get stablebond](https://docs.etherfuse.com/api-reference/lookup/get-stablebond.md).
## Fixed: KYC requirements breakdown rejects business customers
`GET /ramp/customer/{customer_id}/kyc?requirements=true` now returns `400` for a business customer. It used to return `200` with every business verification step left out, which read as a complete list. Track a business with [`GET /ramp/organization/{id}/kyb/status`](https://docs.etherfuse.com/api-reference/organizations/get-kyb-status) instead. Calls without `requirements=true` are unchanged. See [Get KYC status](https://docs.etherfuse.com/api-reference/kyc/get-kyc-status.md) and [KYB Overview](https://docs.etherfuse.com/guides/kyb.md).
**Week of September 18, 2026**
Stablebond prices come from the on-chain BondPrice account.
## Improved: Stablebond prices come from the BondPrice account
Each stablebond's price and rate come from its `BondPrice` account, a PDA with seeds `["bond_price", mint]` under the stablebond program. Quotes and `current_basis_points` read from it. The Token-2022 interest-bearing extension is for wallet display only. See [Token costs](https://docs.etherfuse.com/price-feeds.md#token-costs).
## Breaking: Priced stablebond instructions take a BondPrice account
Instructions that price a bond now require its `BondPrice` account. The current stablebond SDKs add it for you. See the [SDK instruction definitions](https://github.com/etherfuse/stablebond/tree/main/clients/js/src/generated/instructions).
**Week of September 11, 2026**
New wallet balances endpoint and a swap quote fix.
## New: Look up wallet balances and valuations
`GET /ramp/balances` returns the current balance of every supported Etherfuse asset held by one of your registered wallets, with each asset's value in its own fiat currency and in USD. Name the wallet with either `cryptoWalletId` or `blockchain` plus `publicKey`. The endpoint works across Solana, Stellar, Base, Polygon, and Monad, and omits zero-balance assets.
```json theme={null}
{
"walletId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"blockchain": "stellar",
"publicKey": "GDUKMGUGD3V6VXTU2RLAUM7A2FABLMHCPWTMDHKP7HHJ6FCZKEY4PVWL",
"observedAt": "2026-09-04T18:00:00Z",
"balances": [
{
"symbol": "cetes",
"identifier": "CETES:GC3CW7EDYV6VXTU2RLAUM7A2FABLMHCPWTMDHKP7HHJ6FCZKEY4PVWN",
"balance": "1500.00",
"currency": "mxn",
"amountInFiat": "25000.000000",
"amountInUsd": "1450.000000"
}
]
}
```
Use the `identifier` values from [`GET /ramp/assets`](https://docs.etherfuse.com/api-reference/assets/list-assets) to map balances to assets. See [`GET /ramp/balances`](https://docs.etherfuse.com/api-reference/assets/get-one-wallets-balances) for full request and response details.
## Fixed: Swap quotes that cannot fill the full size now return 424
Monad swap quotes that would partially fill because of insufficient market depth now return `424 FailedToGetQuote` instead of a `500` or a partial quote. The `424` response already documented for [`POST /ramp/quote`](https://docs.etherfuse.com/api-reference/quotes/get-quote) means the path is temporarily unquotable; retry with exponential backoff. See [Testing swaps](https://docs.etherfuse.com/guides/testing-swaps.md).
**Week of September 4, 2026**
Agreement questionnaire API, corrected swap webhook statuses, and streamlined bank account onboarding.
## New: Submit customer agreement acceptance through the KYC API
Partners whose own terms already collect customer acceptance can now submit the customer agreement through [`POST /ramp/customer/{customer_id}/verification/questionnaire`](https://docs.etherfuse.com/api-reference/kyc/submit-a-verification-questionnaire) with `type: agreement`. The endpoint accepts `acceptTerms`, `signatureName`, and `signatureDate` and returns the customer's verification status. See [KYC API](https://docs.etherfuse.com/guides/kyc-api.md) and [Customer Onboarding](https://docs.etherfuse.com/guides/onboarding.md).
```json theme={null}
{
"type": "agreement",
"acceptTerms": true,
"signatureName": "Ana Ejemplo",
"signatureDate": "2026-08-31"
}
```
Submit the agreement only when your terms incorporate the Etherfuse customer agreement and you have already collected the customer's affirmative acceptance. The [`occupation`](https://docs.etherfuse.com/api-reference/kyc/submit-a-verification-questionnaire) questionnaire remains required for every customer.
## Fixed: `swap_updated` webhook statuses now match the documentation
The [`swap_updated`](https://docs.etherfuse.com/webhooks) webhook and [`POST /ramp/swap`](https://docs.etherfuse.com/api-reference/swaps/swap-assets) documentation now use `pending` and `funds_received` instead of `created` and `funded`. The `funds_received` status fires on Stellar and Monad only; Solana swaps move directly from `pending` to `completed`. Update your webhook handler to expect `pending` and `funds_received`. See [Testing swaps](https://docs.etherfuse.com/guides/testing-swaps.md) and [Verifying webhooks](https://docs.etherfuse.com/guides/verifying-webhooks.md).
## Improved: Bank account onboarding drops the separate verification step
The partner dashboard no longer prompts customers to complete a standalone bank account verification scan. Bank accounts are approved once the organization passes verification and automated compliance checks. Add accounts after approval with [`POST /ramp/customer/{customer_id}/bank-account`](https://docs.etherfuse.com/api-reference/bank-accounts/create-bank-account-api). See [Customer Onboarding](https://docs.etherfuse.com/guides/onboarding.md).
**Week of August 28, 2026**
Token cost lookup for all tokens, partner-inherited agreement consent, and KYC awaiting\_review steps.
## New: Look up pricing for every Etherfuse token
`GET /lookup/tokens/cost` and `GET /lookup/tokens/cost/{identifier}` are public endpoints that return current pricing for every Etherfuse token, including stablebonds (CETES, TESOURO, USTRY, ...) and principal tokens (MEXe, ...). The response maps each uppercased token symbol to its mint, kind, currency, USD and fiat costs, basis points, current time, and per-provider sources. Use the optional `max_age` query parameter to filter stale sources. See [List token costs](https://docs.etherfuse.com/api-reference/lookup/list-token-costs.md), [Get token cost](https://docs.etherfuse.com/api-reference/lookup/get-token-cost.md), and [Fees](https://docs.etherfuse.com/fees.md).
## Improved: Partner-inherited agreement consent
Customers onboarded under a partner organization no longer complete a standalone user-agreement step inside the `/idv` flow; consent is inherited from your partner terms. The signed customer agreement is still generated from verified data. See [KYC WebSDK](https://docs.etherfuse.com/guides/kyc-websdk.md), [Customer Onboarding](https://docs.etherfuse.com/guides/onboarding.md), and [User Launch Flows](https://docs.etherfuse.com/guides/user-launch-flows.md).
## Fixed: KYC requirements handle inconclusive verification steps
`POST /ramp/customer/{customer_id}/verification/import` and `GET /ramp/customer/{customer_id}/kyc?requirements=true` no longer return a 502 when a verification step is under review; they now report `awaiting_review`. Read the status from [`GET /ramp/customer/{customer_id}/kyc`](https://docs.etherfuse.com/api-reference/kyc/get-kyc-status) or the [`kyc_updated`](https://docs.etherfuse.com/guides/verifying-webhooks) webhook. See [KYC API](https://docs.etherfuse.com/guides/kyc-api.md).
## Deprecated: Stablebond cost lookup
`GET /lookup/bonds/cost` and `GET /lookup/bonds/cost/{identifier}` are deprecated in favor of [`GET /lookup/tokens/cost`](https://docs.etherfuse.com/api-reference/lookup/list-token-costs) and [`GET /lookup/tokens/cost/{identifier}`](https://docs.etherfuse.com/api-reference/lookup/get-token-cost). They keep working with their existing fields and no sunset date, but they only price stablebonds, not principal tokens such as MEXe. See [Deprecations](https://docs.etherfuse.com/changelog/deprecations.md) for the field mapping.
**Week of August 21, 2026**
Business KYB decisions now close automatically, and KYC import and requirements lookups handle rejected verification steps.
## Improved: Business KYB decisions now flow through automatically
Terminal business verification decisions now approve or revoke the organization automatically, so the `kyb_updated` webhook reaches `approved` or `denied` without a manual compliance step. This matches the personal KYC approval flow. See [KYB](https://docs.etherfuse.com/guides/kyb.md) and [Verifying webhooks](https://docs.etherfuse.com/guides/verifying-webhooks.md).
## Fixed: Verification import and KYC requirements resolve rejected steps
`POST /ramp/customer/{customer_id}/verification/import` and `GET /ramp/customer/{customer_id}/kyc?requirements=true` now return the requirements breakdown for customers whose verification has a rejected step, instead of a 502. Read the status from [`GET /ramp/customer/{customer_id}/kyc`](https://docs.etherfuse.com/api-reference/kyc/get-kyc-status) or the [`kyc_updated`](https://docs.etherfuse.com/guides/verifying-webhooks) webhook. See [KYC API](https://docs.etherfuse.com/guides/kyc-api.md).
**Week of August 14, 2026**
Wallet responses no longer include per-wallet KYC status fields; use the org-level KYC endpoint and webhook instead.
## Breaking: Wallet responses no longer include per-wallet KYC status
`kycStatus` and `kycOnChain` have been removed from the [`Wallet`](https://docs.etherfuse.com/api-reference/wallets/get-wallet) object returned by wallet list, search, get, and register endpoints. KYC state is organization-level, so use [`GET /ramp/customer/{customer_id}/kyc`](https://docs.etherfuse.com/api-reference/kyc/get-kyc-status) or the [`kyc_updated`](https://docs.etherfuse.com/guides/verifying-webhooks) webhook to track verification status. The wallet object still includes `claimedOwnership` to show whether the wallet is claimed by the org.
```json theme={null}
{
"walletId": "c3d4e5f6-a7b8-9012-cdef-123456789012",
"customerId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"publicKey": "GDUKMGUGD3V6VXTU2RLAUM7A2FABLMHCPWTMDHKP7HHJ6FCZKEY4PVWL",
"blockchain": "stellar",
"claimedOwnership": true,
"createdAt": "2026-05-01T14:30:00Z",
"updatedAt": "2026-05-02T09:15:00Z"
}
```
The response no longer carries `kycStatus` or `kycOnChain`; consume KYC state from the org-level endpoint or webhook instead.
> [!WARNING]
>
> If your integration reads `kycStatus` or `kycOnChain` from any wallet response, remove that logic. Query [`GET /ramp/customer/{customer_id}/kyc`](https://docs.etherfuse.com/api-reference/kyc/get-kyc-status) for the current state, or subscribe to the [`kyc_updated`](https://docs.etherfuse.com/guides/verifying-webhooks) webhook to get notified when it changes. See [Deprecations](https://docs.etherfuse.com/changelog/deprecations.md) for the full removal record.
**Week of August 7, 2026**
Programmatic KYC API flow, partner revenue statements, and KYB status updates.
## New: Programmatic KYC API flow
Submit personal data, documents, and questionnaire answers over new [`/ramp/customer/{customer_id}/verification/*`](https://docs.etherfuse.com/api-reference/kyc/submit-verification-data) endpoints, then launch the customer into [`/idv`](https://docs.etherfuse.com/guides/user-launch-flows#identity-verification) for only the remaining steps. Import an existing Sumsub verification with [`POST /ramp/customer/{customer_id}/verification/import`](https://docs.etherfuse.com/api-reference/kyc/import-a-verified-session), look up occupation codes with [`GET /ramp/verification/occupations`](https://docs.etherfuse.com/api-reference/kyc/list-occupation-categories), and read the per-requirement breakdown from [`GET /ramp/customer/{customer_id}/kyc?requirements=true`](https://docs.etherfuse.com/api-reference/kyc/get-kyc-status). All writes except import answer `202 Accepted` and apply asynchronously. See [KYC API](https://docs.etherfuse.com/guides/kyc-api.md), [KYC Sumsub Shared Token](https://docs.etherfuse.com/guides/kyc-sumsub-shared-token.md), and [KYC WebSDK](https://docs.etherfuse.com/guides/kyc-websdk.md).
## New: Partner revenue statements
[`GET /ramp/partner-statements`](https://docs.etherfuse.com/api-reference/statements/list-partner-statements), [`.../{year}-{month}/csv`](https://docs.etherfuse.com/api-reference/statements/download-statement-csv), and [`.../{year}-{month}/pdf`](https://docs.etherfuse.com/api-reference/statements/download-statement-pdf) list and download closed monthly revenue share statements. Only closed months are returned; the open month is hidden and returns 404.
## Improved: KYB status webhooks and progress
The [`kyb_updated`](https://docs.etherfuse.com/guides/verifying-webhooks) webhook now fires when a business organization's KYB status reaches `approved` or `denied`, and the payload includes `approvedAt`. The same shape is returned by [`GET /ramp/organization/{id}/kyb/progress`](https://docs.etherfuse.com/api-reference/organizations/get-kyb-progress). See [KYB](https://docs.etherfuse.com/guides/kyb.md) and [Verifying webhooks](https://docs.etherfuse.com/guides/verifying-webhooks.md).
## Breaking: Presigned onboarding URL requires userInfo
The deprecated [`POST /ramp/onboarding-url`](https://docs.etherfuse.com/api-reference/deprecated/generate-onboarding-url) now rejects requests without non-empty `userInfo.email` and `userInfo.displayName`. It sunsets on August 16, 2026; migrate to creating a `personal` organization and launching [`/idv`](https://docs.etherfuse.com/guides/kyc-websdk) before then.
> [!WARNING]
>
> If you still use `POST /ramp/onboarding-url`, include `userInfo` with valid `email` and `displayName` before August 16, 2026.
**Week of July 31, 2026**
Catch-up on compliance and KYC status changes: bank accounts now require an approved organization, and KYC status is now a single 5-state value.
## Breaking: Bank accounts require an approved organization
`POST /ramp/customer/{customer_id}/bank-account` and the presigned bank-account path now
reject requests for unapproved personal organizations. Create the child organization with
[`POST /ramp/organization`](https://docs.etherfuse.com/api-reference/organizations/create-child-org), complete
identity or business verification, and wait for the organization to be approved before
registering a Mexican bank account. The partner dashboard also gates the bank-account step
until verification is complete.
> [!WARNING]
>
> `POST /ramp/organization` no longer creates a bank account inline and no longer returns
> `bankAccount` in the response. Register bank accounts separately after the organization
> is approved. See [Customer Onboarding (KYC)](https://docs.etherfuse.com/guides/onboarding.md) and
> [Bank account creation](https://docs.etherfuse.com/api-reference/bank-accounts/create-bank-account-api.md).
## KYC status is now a single 5-state value
[`GET /ramp/customer/{customer_id}/kyc`](https://docs.etherfuse.com/api-reference/kyc/get-kyc-status) and the
[`kyc_updated`](https://docs.etherfuse.com/guides/verifying-webhooks) webhook now publish a unified `status` field:
`not_started`, `in_progress`, `submitted`, `approved`, or `denied`. The boolean
`approved` field is still present for backward compatibility. If you were parsing the
previous `status` strings, replace `proposed` with `submitted` and use `denied` for
rejections or revoked approvals. See [Verifying webhooks](https://docs.etherfuse.com/guides/verifying-webhooks.md).
**Week of July 24, 2026**
Principal Tokens are now supported across every chain; /idv onboarding handles addresses without postal codes and verifies email earlier.
## Principal Tokens supported on all chains
MEXe, GBRe, and the full Principal Token family are now available for swaps and
bridging across every chain Etherfuse supports — Solana, Stellar, Base, Polygon,
and Monad. Create a [`POST /ramp/quote`](https://docs.etherfuse.com/api-reference/quotes/get-quote) with
`quoteAssets.type: "swap"` and the PT asset identifier from
[`GET /ramp/assets`](https://docs.etherfuse.com/api-reference/assets/list-assets), then execute with
[`POST /ramp/swap`](https://docs.etherfuse.com/api-reference/swaps/swap-assets). See the
[swaps guide](https://docs.etherfuse.com/guides/testing-swaps.md) and the chain guides for
[Stellar](https://docs.etherfuse.com/guides/chains/stellar.md), [Solana](https://docs.etherfuse.com/guides/chains/solana.md),
[Base](https://docs.etherfuse.com/guides/chains/base.md), [Polygon](https://docs.etherfuse.com/guides/chains/polygon.md), and
[Monad](https://docs.etherfuse.com/guides/chains/monad.md).
## `/idv` accepts addresses without postal codes
The hosted [identity verification flow](https://docs.etherfuse.com/guides/user-launch-flows.md#identity-verification)
now completes for customers in countries that do not require a postal code.
The address collected during `/idv` is accepted with the fields that are
present, so onboarding no longer gets stuck waiting for a postcode. See
[Customer Onboarding (KYC)](https://docs.etherfuse.com/guides/onboarding.md).
## `/idv` marks email verified earlier
Customers launched through `/idv` are now marked email-verified as soon as they
complete the email verification step, instead of waiting until full KYC
approval. This lets them continue through the rest of onboarding while the
remaining verification completes. See
[User Launch Flows](https://docs.etherfuse.com/guides/user-launch-flows.md#identity-verification).
**Week of July 17, 2026**
Customer onboarding consolidates onto a single hosted /idv flow; presigned onboarding URL and programmatic KYC endpoints deprecated.
## One onboarding flow: create org, launch `/idv`
Customer onboarding is now a single hosted flow. Create the customer's
`personal` organization (you generate its `id`), then launch them into `/idv`
with `scope: verification` and `sub` = the org id. `/idv` runs **identity
verification and agreement signing in one hosted step.** You no longer submit
identity fields, upload ID images, or run a separate `/agreements` launch.
Register the customer's wallet and bank account over the API before or after.
See [Customer Onboarding (KYC)](https://docs.etherfuse.com/guides/onboarding.md).
The partner-facing [`kyc_updated`](https://docs.etherfuse.com/guides/verifying-webhooks) webhook and
[`GET /ramp/customer/{customer_id}/kyc`](https://docs.etherfuse.com/api-reference/kyc/get-kyc-status)
status endpoint are unchanged; keep using them to track approval.
## Deprecated
The following are deprecated with a **sunset date of August 16, 2026** (see the
[Deprecations](https://docs.etherfuse.com/changelog/deprecations.md) page and the
[deprecation policy](https://docs.etherfuse.com/changelog/deprecation-policy.md)):
* **Presigned onboarding URL** (`POST /ramp/onboarding-url`) and using the
presigned URL for auth (e.g. `POST /ramp/onboarding/bank-accounts`).
* **Programmatic KYC submission** (`POST /ramp/customer/{customer_id}/kyc`).
* The **`/agreements` launch**: agreement signing now happens inside `/idv`.
**KYC document upload** (`POST /ramp/customer/{customer_id}/kyc/documents`) is
also deprecated but has **no sunset date yet**.
Migrate to the `/idv` launch above.
**Week of July 10, 2026**
MEXe on Base/EVM chains, USTRY/EUROB/KTB swaps, canonical asset metadata, restricted-country lookup, and KYB legal name.
## MEXe fiat ramps on Base and EVM chains
MEXe, the principal token backed by CETES, is now available for fiat on- and off-ramps on Base and the other EVM chains where the MEXe OFT is registered. Call [`POST /ramp/quote`](https://docs.etherfuse.com/api-reference/quotes/get-quote) with `blockchain: "base"` (or `monad`, `polygon`) and the MEXe asset identifier from [`GET /ramp/assets`](https://docs.etherfuse.com/api-reference/assets/list-assets), then create the order with [`POST /ramp/order`](https://docs.etherfuse.com/api-reference/orders/create-order). Cross-chain LayerZero OFT delivery is handled end-to-end, so the customer receives MEXe in their 0x wallet for onramps or sends from it for offramps. See the [Base chain guide](https://docs.etherfuse.com/guides/chains/base.md) and the [onramp](https://docs.etherfuse.com/guides/testing-onramps.md) and [offramp](https://docs.etherfuse.com/guides/testing-offramps.md) testing guides.
## Canonical asset metadata on GET /ramp/assets
[`GET /ramp/assets`](https://docs.etherfuse.com/api-reference/assets/list-assets) now returns a `metadata` block for every asset with the canonical `symbol`, `name`, and `image` from Solana Metaplex. The legacy top-level `symbol`, `name`, and `image` fields are still present for backward compatibility, but the new `metadata` block is the single source of truth for display metadata across all chains. The `balance` field is now a human-decimal string scaled by token decimals on every chain.
```json theme={null}
{
"assets": [
{
"identifier": "CETES:GC3CW7EDYRTWQ635VDIGY6S4ZUF5L6TQ7AA4MWS7LEQDBLUSZXV7UPS4",
"symbol": "CETES",
"name": "Cetes",
"image": "https://assets.etherfuse.com/cetes.png",
"metadata": {
"symbol": "CETES",
"name": "Cetes",
"image": "https://assets.etherfuse.com/cetes.png"
},
"balance": "1500.00"
}
]
}
```
The `metadata` object is the recommended place to read `symbol`, `name`, and `image`. The `balance` value is now a human-decimal string such as `1500.00` everywhere, not a raw integer amount.
## USTRY, EUROB, and KTB now available for swaps
The USTRY, EUROB, and KTB stablebonds are now eligible for crypto-to-crypto swap quotes on chains with DEX liquidity. They appear in the receive list from [`GET /ramp/assets`](https://docs.etherfuse.com/api-reference/assets/list-assets) and can be used as `targetAsset` or `sourceAsset` in a [`POST /ramp/quote`](https://docs.etherfuse.com/api-reference/quotes/get-quote) with `quoteAssets.type: "swap"`. If no swap route is available, the quote returns the existing `424 FailedToGetQuote` response. See the [swaps guide](https://docs.etherfuse.com/guides/testing-swaps.md).
## Restricted-country lookup endpoint
The new [`GET /lookup/restricted-countries`](https://docs.etherfuse.com/api-reference/lookup/list-restricted-countries) endpoint lists countries with effective KYC or KYB restrictions. It returns a `countries` array with ISO alpha-2 `code`, `name`, `kyc`, and `kyb` booleans. Use it to pre-check a country before onboarding or to filter country selectors in your UI.
```json theme={null}
{
"countries": [
{
"code": "AF",
"name": "Afghanistan",
"kyc": true,
"kyb": true
}
]
}
```
A country is included when KYC, KYB, or both are restricted. Country codes in the response are the same ISO alpha-2 codes used by [`GET /lookup/country-codes`](https://docs.etherfuse.com/api-reference/lookup/list-country-codes).
## KYB legal name separate from organization display name
When you create a child organization with [`POST /ramp/organization`](https://docs.etherfuse.com/api-reference/organizations/create-child-org), you can now pass `legalName` together with `country` to set the KYB company name independently of `displayName`. The `legalName` is the legal entity name used for compliance; `displayName` is the friendly org label. Renaming one does not affect the other. See the [KYB guide](https://docs.etherfuse.com/guides/kyb.md).
**Week of July 3, 2026**
## Swap USDC to and from MEXe on Solana
MEXe, the Principal Token backed by CETES, is now live on Solana mainnet, and you
can swap directly between USDC and MEXe in a single atomic transaction. Create a
[`POST /ramp/quote`](https://docs.etherfuse.com/api-reference/quotes/get-quote) with `quoteAssets.type: "swap"`,
`sourceAsset` set to the USDC mint and `targetAsset` set to the MEXe mint; the FX
conversion between USDC and CETES is handled for you. The quote returns
`requiresSwap: true` with the `exchangeRate` and `destinationAmount`, and you
execute it like any other swap. See the [swaps guide](https://docs.etherfuse.com/guides/testing-swaps.md) and
the [Solana chain guide](https://docs.etherfuse.com/guides/chains/solana.md).
## Self-serve JWT auth configuration
You can now register the issuer and JWKS URL used to verify your partner-signed
JWTs directly from the Etherfuse dashboard, instead of sending them to your
Etherfuse representative. Set them once per environment (sandbox and production
each keep their own registration), and Etherfuse fetches your JWKS from that URL
to verify incoming tokens. See [JWT authentication](https://docs.etherfuse.com/guides/jwt-authentication.md).
**Week of June 26, 2026**
## KYB partner API
Partners can now manage business organization membership and track KYB progress
through the API. Create an org with
[`POST /ramp/organization`](https://docs.etherfuse.com/api-reference/organizations/create-child-org), then
[add](https://docs.etherfuse.com/api-reference/organizations/add-organization-member.md),
[list](https://docs.etherfuse.com/api-reference/organizations/list-organization-members.md), and
[remove](https://docs.etherfuse.com/api-reference/organizations/remove-organization-member.md) members.
Track completion with
[`GET /ramp/organization/{id}/kyb/progress`](https://docs.etherfuse.com/api-reference/organizations/get-kyb-progress)
or subscribe to the new `kyb_updated` [webhook](https://docs.etherfuse.com/webhooks.md) to skip polling. See
the [KYB guide](https://docs.etherfuse.com/guides/kyb.md) for the full walkthrough.
## Business identity verification via /idv
The [`/idv` launch flow](https://docs.etherfuse.com/guides/user-launch-flows#identity-verification) now
supports business customers. Personal customers still run a liveness face scan
matched against their existing KYC ID. Business customers, who have no prior ID
on file, complete a full ID document scan and face capture in a single session.
The trigger is unchanged: a bank account with
`requiresAdditionalVerification: true`. See
[User Launch Flows](https://docs.etherfuse.com/guides/user-launch-flows.md#identity-verification).
## IDV Spanish localization
Append `lang=es` to the `/idv` launch target to render the entire identity
verification flow in Spanish, including all UI text, scan prompts, and error
messages. Omit the parameter or pass `lang=en` for English. Example target:
`/idv?bank_account_id=&lang=es`. See
[User Launch Flows](https://docs.etherfuse.com/guides/user-launch-flows.md#identity-verification).
**Week of June 19, 2026**
## Embedded wallets
Partners can now provision non-custodial wallets for their users via
`POST /ramp/wallet` and move on-chain assets without managing gas,
trustlines, or transaction construction. Each wallet is secured by a P-256
owner key that the partner (or their end-user) holds; Etherfuse proposes
transactions and the owner signs one approval per order.
The flow: provision a wallet with a public key, quote and order as usual,
then sign the `approvalMessage` from
[`GET /ramp/order/{orderId}/approvals`](https://docs.etherfuse.com/api-reference/orders/get-order-approval)
and submit it to
[`POST /ramp/order/{orderId}/approvals`](https://docs.etherfuse.com/api-reference/orders/submit-order-approval).
Reserve, trustline, and gas costs are folded into the onramp fee shown in the
quote. See the [embedded wallets guide](https://docs.etherfuse.com/guides/embedded-wallets.md) and the
[sandbox playground](https://docs.etherfuse.com/guides/embedded-wallets-walkthrough.md) for the full
walkthrough.
## SPEI tracking code on orders
The order response and `order_updated` [webhook](https://docs.etherfuse.com/webhooks.md) now include a
`trackingCode` field with the SPEI clave de rastreo for the fiat transfer.
On onramps this is the incoming deposit key; on offramps, the outgoing
payout key. Use it to look up the CEP receipt for reconciliation. The field
appears once the SPEI transfer settles. See
[`GET /ramp/order/{orderId}`](https://docs.etherfuse.com/api-reference/orders/get-order).
## KYB via JWT launch flow
Partners can now launch users directly into KYB using `target: /kyb` in the
[JWT launch flow](https://docs.etherfuse.com/guides/user-launch-flows.md). The hosted KYB renders in a
light, partner-friendly shell and shares the same compliance form as the
main dashboard.
## Standard `jti` claim for JWT replay protection
Partner JWTs now accept the standard `jti` (JWT ID, RFC 7519) claim for
replay protection alongside the existing `nonce` claim. Use either one, or
both (values must match). Existing integrations using `nonce` are
unaffected. See the
[JWT authentication guide](https://docs.etherfuse.com/guides/jwt-authentication.md).
## Verification-complete webhook
The `bank_account_updated` [webhook](https://docs.etherfuse.com/webhooks.md) now fires when biometric
verification completes and the bank becomes `compliant: true`, so partners
can react immediately without polling. Combined with the existing signal
when a bank needs verification (`compliant: false`), the webhook now covers
the full verification lifecycle.
## Larger KYC document uploads
`POST /ramp/customer/{customerId}/kyc/documents` now accepts up to 10 MB
per request (total across all images), up from the previous default. See
the [KYC docs endpoint](https://docs.etherfuse.com/api-reference/kyc/upload-kyc-docs.md) for document
requirements.
**Week of June 12, 2026**
## Partner JWT face-scan verification
Partners can now launch users straight into biometric face-scan verification
using `target: /idv` in the [JWT launch flow](https://docs.etherfuse.com/guides/user-launch-flows.md).
MXN ramps require biometric verification before fiat transfers are enabled.
## Agreement signing via launch flow
Launch users directly into electronic-signature and terms-and-conditions
agreement flows using `target: /agreements` in the
[user launch flow](https://docs.etherfuse.com/guides/user-launch-flows.md). Works with both Firebase and
partner JWT authentication.
## Auth token access and refresh pairs
`POST /auth/token` now returns an access token **and** a refresh token. Use the
refresh token to obtain a new access token without re-signing a JWT:
```json theme={null}
{
"access_token": "",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": ""
}
```
This builds on last week's auth token endpoint; the
[JWT authentication](https://docs.etherfuse.com/guides/jwt-authentication.md) guide covers the full flow.
## PT wrap and unwrap orders on Solana
Partners can now execute Principal Token wrap and unwrap orders on
[Solana](https://docs.etherfuse.com/guides/chains/solana.md) using the existing `/ramp/quote` and
`/ramp/swap` flow with PT asset identifiers — the
[testing swaps](https://docs.etherfuse.com/guides/testing-swaps.md) guide walks through it.
## KYC submission validates required fields
`POST /ramp/customer/{customer_id}/kyc` now validates required personal fields
up front — `email`, `phoneNumber`, `occupation`, `name`, `dateOfBirth`, and a
full `address`. Mexican customers (`address.country: "MX"`) must include a
`CURP`; an `RFC` is optional. Missing or invalid fields return `400` with a list
of what to fix, as detailed in the [onboarding guide](https://docs.etherfuse.com/guides/onboarding.md).
## Authentication errors link to docs
Errors from `POST /auth/token` and the JWT launch flow now include an
`error_uri` (OAuth 2.0) that points to the matching entry in the
[authentication errors](https://docs.etherfuse.com/guides/authentication-errors.md) guide, so you can jump
straight to the cause and fix.
**Week of June 5, 2026**
## Auth token endpoint
The new `POST /auth/token` endpoint issues access tokens for server-to-server
calls — prefer it over launch-flow JWTs when you need backend-only access, as
described in the [JWT authentication](https://docs.etherfuse.com/guides/jwt-authentication.md) guide.
## Scoped API key enforcement
API keys now enforce scope-based access control: keys created after June 8
default to minimal scopes, while existing keys keep working unchanged. The
[authentication](https://docs.etherfuse.com/authentication.md) reference explains the scope model.
## Bank compliance webhook signal
The `bank_account_updated` [webhook](https://docs.etherfuse.com/webhooks.md) now signals when a bank needs
additional verification: while `compliant` is `false`, the bank can't be used
until the customer completes the [verification flow](https://docs.etherfuse.com/guides/user-launch-flows.md#identity-verification).
## Biometric verification
Identity verification now supports biometric face-scan — the foundation
for the partner JWT [launch flow](https://docs.etherfuse.com/guides/user-launch-flows.md).
## Partner JWT auth launch
The partner dashboard can now launch users via partner-issued JWTs, so you can
authenticate users with your own identity provider, as set up in the
[JWT authentication](https://docs.etherfuse.com/guides/jwt-authentication.md) guide.
**Week of May 29, 2026**
## JWKS-based JWT verification
Partners can now register a JWKS endpoint for JWT-based authentication: the
platform fetches and caches public keys from your `/.well-known/jwks.json`
endpoint to verify partner-issued tokens, as described in the
[JWT authentication](https://docs.etherfuse.com/guides/jwt-authentication.md) guide.
## PT token metadata improvements
The partner dashboard now shows token metadata for all rampable assets, not just
those currently held, improving asset selection when initiating quotes.
**Week of May 22, 2026**
## Better KYB error messages
[KYB](https://docs.etherfuse.com/guides/kyb.md) validation errors now return structured, field-level messages
instead of generic failures, so partners get clearer guidance when a submission
is incomplete or invalid.
**Week of May 15, 2026**
## Self-service API keys
Approved organizations can now generate their own API keys directly in the
dashboard — no more requesting access over Slack. Once your organization is
approved through KYB, create keys from your account settings; the
[authentication](https://docs.etherfuse.com/authentication.md) reference covers usage. In sandbox,
organizations created through the portal are auto-approved, so you can generate
keys and run the full flow immediately, as noted in the
[test environment](https://docs.etherfuse.com/test-environment.md) guide.
## KYB questionnaire renderer
[KYB](https://docs.etherfuse.com/guides/kyb.md) questionnaires now render dynamically based on organization
type and jurisdiction, replacing the previous static form layout.
**Week of May 8, 2026**
## Client portal document upload
Customers can now upload KYB-required documents directly through the client
portal during [onboarding](https://docs.etherfuse.com/guides/onboarding.md), removing manual document
collection outside the platform.
## Onboarding requirement progress
The [onboarding](https://docs.etherfuse.com/guides/onboarding.md) flow now shows requirement-completion
progress, so customers see exactly which steps remain before their organization
is approved.
## Entity editing and tax ID population
Organization entity details and tax identification numbers can now be edited
after initial submission, so customers can correct mistakes without re-creating
the organization.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.