> ## Documentation Index
> Fetch the complete documentation index at: https://docs.spherepay.co/llms.txt
> Use this file to discover all available pages before exploring further.

# SpherePay API Release Notes and Changelog

> Latest SpherePay API updates, including new features, breaking changes, deprecations, compliance updates, and newly supported payment rails and assets.

Learn about all of the most recent updates to the SpherePay API Product. This is where you will find out about new features, API changes, deprecations, compliance updates, and new rails/assets. If you have any questions reach out to [support@spherepay.co](mailto:support@spherepay.co).

<Update label="July 20, 2026" tags={["Onboarding/Compliance"]}>
  ## Brazilian digital identity documents

  SpherePay now accepts two additional `documentType` values on [POST /v2/document](/api-reference/document/post) for Brazilian digital identity documents:

  * `br_digital_drivers` — digital driver's license (`CNH digital`)
  * `br_digital_id` — digital national ID (`RG digital`)

  These types are valid only with `country: "BRA"`. Upload a single image and omit the `side` field. They are supported for individual customers (`target: "customer"`) and business representatives (`target: "business_representative"`). Physical Brazilian documents continue to use `drivers` and `id_card` with front and back.

  For the full list of accepted ID types, see [Supported ID and Tax ID Types](/concepts/onboarding/identification-types).
</Update>

<Update label="July 15, 2026" tags={["API", "Customers", "KYC"]}>
  ## New: EEA verification fields for individual customers

  Individual customers resident in the EEA+ region now require `accountPurpose` (new field), `countryOfBirth`, and `nationality` under `personalInformation` before they can be submitted for verification.

  These fields are optional at creation and can be supplied later via `PATCH /v2/customer/{id}`. Until they are provided, they surface as `country_of_birth`, `nationality`, and `account_purpose` requirement codes on the customer's `kyc_profile_a` verification profile. Customers outside EEA+ are unaffected.

  Existing EEA+ customers may show these as new outstanding requirements. Backfill them with `PATCH /v2/customer/{id}` — validation runs on the merged customer state.

  Hosted verification links collect the new data automatically. Integrators using hosted links need no changes.

  For field values, enforcement, and an example request, see [EEA+ residents](/concepts/onboarding/individual-kyc#eea-residents).
</Update>

<Update label="July 15, 2026" tags={["API", "Customers", "KYB"]}>
  ## New: EEA business registration number and expanded associated-person requirements

  EEA+ incorporated businesses must provide `businessInformation.registrationNumber` plus a new per-country `registrationNumberType` (for example `siren`, `kvk`, `crn`). The registration number is stored and verified separately from the tax ID — do not submit a VAT or tax number as the registration number.

  Business representatives support a new `director` role. `ownershipPercentage` now accepts `0`–`100` (previously the minimum was 25); the `ubo` role still requires ≥ 25. EEA+ businesses must have at least one control person and complete KYC for all directors, signers, control persons, and 25%+ owners.

  Outstanding items surface as `registration_number`, `eea_control_person_present`, and `eea_ap_kyc_scope` requirement codes on `kyb_profile_a`. Representatives of EEA+ businesses must also provide `countryOfBirth` and `nationality`, which surface on each representative's `ubo_kyc_profile_a` profile.

  Existing EEA+ customers and representatives may show these as new outstanding requirements. Backfill them with `PATCH /v2/customer/{id}` and `PATCH /v2/business-representative/{id}` — validation runs on the merged state.

  Hosted verification links collect the new data automatically. Integrators using hosted links need no changes.

  For registration types, representative roles, and requirement codes, see [EEA+ businesses](/concepts/onboarding/business-kyb#eea-businesses).
</Update>

<Update label="July 6, 2026" tags={["API", "Transfers"]}>
  ## New: `statusHistory` on transfer responses

  Transfers returned by the v2 API now carry a `statusHistory` array — the full, timestamped timeline of every status the transfer has moved through, oldest first. It's included on [create](/api-reference/transfer/post), [list](/api-reference/transfer/get), and [retrieve](/api-reference/transfer/get-id) responses.

  ```json theme={"dark"}
  "statusHistory": [
    { "status": "pendingFunding", "transitionedAt": "2026-06-20T14:03:21.000Z" },
    { "status": "processing", "transitionedAt": "2026-06-20T14:05:10.000Z" }
  ]
  ```

  Until now, building a payment timeline meant recording webhook events on your side. With `statusHistory`, you can give your customers full visibility into where a payment is and how it got there from a single API read — and debugging a stalled transfer no longer means reconstructing its history. The field is additive and fully backwards compatible; no request changes are needed.
</Update>

<Update label="June 30, 2026" tags={["Transfers", "Bank Accounts"]}>
  ## SWIFT international payouts

  SpherePay now supports **SWIFT** for off-ramp USD payouts to international bank accounts. Funds are converted from stablecoin to USD and sent as a **cross-border wire over the SWIFT network**, routed to the beneficiary's bank through up to **three intermediary (correspondent) banks** when required.

  **Registering a SWIFT beneficiary bank account:**

  * Create a USD bank account with `currency: "usd"` and `networks: ["swift"]`
  * Provide `accountNumber` (IBAN or BBAN) and the beneficiary bank's `bic` (8 or 11 characters)
  * Optionally include `intermediaryBics` — an ordered list of up to 3 correspondent-bank BICs (each 8 or 11 characters, no duplicates)

  <Note>
    SWIFT access requires **verification profile C**. A USD SWIFT bank account cannot be created until profile C is approved — contact your SpherePay representative to enable it.
  </Note>

  SWIFT support includes both first-party and third-party payments. Read more about the requirements for third-party payments [here](/implementation-guides/third-party-flows).
</Update>

<Update label="June 29, 2026" tags={["Dashboard"]}>
  ## Manage offloader wallets from the dashboard

  Integrators can now generate and track offloader wallets directly from the dashboard.

  * **Generate offloader wallets** — create new offloader wallet addresses without an API call.
  * **Wallet transaction history** — view the full transaction history for each offloader wallet, including the transfers associated with it.
</Update>

<Update label="June 24, 2026" tags={["Dashboard", "Onboarding/Compliance"]}>
  ## Onboard your customers and view their external accounts

  Integrators can now create and onboard their end customers directly from the dashboard, as part of the ongoing Integrators Dashboard rollout.

  * **Create & onboard a customer** — add a business or individual end customer and run KYB or KYC verification, with a Terms of Service link per customer and live verification status.
  * **Customer external accounts** — view a customer's external accounts directly from their Customer tab.
</Update>

<Update label="June 12, 2026" tags={["Dashboard"]}>
  ## Add accounts and create transfers on behalf of your customers

  Integrators can now manage on-behalf-of activity directly from the dashboard, as part of the first phased release of the new Integrators Dashboard.

  * **Add customer accounts** — add external accounts on behalf of your customers without leaving the dashboard.
  * **Create transfers on behalf of customers** — initiate transfers from those accounts on your customers' behalf.
  * **Improved transfer details** — a refreshed confirmation and details view makes it easier to review each transfer.
</Update>

<Update label="April 11, 2026" tags={["Dashboard", "Onboarding/Compliance"]}>
  ## Redesigned dashboard navigation and Transfer flow

  The SpherePay dashboard has been overhauled with clearer navigation and a rebuilt Transfer flow.

  **Navigation updates:**

  * Onboarding has moved out of the Transfers section into its own "Get Started" sidebar item, giving customers a clearer path through the platform from day one.
  * "Bank Accounts" has been renamed to "External Accounts" to better reflect how the product works.

  **Transfer flow redesign:** The Transfer flow is now a step-based journey with a dedicated entry page. You can choose between moving your own funds, sending to recipients, or setting up Autoramp accounts.

  **Offloader Wallets:** Offloader Wallets now has a dedicated page under Autoramp Accounts, with clear product descriptions and usage guidance so customers have full context before getting started.
</Update>

<Update label="April 9, 2026" tags={["Transfers", "Bank Accounts", "Assets"]}>
  ## BRL/PIX transfers now supported

  SpherePay now supports BRL (Brazilian Real) transfers via the PIX instant payment network.

  **Supported routes:**

  * Off-ramp: USDC/USDT on Polygon, Ethereum, Base, or Tron → PIX BRL
  * On-ramp: PIX BRL → USDC/USDT on Polygon, Ethereum, Base, or Tron
  * Transfer limits: R$1.00–R$7,500.00 per transfer

  **BRL-specific constraints:**

  * Only `integratorBpsFeeRate` is supported for fees (`integratorFixedFee` is not allowed).
  * Solana is not supported for BRL transfers.
  * PIX bank accounts require `currency: "brl"` and `networks: ["pix"]`.

  <Note>
    BRL transfers require a separate verification profile (`kyc_profile_b` / `kyb_profile_b`). Contact your SpherePay representative for access.
  </Note>

  For details, see [Transfers API — BRL/PIX constraints](/concepts/transfers/overview#brlpix-transfer-constraints) and [Supported Rails & Currencies](/concepts/transfers/supported-rails).
</Update>

<Update label="April 7, 2026" tags={["Transfers", "Bank Accounts"]}>
  ## Named wire payouts

  USD wire payouts now display your business name as the sender instead of "Sphere." This is enabled automatically when a customer is approved — no manual configuration needed.

  Existing approved customers who have transacted in the last 3 months have been backfilled and will see this change reflected immediately.
</Update>

<Update label="March 12, 2026" tags={["Onboarding/Compliance"]}>
  ## API-first onboarding defaults

  SpherePay now defaults to a streamlined onboarding model for API-integrated applications. KYC and UBO liveness checks, phone and email OTP verification, and MSA signing are no longer required during onboarding when these steps are handled upstream by the integrator.

  These capabilities remain fully supported and can be enabled as opt-in requirements per application. Existing applications retain their current behavior — only new applications receive the streamlined defaults.

  For more information, see the [Customers & Onboarding](/concepts/onboarding/overview) guide.
</Update>

<Update label="March 3, 2026" tags={["Wallets", "Transfers", "Assets"]}>
  ## Offloader Wallets API and EURC support

  ### Offloader Wallets API

  Offloader Wallets are automated crypto-to-fiat conversion wallets that let your customers receive stablecoins and have them automatically settled to a linked bank account.

  **Supported stablecoins and networks:**

  * USDC on Arbitrum, Avalanche, Base, Ethereum, Polygon, and Solana
  * USDT on Ethereum and Tron
  * EURC on Base, Ethereum, and Solana

  **Supported fiat destinations:**

  * USD via ACH and Wire
  * EUR via SEPA

  For full details, see the [Offloader Wallets guide](/concepts/automation/offloader-wallets).

  ### EURC now supported

  EURC is now available across SpherePay's on-ramp and off-ramp products on Base, Ethereum, and Solana networks.
</Update>

<Update label="January 13, 2026" tags={["Onboarding/Compliance"]}>
  ## Customer API suite for business customers

  Full API support for onboarding and verifying business customers, including UBO registration — giving you complete control over the onboarding UX without redirecting customers to an external flow.

  New endpoints available:

  * [Register business representative](/api-reference/business-representative/post)
  * [Upload UBO identification documents](/api-reference/document/post)
  * [Request face liveness verification for UBO](/api-reference/enhanced-due-diligence/ubo-face-verification-link)
  * [Submit UBO for verification](/concepts/onboarding/business-kyb#poll-for-verification-result)

  For full details, see the [KYB via API guide](/concepts/onboarding/business-kyb).
</Update>

<Update label="January 7, 2026" tags={["Transfers"]}>
  ## Deprecating the Transfer Fee API

  <Warning>
    **Action required by January 14, 2026.** The `/v1/transfer/fee` endpoint will be removed on January 14, 2026. Migrate before this date to avoid disruption.
  </Warning>

  Transfer fees are now declared directly in the transfer request body. The standalone fee endpoint is no longer needed and will be retired.
</Update>

<Update label="December 1, 2025" tags={["Onboarding/Compliance"]}>
  ## Customer API suite for individual customers

  Full API support for onboarding and verifying individual customers — enabling end-to-end KYC flows inside your own product without redirecting customers to an external page.

  New endpoints available:

  * [Upload required documents](/api-reference/document/post)
  * [Send and verify email OTP](/api-reference/enhanced-due-diligence/send-verification-code)
  * [Send and verify phone OTP](/api-reference/enhanced-due-diligence/send-verification-code)
  * [Request face liveness verification](/api-reference/enhanced-due-diligence/face-verification-link)

  The [Create Customer](/api-reference/customer/post) endpoint now accepts the following fields for API-based KYC:

  * `personalInformation.taxIdentificationNumber`
  * `personalInformation.taxIdentificationNumberType`
  * `personalInformation.taxIdentificationNumberCountry`
  * `personalInformation.taxIdentificationNumberDescription`

  For full details, see the [KYC via API guide](/concepts/onboarding/individual-kyc) or [KYC via Link](/concepts/onboarding/kyc-via-link) for a faster integration path.
</Update>

<Update label="August 21, 2025" tags={["Bank Accounts", "Wallets", "Transfers"]}>
  ## Onramper Accounts API

  Onramper Accounts generate dedicated virtual bank accounts that automatically convert incoming fiat deposits into stablecoins and deliver them on-chain — no manual intervention required.

  * Generate dedicated bank accounts per customer or application
  * Automatically convert USD/EUR deposits into USDC or USDT
  * Deliver converted funds directly to any on-chain wallet address

  For full details, see the [Onramper Accounts guide](/concepts/automation/onramper-accounts).
</Update>

<Update label="June 18, 2025" tags={["Wallets", "Transfers"]}>
  ## Starknet network support

  Starknet is now supported for USDC `onRamp` and `offRamp` transfers. Use `"network": "starknet"` in the `source` or `destination` of your transfer request.

  **Off-ramp via Starknet:**

  ```json theme={"dark"}
  {
    "customer": "customer_098xxxxxxxxxxxxxxxxxxxxxxxxxxxfbb",
    "amount": "1.12",
    "source": {
      "id": "wallet_81bxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx9f3",
      "network": "starknet",
      "currency": "usdc"
    },
    "destination": {
      "id": "bankAccount_cabxxxxxxxxxxxxxxxxxxxxcxxxxx42c",
      "network": "ach",
      "currency": "usd"
    }
  }
  ```

  **On-ramp via Starknet:**

  ```json theme={"dark"}
  {
    "customer": "customer_098xxxxxxxxxxxxxxxxxxxxxxxxxxxfbb",
    "amount": "2",
    "source": {
      "id": "bankAccount_cabxxxxxxxxxxxxxxxxxxxxcxxxxx42c",
      "network": "wire",
      "currency": "usd"
    },
    "destination": {
      "id": "wallet_81bxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx9f3",
      "network": "starknet",
      "currency": "usdc"
    }
  }
  ```
</Update>

<Update label="June 3, 2025" tags={["Onboarding/Compliance"]}>
  ## Deprecating `/v1/customer`

  <Warning>
    **Action required by June 6, 2025.** The `/v1/customer` endpoint will be deprecated on June 6, 2025. Migrate to `/v2/customer` before this date.
  </Warning>

  `/v2/customer` is the new standard for creating and managing customers and will continue to receive new features. See the [Customer API reference](/api-reference/customer/post) for migration details.
</Update>