> ## Documentation Index
> Fetch the complete documentation index at: https://developer.uphold.com/llms.txt
> Use this file to discover all available pages before exploring further.
# REST API changelog
> Track Uphold REST API releases, breaking changes, enhancements, and new features. Includes RSS feed for KYC, transactions, and other endpoint updates.
export const RestEndpointSubjects = ({subjects = []}) => {
const subjectToIconMap = {
'client': 'browser',
'user:individual': 'user',
'user:business': 'briefcase'
};
if (subjects.length === 0) {
return null;
}
return <>
{subjects.map(subject =>
{subject}
)}
;
};
### Bank account numbers containing only zeros are now rejected
**Summary**
Creating a bank external account with an account number consisting entirely of zeros now returns `400 request_invalid`. Account numbers must contain between 4 and 17 digits and cannot be made up exclusively of zeros.
**Documentation**
* [Create external account](/rest-apis/core-api/external-accounts/create-external-account)
**Actions required**
* If your integration relies on accepting any 4–17 digit account number, update your validation to require at least one non-zero digit.
### USD bank deposit simulation
**Summary**
Sandbox simulation for USD bank rails is now available via the [Simulate bank deposit](/rest-apis/core-api/accounts/test-helpers/simulate-bank-deposit) test helper.
**Details**
* **ACH**: Simulate ACH deposits with optional remitter fields including `secCode` (`CCD`, `PPD`, `WEB`), `transactionType` (`Pull`, `Push`), and `serviceType` (`Standard`, `SameDay`).
* **FedNow / RTP**: Simulate FedNow and RTP deposits with optional remitter name, account number, and routing number.
* **Wire**: Simulate Wire deposits with optional remitter name and address fields.
**Documentation**
* [Simulate bank deposit](/rest-apis/core-api/accounts/test-helpers/simulate-bank-deposit)
### Invalid amounts now return `400 request_invalid`
**Summary**
Submitting a zero or negative `amount` when creating quotes or simulating bank and crypto deposits now returns `400 request_invalid`.
**Documentation**
* [Create quote](/rest-apis/core-api/transactions/create-quote)
* [Simulate bank deposit](/rest-apis/core-api/accounts/test-helpers/simulate-bank-deposit)
* [Simulate crypto deposit](/rest-apis/core-api/accounts/test-helpers/simulate-crypto-deposit)
**Actions required**
* If your integration catches `409 transaction_amount_invalid` for zero or negative amount submissions, update your error handling to expect `400 request_invalid` instead.
* If your integration does not validate the `amount` field before calling the API, add a guard to reject zero and negative values on your side. The API will now return `400 request_invalid` for these cases, but validating early produces a better user experience.
### Deprecated `partnerOnboardedAt` field when creating a user
**Summary**
The `partnerOnboardedAt` field is now deprecated and no longer required when creating a user. Your integration will keep working until the field is fully removed, but we recommend updating it now so you no longer depend on this field. See the actions below for details.
**Removal date:** 2026-08-03
**Documentation**
* [Create user](/rest-apis/core-api/users/create-user)
* [Get user](/rest-apis/core-api/users/get-user)
**Actions required**
1. Stop sending `partnerOnboardedAt` in the request body of [Create User](/rest-apis/core-api/users/create-user) requests. The field is no longer needed and will be ignored once it is fully removed.
2. If you still rely on storing and reading this date:
* Adjust your integration to send it as `metadata.partnerOnboardedAt` instead of `partnerOnboardedAt` when creating the user.
* Adjust your integration to read it from [Get metadata](/rest-apis/entity-metadata#retrieving-metadata) instead of `partnerOnboardedAt` on user objects.
If actions on step 2 do not apply to you, your integration will keep working even after the field is fully removed. However, we still recommend you take action on step 1.
### Request field validation constraints
**Summary**
Added length constraints to several request fields to ensure input values fall within supported ranges. Affected endpoints now return a `400 request_invalid` error with details about the violated constraint.
**Details**
The most impactful changes reduce previously accepted limits:
* **KYC name fields** (`givenName`, `familyName`, across identity and tax-details processes): max reduced from **200 → 100**
* **Address fields** (shared): `line1` (max 150), `line2` (max 100), `postalCode` (max 12), `city` (max 100)
Other fields received new length limits, including KYC document numbers, quote destination details, transfer references, and file content types.
### KYC verification model
**Summary**
Every KYC process is now explicit about who is responsible for verifying it — replacing the previous implicit authoritativeness model.
**Details**
* **Verification object:** Every KYC process now includes a `verification` object with `model` (`uphold-verified` or `partner-verified`), `method` (`manual` or `automatic`), `triggers`, and `dependencies`.
* **`uphold-verified` for `identity` and `proofOfAddress`:** These processes now support the `uphold-verified` model, meaning verification is driven by a third-party provider session hosted by Uphold. No explicit update can be made — Uphold is notified by the provider and updates the process automatically.
**Documentation**
* [KYC verification](/rest-apis/core-api/kyc/introduction#verification)
### Crypto risk assessment updated for AAQ v3
**Summary**
The Crypto Risk Assessment form for UK users has been refreshed to align with the latest revision of the FCA's appropriateness assessment requirements (AAQ v3). Because the form is delivered as a [dynamic form](/developer-guides/resources/dynamic-forms/introduction), integrations that render `hint.schema` and `hint.uiSchema` pick up the new questionnaire automatically.
**Details**
* New users complete the updated AAQ v3 questionnaire.
* Users who already completed the previous version are not required to reassess.
**Documentation**
* [Update crypto risk assessment](/rest-apis/core-api/kyc/update-crypto-risk-assessment)
* [Dynamic forms](/developer-guides/resources/dynamic-forms/introduction)
### Transaction and portfolio statements
**Summary**
Added two new endpoints to retrieve monthly statements for a user's portfolio holdings and transactions.
**Details**
* **Portfolio statement**: Returns holdings per asset at the end of a given period, including exchange rates.
* **Transactions statement**: Returns a paginated list of transactions for a given period, with full transaction details and exchange rates.
* Both endpoints accept `year`, `month`, and an optional `denomination` parameter (single asset code, defaults to `USD`) to control the currency used for exchange rates.
**Documentation**
* [Get portfolio statement](/rest-apis/core-api/statements/get-portfolio-statement)
* [Get transactions statement](/rest-apis/core-api/statements/get-transactions-statement)
* [Statements developer guide](/developer-guides/statements/overview)
### Bank address destination node on ACH withdrawals
**Summary**
ACH withdrawal transactions now support bank-address as a destination node, allowing withdrawals without a linked external account (e.g., microdeposit disbursements during bank account ownership verification).
**Documentation**
* [Transaction nodes](/rest-apis/core-api/transactions/introduction#transaction-nodes)
**Action required**
* 🔍 Update your integration to handle ACH withdrawal transactions where `transaction.destination.node.type` is `bank-address`.
### Dynamic forms: restructured options with field dependencies and validation rules
**Summary**
The dynamic forms used in KYC processes have been enhanced with new capabilities and a restructured options format. These changes affect the `profile` and `taxDetails` processes.
**Details**
* **Restructured `data` option:** The `dataSource` and `exclude` options have been restructured under a `data` object with `source` and `exclude` properties, with `subdivisions` added as a new supported source alongside `countries`.
* **New `format` option:** Custom display formats are now defined in the UI Schema via `options.format` (e.g., `postal-code` for postal code inputs). Standard formats like `date` remain in the JSON Schema.
* **New `rules` option:** Controls can now define client-side validation rules such as `difference-greater-than-or-equal-to-threshold` and `difference-less-than-or-equal-to-threshold`, enabling constraints like age validation.
* **New `dependsOn` option:** Controls can declare dependencies on other fields, enabling dynamic updates (e.g., subdivision list updates when country changes).
**Documentation**
* [Dynamic Forms — UI Schema](/developer-guides/resources/dynamic-forms/ui-schema#custom-options)
* [Dynamic Forms — Schema](/developer-guides/resources/dynamic-forms/schema)
* [Dynamic Forms — Rendering](/developer-guides/resources/dynamic-forms/rendering)
**Action required**
* ⚠️ **Breaking Change:** The `dataSource` option has been replaced by `data.source`, and `exclude` is now nested under `data.exclude`. Update your custom renderers to use the new structure.
* 🔍 Implement support for the new `rules`, `dependsOn`, and `format` options in your custom renderers.
### Limit details on transaction amount errors
**Summary**
Transaction amount validation errors now include a `limit` object in the error details, providing clearer information about which limit was hit and what the allowed bounds are.
* **Maximum and minimum amount limits**: The `limit` object now contains `maximumAmount` or `minimumAmount`, indicating the allowed bound for the transaction.
* **Periodic limits**: When a daily, weekly, or monthly spending limit is exceeded, the API now returns a `transaction_amount_invalid` error. The `rule` field encodes the period (e.g. `amount-exceeds-daily-limit`) and the `limit` object includes both the total allowed amount (`maximumAmount`) and the remaining allowance for the period (`remainingAmount`).
**Documentation**
* [Create quote](/rest-apis/core-api/transactions/create-quote)
* [Create transaction](/rest-apis/core-api/transactions/create-transaction)
* [Transaction amount errors](/rest-apis/core-api/transactions/introduction#transaction-amount-errors)
**Action required**
* ⚠️ **Deprecation:** Update your integrations to use `limit.maximumAmount` or `limit.minimumAmount` instead of `threshold.value` in `transaction_amount_invalid` error details.
* The `threshold` field is still returned but will be removed in a future release.
### Simulate crypto deposit
**Summary**
A new test helper endpoint is now available to simulate a crypto deposit in Sandbox. This endpoint allows you to test how your application handles incoming crypto deposits without needing to perform an actual testnet transfer.
**Documentation**
* [Simulate crypto deposit](/rest-apis/core-api/accounts/test-helpers/simulate-crypto-deposit)
* [Testnets and token faucets](/rest-apis/core-api/accounts/test-helpers/fund-sandbox-accounts)
### SEPA deposits and withdrawals
**Summary**
Introduced support for deposits and withdrawals via the SEPA network.
**Details**
* **Deposit method**: Added support for SEPA deposits.
* **External accounts**: SEPA accounts are automatically linked after the first successful deposit.
* **Withdrawals**: Quotes and transactions now support linked SEPA accounts as a destination.
* **Simulate bank deposit**: Added support for simulating SEPA deposits in the Sandbox environment.
**Documentation**
* [Networks and rails](/rest-apis/core-api/assets/introduction)
* [Set up account deposit method](/rest-apis/core-api/accounts/set-up-account-deposit-method)
* [External account support](/rest-apis/core-api/external-accounts/introduction#types-of-external-accounts)
* [Simulate bank deposit](/rest-apis/core-api/accounts/test-helpers/simulate-bank-deposit)
### ACH deposits and withdrawals
**Summary**
Introduced support for deposits and withdrawals via the Automated Clearing House (ACH), along with the FedNow and Wire US bank rails.
**Details**
* **Account deposit method**: USD accounts can now be set up with a bank deposit method using US bank rails (ACH, FedNow, Wire).
* **External accounts**: US bank accounts can now be added as external accounts for withdrawals.
* **Create quote**: The external account node now accepts an optional `network` field to select a specific US bank rail when the external account supports multiple networks.
* **Transaction nodes**: Bank deposits produce a `bank-address` node that identifies the network used for the transfer.
* **Rail constraints**: Bank rails now support an `allowed-deposit-accounts` constraint to restrict deposits to the user's default account.
**Documentation**
* [Networks and rails](/rest-apis/core-api/assets/introduction)
* [Set up account deposit method](/rest-apis/core-api/accounts/set-up-account-deposit-method)
* [Create external account](/rest-apis/core-api/external-accounts/create-external-account)
* [Create quote](/rest-apis/core-api/transactions/create-quote)
* [Transactions](/rest-apis/core-api/transactions/introduction)
### Proof-of-address support for Veriff in KYC Connector API
**Summary**
The Veriff KYC Connector now supports the `proof-of-address` process. Proof-of-address data (e.g. utility bills, bank statements) can now be ingested from Veriff PoA sessions, in addition to the previously supported `profile`, `address`, and `identity` processes.
**Documentation**
* [Veriff provider overview](/rest-apis/kyc-connector-api/veriff/overview)
* [Onboarding via KYC Connector](/developer-guides/user-onboarding/individual/via-kyc-connector)
### Filter assets and networks by type
**Summary**
The [List Assets](/rest-apis/core-api/assets/list-assets) and [List Networks](/rest-apis/core-api/assets/list-networks) endpoints now support a `type` query parameter, allowing results to be filtered by type (e.g. `crypto`, `fiat`).
**Documentation**
* [List assets](/rest-apis/core-api/assets/list-assets)
* [List networks](/rest-apis/core-api/assets/list-networks)
### Custom TTL when creating quotes
**Summary**
Partners can now specify a custom `ttl` when creating a quote, changing the platform default. This is useful when processing deposits or withdrawals through your own rails (e.g. a custom card processor), where the user needs more time to complete the transaction before the quote expires.
This feature must be enabled per organization — contact your Account Manager to request access.
**Documentation**
* [Create quote — TTL](/rest-apis/core-api/transactions/create-quote#ttl)
### Errors with `date_invalid` code now use hyphenated `details.rule` values
**Summary**
Error responses with the `date_invalid` code have been updated to use hyphenated values in the `details.rule` field for better consistency. This change affects all endpoints that return `date_invalid` errors.
**Details**
The following rule values have changed:
| Before | After |
| ----------------------------------------------- | ----------------------------------------------- |
| `difference_greater_than_threshold` | `difference-greater-than-threshold` |
| `difference_greater_than_or_equal_to_threshold` | `difference-greater-than-or-equal-to-threshold` |
| `difference_less_than_threshold` | `difference-less-than-threshold` |
| `difference_less_than_or_equal_to_threshold` | `difference-less-than-or-equal-to-threshold` |
**Action required**
* ⚠️ **Breaking Change:** Update any error handling logic that matches on `details.rule` values to use the new hyphenated format.
### List default accounts endpoint
**Summary**
Added an endpoint to list the default account for each asset owned by a user. Results can be filtered by asset code using the `asset` query parameter.
Default accounts are where funds are credited when a push deposit does not include a `reference`, or when the network does not support targeting a specific account.
**Documentation**
* [List default accounts](/rest-apis/core-api/accounts/list-default-accounts)
* [Default accounts](/rest-apis/core-api/accounts/introduction#default-accounts)
### Veriff provider support in KYC Connector API
**Summary**
Added Veriff as a new KYC provider in the KYC Connector API. Partners can now ingest and normalize KYC data from Veriff, in addition to the existing Sumsub support.
**Details**
* **Supported processes:** `profile`, `address`, and `identity`.
* **Configuration management:** New endpoints to get and set Veriff integration configuration, including session-to-process mapping and Veriff API credentials.
* **Webhooks:** Real-time notifications for ingestion lifecycle events (`ingestion-created` and `ingestion-status-changed`).
**Documentation**
* [Veriff provider overview](/rest-apis/kyc-connector-api/veriff/overview)
* [Create Veriff ingestion](/rest-apis/kyc-connector-api/veriff/create-ingestion)
* [Get Veriff configuration](/rest-apis/kyc-connector-api/veriff/get-config)
### List default accounts endpoint
**Summary**
Added an endpoint to list the default account for each asset owned by a user. Results can be filtered by asset code using the `asset` query parameter.
Default accounts are where funds are credited when a push deposit does not include a `reference`, or when the network does not support targeting a specific account.
**Documentation**
* [List default accounts](/rest-apis/core-api/accounts/list-default-accounts)
* [Default accounts](/rest-apis/core-api/accounts/introduction#default-accounts)
### Delete user endpoint requires review information
**Summary**
The [Delete User](/rest-apis/core-api/users/delete-user) endpoint now requires a request body with review information when deleting a user account.
**Details**
The request body must include a `review` object with the following properties:
* `reason` (required): The reason code for deleting the user account. Must be one of: `other`, `closure-per-user-request`, `compliance-violation`, `fraud-violation`, `business-decision`.
* `note` (optional): Additional notes about the account deletion.
**Documentation**
* [Delete User](/rest-apis/core-api/users/delete-user)
**Action required**
* ⚠️ **Breaking Change:** The endpoint now requires a request body with a `review` object. Update all calls to include `review.reason` (required) and optionally `review.note` in the request body.
### New asset information endpoint
**Summary**
Added asset information endpoint with descriptive details about each asset. The response supports locale selection via the `Accept-Language` header and format selection via the `format` query parameter (`text` by default, or `html`).
The Market Pulse API endpoints have been reorganized on the documentation for better discoverability, but the paths and schemas remain unchanged.
**Documentation**
* [Get asset information](/rest-apis/market-pulse-api/assets/get-asset-information)
### News articles limit parameter
**Summary**
Changed default news articles to 10 and added a `limit` query parameter allowing partners to control the number of articles returned. The parameter accepts values between 1 and 10.
**Documentation**
* [List general news](/rest-apis/market-pulse-api/general/list-general-news)
* [List asset news](/rest-apis/market-pulse-api/assets/list-asset-news)
### Update set metadata response code
**Summary**
We've updated the set metadata endpoint to return a 200 response code and the resulting metadata.
### Market Pulse API
**Summary**
Introduced the Market Pulse API, providing partners with access to real-time market insights and latest news.
**Documentation**
* [List asset news](/rest-apis/market-pulse-api/assets/list-asset-news)
* [List general news](/rest-apis/market-pulse-api/general/list-general-news)
* [Get asset statistics](/rest-apis/market-pulse-api/assets/get-asset-statistics)
### New KYC Connector API
**Summary**
We've launched the KYC Connector API, a new integration layer that connects third-party KYC providers with Uphold's platform. This API eliminates the need to build and maintain custom integrations by automatically ingesting and normalizing provider data into Uphold's KYC model for processes like profile, address, identity, and proof-of-address verification.
**Details**
* **Workflow-based ingestion:** Create ingestions that represent a KYC ingestion workflow for a given user and track its status via polling or webhooks.
* **Multi-process support:** Ingest profile, address, identity, and proof-of-address KYC processes in a single workflow.
* **Multi-provider support:** Ingest from multiple providers, starting with Sumsub support in this release and more providers coming soon.
**Documentation**
* [KYC Connector API Introduction](/rest-apis/kyc-connector-api/introduction)
* [Sumsub provider](/rest-apis/kyc-connector-api/sumsub/overview)
### Deprecated `amount-limit-exceeded` transaction status reason code
**Summary**
The transaction status reason code `amount-limit-exceeded` has been deprecated and replaced with `provider-maximum-limit-exceeded` to provide clearer error information when transactions fail due to provider-imposed limits.
**Documentation**
* [Transactions](/rest-apis/core-api/transactions/introduction)
**Action required**
* ⚠️ **Breaking Change:** Update your integrations to check for `provider-maximum-limit-exceeded` instead of `amount-limit-exceeded` in the `statusDetails.reason` field of failed transactions.
* ❌ The `amount-limit-exceeded` reason code will no longer be returned.
### Business user support in Widgets
**Summary**
Business user support is now available across all widgets, enabling partners to [create sessions](/rest-apis/widgets-api/payment/create-session) and embed widget experiences for business users as well as individuals.
The [Capabilities endpoints](/rest-apis/core-api/capabilities/introduction) have also been enhanced to reflect business user permissions and features.
Please note that for the [Payment Widget](/widgets/payment/introduction), card withdrawals and bank transfers for business users will be supported in a future release.
**Documentation**
* [Payment Widget](/widgets/payment/introduction)
* [Travel Rule Widget](/widgets/travel-rule/introduction)
* [Create session](/rest-apis/widgets-api/payment/create-session)
* [Capabilities endpoints](/rest-apis/core-api/capabilities/introduction)
### Metadata support in the API
**Summary**
Introduced new endpoints to manage metadata for API resources. Partners can now programmatically create, update, retrieve, and delete custom metadata for supported entities, enabling more flexible integrations and resource annotations.
This feature allows you to attach arbitrary key-value data to resources, such as accounts or users, to support custom workflows, tagging, or additional business logic.
**Documentation**
* [Entity metadata](/rest-apis/entity-metadata)
* [Core API metadata endpoints](/rest-apis/core-api/metadata)
### Travel Rule compliance for crypto transactions
**Summary**
Added Travel Rule support in the Core API: endpoints and response hints to collect the required originator and beneficiary information for crypto deposits and withdrawals.
**Details**
* **Transaction RFIs:** New endpoints to [get](/rest-apis/core-api/transactions/rfis/get-request-for-information), [list](/rest-apis/core-api/transactions/rfis/list-requests-for-information) and [update](/rest-apis/core-api/transactions/rfis/update-request-for-information) requests for information (RFIs) for crypto deposits that require Travel Rule data.
* **Quote Requirements:** Quote responses may include a `travel-rule` requirement when additional information is needed before executing a crypto withdrawal.
**Documentation**
* [Transactions](/rest-apis/core-api/transactions/introduction) — support for transactions subject to the Travel Rule
* [Create session](/rest-apis/widgets-api/travel-rule/create-session) — create `deposit-form` and `withdrawal-form` sessions for the Travel Rule widget; see the [Travel Rule Widget](/widgets/travel-rule/installation-and-setup) for installation and setup instructions.
**Actions required**
* 🔔 Monitor [`core.transaction.status-changed`](/rest-apis/core-api/transactions/webhooks/transaction-status-changed) for transactions with status `on-hold`.
* 🔍 Check for `travel-rule` requirements in quote responses when creating crypto withdrawal quotes.
### Validate network address endpoint
**Summary**
Introduced a new endpoint to programmatically validate the format of a network address before initiating a transaction. This helps ensure only valid crypto addresses are used, reducing the risk of user errors and failed transfers. Currently, validation is supported for addresses on crypto networks.
**Documentation**
* [Validate network address](/rest-apis/core-api/assets/validate-network-address)
### Support for multiple address formats in crypto deposit methods
**Summary**
The [Set up account deposit method](/rest-apis/core-api/accounts/set-up-account-deposit-method) endpoint now supports multiple crypto address formats for a single deposit method. Partners can now retrieve and display all supported address formats (e.g., `native-segwit`, `wrapped-segwit`, `pubkey-hash`) for a given network and asset, improving user experience and compatibility.
**Documentation**
* [Set up account deposit method](/rest-apis/core-api/accounts/set-up-account-deposit-method)
### New public Postman workspace
**Summary**
We've launched a new public Postman Workspace to reduce friction when accessing our API collections, enabling a smoother developer-experience.
The previous invite-only workspace will remain accessible until 25th of January 2026, but it won't receive further updates.
**Actions required**
* Follow the updated [Make your first API call](/get-started/make-your-first-api-call) guide to set up the new Postman workspace. While the setup process is largely unchanged, environment variables have been renamed for clarity.
**Documentation**
* [Make your first API call](/get-started/make-your-first-api-call)
### Skip assets cooldowns test helper
**Summary**
Introduced a new [test helper](/rest-apis/test-helpers) endpoint to instantly bypass asset cooldowns in Sandbox environments.
Asset cooldowns temporarily restrict features like `buy` and `deposit` for compliance reasons. This test helper allows you to skip the waiting period during development and testing, enabling immediate access to all asset features.
For example, when testing with GB users, you can bypass the 24-hour cooldown and immediately test deposit or purchase flows.
**Documentation**
* [Skip assets cooldowns](/rest-apis/core-api/assets/test-helpers/skip-assets-cooldowns)
* [Assets cooldowns](/rest-apis/core-api/assets/introduction#cooldowns)
### Business users
**Summary**
The API has been expanded to support business users, enabling interactions similar to those available for individual users.
At this stage, business users must be created and KYB'ed outside the API. Reach out to your Account Manager if you have a use-case where business users are needed.
Once verified, a business user can be managed through the API, including creating accounts, linking external accounts, and initiating transactions.
**Documentation**
* [Authentication - Subjects](/rest-apis/authentication#subjects)
The documentation now includes badges to indicate the supported subject types for each endpoint.
### Terms of Service update for EEA users
**Summary**
Added `general-pt-bop` as a new Terms of Service code for EEA users, available starting **December 10, 2025** at 10:00 AM UTC. The existing `general-lt-fcs` code remains accepted through the end of 2025.
**Documentation**
* [Create user](/rest-apis/core-api/users/create-user)
* [List Terms of Service](/rest-apis/core-api/terms-of-service/list-terms-of-service)
**Actions required**
* Use `general-pt-bop` for new EEA users starting December 10, 2025 at 10:00 AM UTC.
* Display updated Terms of Service to existing EEA users (previous acceptances automatically migrated).
### EU and UK tax reporting regulatory requirements
**Summary**
Enhanced KYC processes to support EU and UK tax reporting regulatory requirements. The [`profile`](./core-api/kyc/update-profile) and [`taxDetails`](./core-api/kyc/update-tax-details) processes now dynamically adapt to the user's country, collecting additional required properties for compliance.
**Enforcement dates**
* **EU users:** Starting on December 10, 2025 at 10:00 AM UTC for all users.
* **UK users:** Starting on December 30, 2025 at 10:00 AM UTC for newly registered users.
**Details**
* **Profile:** Collects place of birth and other citizenships for EU users
* **Tax Details:** Supports tax address and multiple tax residence countries with flexible data collection when tax IDs cannot be provided
* **Dynamic Forms:** Uses [JSON Forms](https://jsonforms.io/) with progressive disclosure based on user responses
**Documentation**
* [Get KYC overview](/rest-apis/core-api/kyc/get-overview)
* [Update profile](/rest-apis/core-api/kyc/update-profile)
* [Update tax details](/rest-apis/core-api/kyc/update-tax-details)
**Actions required**
* ⚠️ **Breaking Change:** `profile` object structure has changed in [Get KYC overview](/rest-apis/core-api/kyc/get-overview) and [Update profile](/rest-apis/core-api/kyc/update-profile) endpoints:
* Properties moved to `input.details` (previously `input`).
* The `citizenshipCountry` has been renamed to `primaryCitizenship`.
* New `profile.hint` object with dynamic `schema` and `uiSchema`.
* The legacy static structure is deprecated but still supported for backward compatibility. See [Update profile](/rest-apis/core-api/kyc/update-profile#body-input) for both versions.
* Update response parsing and property names in your integration.
* 🔍 Check `taxDetails.status` and use `taxDetails.hint.schema` to collect required properties.
### Crypto deposits and withdrawals
**Summary**
Expanded support for crypto funding flows, enabling seamless deposits and withdrawals in crypto.
**Details**
* **New Capabilities:** Introduced [`bank-deposits`](/rest-apis/core-api/capabilities/list-user-capabilities) and [`crypto-deposits`](/rest-apis/core-api/capabilities/list-user-capabilities). The existing `deposits` capability remains available for other deposit types.
* **Networks:** Added `network.type` to [`List Networks`](/rest-apis/core-api/assets/list-networks) as a validation hint for frontend integrations.
* **Quotes / Transactions:** The `crypto-address` node now includes an `execution` object supporting three modes — `onchain`, `offchain`, and `simulated`. Learn more about it [here](/developer-guides/crypto-transfers/withdrawal/via-rest-api#execution-modes).
* **CDD for US Users:** All users (including US users) will require to [Update customer due diligence](/rest-apis/core-api/kyc/update-customer-due-diligence) before making a crypto deposit or crypto withdrawal.
**Documentation**
* [Crypto deposit flow](/developer-guides/crypto-transfers/deposit/via-rest-api)
* [Crypto withdrawal flow](/developer-guides/crypto-transfers/withdrawal/via-rest-api)
* [Create quote with node type `crypto-address` as destination](/rest-apis/core-api/transactions/create-quote#crypto-address)
* [Transaction schema with node `execution` object](/rest-apis/core-api/transactions/create-transaction#response-transaction-origin-node-execution-transaction-hash)
**Actions required**
* ⚠️ Update your integrations to read `destination.node.execution.transactionHash` instead of `destination.node.transactionHash`.
* ❌ The old property will no longer return a value.
* 🔔 Ensure your app handles Customer Due Diligence for all users (including US users) before enabling crypto deposits or withdrawals.
### Assets cooldown ended webhook
**Summary**
Introduced a new webhook that notifies platforms when a user's asset cooldown period ends. This enables partners to update asset availability, unlock trading actions, and notify users in real-time, without relying on polling.
**Documentation**
* [Assets cooldown ended](/rest-apis/core-api/assets/webhooks/assets-cooldown-ended)
**Actions required**
* ✅ No changes needed if cooldown tracking is not required for your use case.
* 🔔 Subscribe to this webhook to refresh asset states and proactively notify users when cooldowns end.
### Topper API
**Summary**
Introduced the Topper API to enable KYC sharing between partners and the [Topper Widget](/widgets/topper/introduction), allowing partners to complete the KYC of a Topper user directly via the Core API.
**Documentation**
* [Identify a user](/rest-apis/topper-api/kyc-sharing/identify-user)
* [Create session](/rest-apis/topper-api/kyc-sharing/create-session)
### Portfolio endpoints
**Summary**
Introduced a group of endpoints to provide aggregated insights into a user's financial position across all accounts.
**Documentation**
* [Portfolio endpoints](/rest-apis/core-api/portfolio/introduction)
### FPS deposits and withdrawals
**Summary**
Introduced support for deposits and withdrawals via the Faster Payments System (FPS).
**Documentation**
* Added [`Bank`](/rest-apis/core-api/assets/list-networks#bank) to the [Network types](/rest-apis/core-api/assets/introduction#types-of-networks).
* Added [`Bank (FPS)`](/rest-apis/core-api/accounts/set-up-account-deposit-method#bank-fps) to the [Account deposit methods](/rest-apis/core-api/accounts/set-up-account-deposit-method#bank-fps).
* Added `Bank` to the [external account types](/rest-apis/core-api/external-accounts/introduction#types-of-external-accounts).
* Added [`unique-account-number-viban`](/rest-apis/core-api/capabilities/list-user-capabilities) to the list of Capabilities.
### Asset ordering
**Summary**
Introduced support for sorting assets by various criteria, including market cap, price, and price variance. This enhancement enables partners to retrieve ordered asset lists from the API, eliminating the need for custom sorting logic.
**Documentation**
* [List assets sorting](/rest-apis/core-api/assets/list-assets#sorting)
### Widgets API
**Summary**
Introduced the Widgets API, enabling partners to create secure sessions for embedding Uphold widgets in their applications.
**Documentation**
* [Create session](/rest-apis/widgets-api/payment/create-session) for the [Payment Widget](/widgets/payment/introduction).
### Asset cooldowns
**Summary**
Enhanced the [Assets](/rest-apis/core-api/assets/introduction#asset-shape) schema by introducing a `cooldowns` property to provide details about any active cooldowns applied to the asset. This allows partners to understand which assets are temporarily restricted and when they become available again.
**Documentation**
* [Cooldowns](/rest-apis/core-api/assets/introduction#cooldowns)
### Core API
**Summary**
Introduced the Core API, providing the foundational infrastructure for building financial applications on Uphold.
**Included features**
This initial release introduced all foundational components of the Core API, including:
* [Authentication endpoint](/rest-apis/core-api/authentication/request-oauth2-token) to request access tokens using the OAuth2 protocol.
* [Countries endpoints](/rest-apis/core-api/countries/introduction) to retrieve information about the supported countries.
* [Users endpoints](/rest-apis/core-api/users/create-user) to manage users, providing full CRUD capabilities and real-time webhooks to stay informed about user changes.
* [KYC endpoints](/rest-apis/core-api/kyc/introduction) to manage KYC processes, ensuring that users are compliant with regulatory requirements. It also includes webhooks to notify about KYC status changes in real time.
* [Capabilities endpoints](/rest-apis/core-api/capabilities/introduction) to retrieve capabilities, the actions and features that users can perform on the platform.
* [Terms of Service endpoints](/rest-apis/core-api/terms-of-service/introduction) to retrieve applicable Terms of Service and record user acceptance, ensuring compliance with legal requirements.
* [Files endpoints](/rest-apis/core-api/files/create-file) to generate upload and download links that support file-based KYC processes.
* [Assets endpoints](/rest-apis/core-api/assets/introduction) to retrieve information about the assets available on the platform, as well as the networks and rails used to transfer them.
* [Accounts endpoints](/rest-apis/core-api/accounts/introduction) to manage users' accounts, along with webhooks to asynchronously notify about account changes and balance updates.
* [External accounts endpoints](/rest-apis/core-api/external-accounts/introduction) to link and manage financial accounts that users own outside the platform, such as debit or credit cards, enabling both pull deposits (moving funds into Uphold) and withdrawals (sending funds out of Uphold).
* [Transactions endpoints](/rest-apis/core-api/transactions/introduction) to initiate and retrieve transactions through a unified RFQ (Request for Quote) model, supporting deposits, withdrawals, trades, and transfers across multiple asset types, along with webhooks to notify about transaction changes.
**Documentation**
* [Core API concepts](/rest-apis/core-api/concepts)