# Changelog Source: https://docs.anchorage.com/agentic-banking/changelog User-visible changes to Anchorage Agentic Banking and these docs. You can now see a received payment's screening status on the payment itself, in addition to the payments page. The label is the same one shown on the payments page: **Screened**, **Under review**, **Blocked on screening**, **Not screened**, or **Screening status unavailable**. Start at [llms.txt](https://agentic.anchorage.com/llms.txt) for the live service catalog, authenticated tools, and public API description. Use this index in place of the retired enrollment and payment walkthrough. The **Agents** page has a **Replit** tab. It gives you a one-click **Add to Replit** link and the display name and server URL to paste into Replit's **Add MCP server** dialog. After **Test & save**, Replit opens the usual consent screen where you pick the agent this connection acts as. The public merchant catalog page has the same tab for its no-sign-in endpoint. Payments you receive now show their compliance screening status next to the transaction: **Screened**, **Under review**, **Blocked on screening**, **Not screened**, or **Screening status unavailable**. Payments you send are unchanged. An agent reads a payment's approval status and details only for the payments it created. A payment another agent created is not visible to it, even when both agents belong to the same organization. This does not change what people see: org admins and members keep the same view of payments they had before. Minting is refused once an agent has ten active API keys. Revoking a key frees a slot, so you can mint a new one once you're at the limit. Minting is also rate limited: you can mint many keys in quick succession, and once that allowance is spent, further mints are refused for a short while. Either refusal shows a plain-language reason on the agent's page. An agent can now authenticate with an API key, so a client that runs with no browser connects without an OAuth consent. An org admin, or the user the agent acts for, mints a key on the agent's page and the client sends it to the MCP endpoint as a bearer token. An agent can hold several keys, one per client or workflow. The key appears once, at mint. Copy it then; if you lose it, mint another. Keys never expire, and revoking one from the same page takes effect immediately. Linked-card operations still run under an OAuth session, because a card purchase returns live card credentials and depends on a person approving that purchase in the browser. A key stops working with the agent it belongs to. Revoking or pausing the agent stops its keys immediately, and removing from your organization the member an agent acts for revokes that agent's keys. When a card's network can't set up agentic payments for cards from that card's issuer, the error on the cards settings page now names the network and the issuer, when the network reports them, instead of a bare status code. If you see this error, try a different card. On the crypto rail, where a merchant charges the payment itself rather than returning the resource, the payment completes when the merchant acknowledges it. A merchant that answers without acknowledging — no readable acknowledgement, one naming a different payment, or one reporting failure — returns an error quoting the merchant's own response, so an agent can read why. The payment reached the merchant either way, and the merchant may still take it, so paying again under a new idempotency key risks paying twice. Confirm on chain, or with Anchorage, before re-attempting — the merchant holds the credential and is the party that would submit it. Merchant enablement requests are paused. An org admin can no longer request merchant enablement, and Anchorage is not deciding open requests for now. Every decision already made stands: an org that is already merchant-enabled stays enabled, and the org settings page still shows the most recent request's status and the reason for a denial. Merchant compliance screening runs when a merchant is reviewed for activation and again on periodic rescreens. A merchant that compliance screening flags is refused at review or deactivated later, and agents can no longer pay it. A merchant deactivated on 2 or 3 September stays deactivated. Ask Anchorage to review it again. The per-payment limit on agent spend is now the smaller of two limits Anchorage sets independently: a per-payment cap, and a travel-rule block of \$2,099 that no agent payment may exceed whatever the cap is raised to. Nothing changes for you today: the cap is \$250, so the limit an agent meets on the crypto rail and the linked-card rail alike is still \$250. A payment above it is declined outright, whatever room the agent's budget has left, and no approval lifts it. What changed is the headroom: raising the cap now raises the limit as far as \$2,099 without a further change. The separate \$1,000-per-UTC-day cap per agent is unchanged. See [Stopping a runaway agent](/agentic-banking/concepts/agents#stopping-a-runaway-agent). Repeated code attempts for one email address during sign-in are now limited. If you enter a correct one-time code and it's rejected, wait a moment and try again. Merchant compliance screening was strengthened. Merchants are screened when they are reviewed for activation and again on periodic rescreens; a merchant that screening flags is declined at review or deactivated later, and agents can no longer pay it. `agentic.anchorage.com/robots.txt` and `/llms.txt` return those files. If you fetched either one before and got the sign-in page with a success status, fetch it again. `/llms.txt` is an index for agents, in the [llms.txt](https://llmstxt.org) format. It points at the unauthenticated merchant catalog, at the authenticated endpoint that holds the wallet and payment actions, and at the description of the public API. An agent looking for a service to pay for should read it first and then search the catalog, since the catalog pages render results for a query rather than listing every service. `/robots.txt` opens the landing page, the merchant catalog, `/llms.txt`, the agent instructions, the OpenClaw skill file, and the public API description to crawlers. Signed-in pages stay closed to them. [Discovery](/agentic-banking/concepts/discovery) covers both files and the unauthenticated catalog endpoint. Connecting an MCP client before you have picked an organization, on your first sign-in or when you belong to several, now sends you to the organization picker and brings you back to the consent screen once you pick one. You accept an invitation or join an organization open to your email domain if you need to, choose which agent the client links to, and the connection completes, where the client used to receive an error. Two cases still need a restart from the client: taking more than thirty minutes to pick, or a client authorize request too long for the browser to remember. Both land you on the dashboard after you pick. When a payment on one of the newly payable URLs is signed but never makes it onto the chain, the funds it reserved are released and the payment is closed automatically, once the network confirms the payment can no longer be completed. The budget it drew against becomes available again without anyone having to intervene. A payment on one of the newly payable URLs comes back carrying the merchant's own answer to it, whether the merchant accepted the payment or refused it. The response is marked as shortened only when it was actually too long to return whole, and the completion message names the rail that handled the payment. Agents do nothing differently. Agents can now pay paid URLs whose merchants quote a price in a way the platform previously could not settle. Agents do nothing differently: how to pay is read from what the URL asks for at payment time, and a cost preview prices the same URL the same way. The newly payable quotes are payable on GET requests only: a price quoted in answer to a write is refused rather than paid, because paying it would leave the agent unable to tell whether calling again repeats the change. Extra request headers on a payment or cost preview — an API key, a content type — reach the paid URL whether the agent passes them as a JSON object or as a JSON-encoded string, and a headers value of any other shape is refused with an error naming what was sent, before anything is fetched or paid. Previously the object form was silently ignored, so a payment could settle against the response the URL gives an unauthenticated caller. A request body must be a string: a body sent as an unencoded JSON document is refused with an error asking for the string form, before anything is fetched or paid. Previously that shape was silently sent as an empty body. Registering an MCP client and revoking a token are now rate-limited: repeated registration or revocation attempts are refused once they arrive faster than the limit allows. An agent's first reach of an endpoint URL nobody has registered yet is rate-limited per agent. Once an endpoint URL is registered — whether or not a payment on it completes — later calls to that URL are not limited, and a normal connect — one registration, one consent — stays well inside the limit. A registration or revocation request that hits its limit comes back as a standard HTTP 429 with a `Retry-After` header and the `X-RateLimit-Limit`, `X-RateLimit-Remaining`, and `X-RateLimit-Reset` headers, so a client can wait exactly as long as the response asks and then retry. A payment tool call that hits its limit returns an error naming the limit; retry shortly. Every request body is also capped at 2 MiB: a request that declares a body larger than that is refused with a `413` before it reaches the requested action, unless another protection, such as cross-origin request blocking, refuses it first. A request sent without a declared size that turns out to exceed the cap is refused once the cap is hit while reading it. See [Agents](/agentic-banking/concepts/agents) for the details. When a payment or cost preview cannot reach the paid URL — the hostname does not resolve, the connection is refused or unreachable, or the request times out — the agent now receives an error naming the host and the cause, so it can report the failing address instead of retrying blindly. These failures used to return the generic reference-ID error. A URL whose host points at a private or reserved network address is reported the same way as one that does not resolve. Failures inside Anchorage Agentic Banking still return the reference-ID message so support can trace them. A cost preview for a paid URL now names the payment rail its price applies to, alongside the amount, asset, chain, and recipient it already reported. A preview still moves no money, and it quotes the merchant's terms rather than clearing the payment: an agent that gets a price can still be refused when it pays, because paying applies budget, screening, and wallet checks a preview has nothing to run them against. The agent-facing tool text now says so, so an agent reports a price as a price rather than as an approval. The Deposit page fetches the details for whichever deposit option you pick, so picking one is what shows you where to send funds. The page tells you while it is fetching them. A payment to a merchant who also banks with Anchorage Agentic Banking now credits the receiving account from the same on-chain transfer that debits the payer, so a paid balance reflects the money that arrived and reconciles against the chain. Signing in identifies you, and you choose which organization to enter. Your first sign-in lands on the organization picker, which lists your pending invitations and every organization open to your email domain. Accept an invitation or click Join, and you are a member; later sign-ins take you straight to the organization you belong to. An organization is open to your email domain when it admits anyone with an address at that domain. When one matches an address you have verified and you are not a member, it appears under **Organizations you can join** with a Join button — on the organization picker when you have no organization yet, and on **Settings** once you do. You join at the standard member role, so accept the invitation instead when someone invited you as an admin. An organization you were removed from stays out of that list; ask an admin there to restore your access. A payment record now carries two budget versions: the version read when the payment started, and the version in effect when the funds were authorized. When they match, nothing changed mid-payment. When they differ, you can see which rule applied. Both appear on the payment detail page and in the payment record the API returns. This records the budget the payment draws on directly. A budget nested under a parent is still checked against its parents as well, and their versions are not recorded. A Solana payment that settles on chain in the brief moment between the merchant receiving the signed payment and Anchorage recording that delivery now completes automatically: the settlement is recognized whichever side finishes first, and the payment reaches its normal completed state with funds accounted for exactly once. Payments on Base already behave this way. In the rare case a crypto payment is interrupted at the moment of signing — before any payment authorization is recorded — the agent now receives a structured conflict explaining that reserved funds stay held and that retrying with the **same** idempotency key re-enters normal payment processing. Every org admin now has the Deposit page and its navigation entry, so any organization can fund its account by deposit. Incoming deposits still go through the same compliance screening before the funds release to your available balance. While an account is locked for review, the Deposit page now withholds its crypto deposit addresses — generating a new address and viewing the current one are both refused, and the page explains the lock in place of the address. The account's deposit history stays visible throughout, and deposits already on their way to a previously issued address still arrive and follow the usual screening steps. A frozen account is unchanged: it still accepts deposits and still shows its deposit addresses. Creating or editing a budget — including the budget created with a new agent — now requires the merchant scope to either allow all merchants or name at least one; an empty allowlist returns a clear validation message. To deliberately stop a budget's spending, pause it — pause is reversible. An existing budget with an empty allowlist can still be edited to a valid merchant scope, paused, or revoked. A Solana payment authorization is signed against recent network state and can only land on chain for a short window. When that window has provably closed and the network shows no settlement, the payment now declines automatically and its reserved funds release — matching what already happens on Base. A payment whose settlement did land on chain completes as usual. When Anchorage consolidates duplicate entries for one merchant in the merchant catalog, budgets whose allowlist names the duplicate now follow to the surviving entry automatically. The budget keeps admitting the same real-world merchant, and its cap and spend-to-date stay untouched. See [Budgets](/agentic-banking/concepts/budgets). When a paid URL quotes its price, the quote may also name the resource being sold. That name must now sit at the same address as the URL actually reached — the same host and port, so a sibling or CDN subdomain counts as a different address. A mismatch refuses the payment before anything is signed, and a cost estimate for the same URL reports the same refusal. Merchant screening is keyed by the resource's address, so a mismatched address could otherwise let one merchant present itself as another. Quotes that omit the resource name keep working unchanged. See the failure-modes table in [Crypto payments](/agentic-banking/concepts/payments#failure-modes). A pending invitation to an organization whose setup did not finish now shows **Setup incomplete** in its row instead of an Accept button — accepting becomes available the moment Anchorage completes the organization's setup. Declining stays available throughout. Signing in also now requires an organization that is ready for you: an invitation to an organization with incomplete setup admits you once that setup completes, or once another of your invitations or memberships points somewhere active. (Organizations are active from the moment they are created — see the entry below — so this state is rare and always something Anchorage resolves, never a step you wait out.) The organization chooser — including the pending-invitations view shown before you belong to an organization — now names the account you are signed in to and includes a sign-out button. Signing in with the wrong account recovers in one step: sign out from the page and sign back in with the right account. A new organization is active from the moment Anchorage creates it. Anyone it invites can accept and sign in straight away, and paying, transferring, and approving a queued payment all work immediately. Anchorage's onboarding checks on an organization and its members still run in full — they complete as the organization is set up. This replaces the separate activation step described in the 2026-07-27 entry below. An organization can still be frozen, which stops payments and transfers and pauses its agents, and approving a queued payment stays blocked until it is unfrozen. The merchant directory at `/merchants` now returns results whether or not you are signed in: a signed-out search shows the same live merchants a signed-in user sees. An invited member can now sign in for the first time with the email address the invitation was sent to, whatever its domain — a personal address, or a contractor's own company address, for example. Signing in creates their account and shows them the invitation; accepting it is what adds them to the organization, with the role the invitation specified. An expired, revoked, or already-accepted invitation grants nothing. Sign-in for a domain with an identity provider configured still goes through that provider. Someone invited from outside that domain signs in with an email code and accepts the invitation the same way. Two cases decline an invitation at the moment it is accepted: an organization that has since restricted membership to its own email domain, and one still awaiting activation. Both leave the invitation open — the first needs a fresh invitation from an address the organization now admits, the second only needs activation to finish. A new organization now starts in a review state and must be activated by Anchorage's compliance team before it can be used — signing in, paying, transferring, and approving a queued payment wait until activation. Existing organizations are already active and unaffected. Merchant availability is likewise reviewed by Anchorage's compliance team. Visiting [agentic.anchorage.com](https://agentic.anchorage.com) without being signed in now shows a short starting page linking to sign-in, these docs, the product overview, and a way to reach us. If you are already signed in, you go directly to your account. You can now switch to sandbox mode to try deposits and payments on a test network without moving real funds. Your sandbox balance is kept separate from your live one, and test-network deposit addresses differ from your live ones — copy the address shown for the network you are on. Switch back to your live account at any time. Approving a payment that is waiting in the approval queue now checks the organization's status first: if the organization is frozen, the approval is rejected with a message naming the reason and the payment stays in the queue. The same check runs when an approved payment is re-issued. Nothing is lost — once the organization is unfrozen, the approval and re-issue work as before. On a computer you can now collapse the navigation sidebar to give the page more room, and open it again from the menu button in the top bar — the sidebar stays the way you left it as you move between pages. The bar holding the logo and the light and dark theme controls now sits at the top of every screen, on computers as well as phones. The navigation menu on phones opens from the top bar, the Escape key closes it, and keyboard focus moves into the menu when it opens and returns to the menu button when it closes. Switching between light and dark themes is available directly from the top bar on phones. The sidebar also keeps the current section highlighted while you view its subpages — for example, a card's detail page keeps Cards highlighted — so it is always clear where you are. Paging through long lists — purchase requests, budgets — uses an opaque marker to fetch the next page. A corrupted or outdated marker now returns a clear invalid-request error, and restarting the listing from the first page recovers. Markers issued before this release are invalidated once at rollout, with the same recovery. This documentation now lives at docs.anchorage.com/agentic-banking. Old links under agentic.anchorage.com/docs redirect here automatically, so bookmarked pages keep working. The docs MCP server moved with it: requests to the old address are redirected with the method preserved, which most MCP clients follow transparently — if yours does not, update its configured address to docs.anchorage.com/mcp. Updating saved links is a good idea either way. Finding a merchant now happens in one place: the merchant catalog, browsable by anyone in the web UI — signed in or anonymous — and searchable by agents over MCP. An agent's results are limited to what it can actually pay on its network (mainnet or testnet), and this catalog search is now the only way an agent discovers where it can pay; the earlier separate list of allowed merchants has been retired in its favor. Each result now also shows the merchant a service belongs to, whether that merchant runs the service itself or resells another provider's, and the payment methods the service accepts, so an agent can tell up front what it's able to pay and who it's dealing with. Services from the same merchant are grouped together, and pulling a single service's detail lists the payment methods its endpoints accept. Only merchants that have cleared review appear in results. Agents can now report problems with the merchant catalog as they browse it. When an agent cannot find a merchant it expected, finds that no merchant offers what it needs, hits a service that does not work, or gets search results that miss the mark, it can send that feedback to Anchorage Agentic Banking — noting the search it tried or the service in question. The reports help us fill gaps in the catalog and fix listings that have gone stale. The Deposit page now warns when a Solana deposit address still needs its token account created. If you see the warning, complete the setup before sending funds to that Solana address. Existing ready addresses are unchanged. Agents can now make crypto payments with USDC on Solana, alongside USDC on Base — Anchorage Agentic Banking automatically settles on Solana when a merchant prices a request there. You can also fund your account by depositing USDC on Solana; it credits your account's USD balance on that network (mainnet or testnet — Base and Solana deposits feed the same balance, not separate ones per chain) and is screened like any other deposit. Existing Base payments and deposits are unchanged. After you attribute a self-hosted deposit sender once, later deposits from the same sender in your org can reuse those details automatically. The deposit still runs screening before funds become available, so a fresh review can still block the funds. Agents can now find merchants and services to pay by describing what they need — for example, "web search" or "image generation" — instead of needing a URL up front. Search returns the matching live merchants, and an agent can then pull a service's payable endpoints and documentation links to make the call. Only merchants that have cleared review appear in results. Linked-card compliance screening was strengthened. As before, a card that does not pass is refused at link time and stays in your card list, marked with the reason. When a deposit reads **Needs attribution**, you can now enter the sender's name and country directly from your deposit history. Submitting those details runs the review and releases the funds in the same step if it passes. When an agent connection does not pass compliance screening, its whole session now ends and the agent must reconnect to continue. No action required — a runaway agent is stopped at the connection. Each deposit now shows where it stands in review: **Needs attribution**, **Reviewing attribution**, **Cleared**, or **Blocked on screening**. A deposit becomes available to spend once it reads **Cleared**. The label sits next to each deposit in your deposit history, so you can tell at a glance whether funds are ready or still in review. Paid URLs that return large payloads now come back to your agent whole: responses up to 10 MB are delivered in full, so data-heavy APIs behind a paid URL work as expected. Linked-card support now runs compliance screening when a card is linked and on each purchase. A card or purchase that does not pass is refused; rejected cards stay visible in your card list for audit, marked with the reason. No action required — if a link or purchase is refused, the web UI explains why. The first public release of **Anchorage Agentic Banking**, alongside the launch of this docs site. * **Two payment rails.** Crypto payments to paid URLs on the open internet, and linked-card purchases via a one-shot credential scoped per merchant. Each agent can use both rails and picks one per spend. * **Agent-scoped budgets.** Org admins pre-authorize crypto spend with a USD spend limit and a merchant allowlist; agents see the limit, not the account balance. * **Per-purchase passkey approval for linked cards.** Each card purchase an agent requests goes through a fresh passkey approval in the browser. * **Safety cap that no approval can override.** \$1,000 per UTC day, per agent, across both rails. * **Instant revoke** of any agent from the web UI, with no grace window. * **Sign-in** via work SSO or a one-time email code. Orgs fund their account by stablecoin deposit on the supported crypto chains; each deposit credits the account as USD at confirmation. Bank linking and ACH deposits are on the roadmap. The docs cover the [agent connection flow](/agentic-banking/guides/connect-an-agent), the [concepts](/agentic-banking/concepts/agents) behind agents, accounts, budgets, payments, and linked cards, and per-action [how-to guides](/agentic-banking/guides/make-a-crypto-payment). # Accounts Source: https://docs.anchorage.com/agentic-banking/concepts/accounts Your org's USD balance per network, and how to fund it. An **account** is your org's balance on Anchorage Agentic Banking. Your org has one account per network it runs on (mainnet and/or testnet), each denominated in **USD** as a single decimal figure. Every member of the org accesses their org's accounts through their org membership. ## Where to find it The **dashboard** (the home page in [agentic.anchorage.com](https://agentic.anchorage.com) after sign-in) shows org admins the current balance for each network. It also shows the amount held against pending payments and approvals, so the dashboard displays both the **available** balance and the **held** amount separately. Plain org members don't see the org balance; their dashboard view stops at their own budget slice (see [Budgets](/agentic-banking/concepts/budgets)). ## How it gets funded The **Deposit** page in the web UI is the funding entry point. Anchorage Agentic Banking generates a deposit address for each crypto chain it supports. While an account is locked for review, its deposit addresses are unavailable — the Deposit page says so in place of the address, and both generating a new address and viewing the current one wait until the lock lifts — while the account's deposit history stays visible. Deposits arrive the same way whoever sends them. When the sender is another Anchorage Agentic Banking customer — an agent paying for your priced service, say — that payment credits your account like any other arrival, and the paying account is debited by the same transfer. A crypto deposit moves through four steps before it's spendable: 1. **Deposit** — on the Deposit page, pick the chain you're depositing on to see its address, then send funds there. Some addresses need one-time setup before they're ready to receive funds; the Deposit page warns you if yours does. Follow that warning before sending funds. Testnet and mainnet deposit addresses are different: copy the address shown for the network you are transacting on — funds sent to the other network's address land in a separate balance. 2. **Confirm** — the deposit shows as **pending** until the chain confirms (seconds in practice), then moves to **confirmed**. Anchorage Agentic Banking converts the incoming crypto to USD as part of that step, so the balance you see is always one USD figure regardless of which chain the deposit came in on. The Deposit page shows the rate each accepted token converts at, so you can check what a deposit will credit before you send it. 3. **Screen** — a confirmed deposit still needs to clear compliance screening before the funds release. Each deposit carries one of these labels: | Label | Meaning | | --------------------- | ----------------------------------------------------- | | Needs attribution | We need the sender's details before the funds release | | Reviewing attribution | Details received, review in progress | | Cleared | Review passed, funds available | | Blocked on screening | Review did not pass | When a deposit reads **Needs attribution**, the form to provide the sender's name and country appears directly in your deposit history — no extra step to open it. Submitting those details runs the review and, if it passes, releases the funds in the same step. After you attribute a self-hosted sender once, later deposits from that same sender in your org can reuse those details automatically; each deposit still runs screening before the funds become available, so a later review can still leave funds blocked. 4. **Release** — once a deposit reads **Cleared**, the funds are available to spend. Bank linking and ACH deposits are on the roadmap. ## How budgets draw against the account When an agent spends against a [budget](/agentic-banking/concepts/budgets), the spend consumes part of the account's USD balance, bounded by the budget's cap. ## What spends from the account Today, the account funds **crypto payments** — each crypto spend draws from the USD balance. Linked-card purchases settle through the card's own issuer rather than through the account, so a linked-card spend leaves the account balance alone. See [Cards](/agentic-banking/concepts/cards) for the linked-card flow. Spending directly from the account at card-accepting merchants is on the roadmap — it would let an agent use the account balance at any merchant that takes cards, with no external card linked. ## What the agent sees The agent sees the **spend limit** configured by the budget it draws on: its allotted cap and spend-to-date. See [Budgets](/agentic-banking/concepts/budgets) for the limit model. # Agents Source: https://docs.anchorage.com/agentic-banking/concepts/agents What an agent is in Anchorage Agentic Banking, and how it gets authorized to spend. An **agent** is a non-human principal that holds credentials to call Anchorage Agentic Banking's MCP tools on behalf of a user. Agents are first-class: each has its own identity, audit trail, and scoped permission to draw against [budgets](/agentic-banking/concepts/budgets). ## Authorization model An agent acts under exactly one user-org pair at a time. When the agent calls a tool, Anchorage Agentic Banking resolves three things: 1. **Who is calling** — the agent's credential identifies the agent. 2. **For whom** — the agent is scoped to one user-org membership. 3. **Against what** — the agent has a list of [budgets](/agentic-banking/concepts/budgets) it may draw on. The list of allowed budgets is returned inline when the agent introspects its identity, so an agent gets everything it needs in one call. An agent authenticates with either an OAuth session or an API key. A client gets an OAuth session by running the browser consent flow; an org admin or the agent's user mints an API key on the agent's page in the web UI. Both credentials authenticate as the same agent acting for the same user, so they reach the same tools under the same budget scoping. An API key never expires and authenticates only while its agent is usable. Minting is refused once an agent has ten active API keys. Revoked keys don't count against that limit, so revoking one frees a slot for a new one. Minting is also rate limited per user: you can mint many keys in quick succession, and once that allowance is spent, further mints are refused for a short while. [Linked-card](/agentic-banking/concepts/cards) operations run under an OAuth session only, because a card purchase returns live card credentials and depends on a person approving that purchase in the browser. ## Crypto and card rails An agent can use both [payment rails](/agentic-banking/concepts/payments); each individual spend goes through one of them explicitly, picked by the agent at call time: | Rail | Authorization | Settlement | | ----------------------------------------------- | ------------------------------- | -------------------------------------------- | | Crypto | Budget-scoped, standing consent | On-chain, from the org account's USD balance | | [Linked cards](/agentic-banking/concepts/cards) | Per-purchase passkey approval | Card-network rails via the issuer | ## Finding merchants to pay An agent can search the merchants and services it is cleared to pay by plain description of what it needs, then pull the call detail for the one it picks: * **Search by need** — the agent describes what it is looking for (for example, "web search" or "image generation") and gets back the matching merchant services. This searches only merchants that have cleared review, limited to the services payable on the agent's own network (mainnet or testnet), so every result is one the agent can actually pay. Services from the same merchant are grouped together. Each result carries: * a name, a short description, and tags * the merchant it belongs to, and whether that merchant runs the service itself or resells another provider's * the payment methods the service accepts so the agent can tell up front which services it is able to pay and who it is dealing with. * **Drill into a service** — given a service from that search, the agent pulls its payable endpoints — the URLs to pay and the payment methods they accept — plus pointers to the merchant's API and documentation, so it has what it needs to make the call. Search returns a focused, ranked set rather than the whole directory, so an agent can go from a goal to a payable endpoint in two steps. ## Where agent activity appears Every payment and approval an agent initiates shows up in the Anchorage Agentic Banking web UI under the user's history, tagged with the agent's name — budget-cap overruns on the crypto side and every linked-card purchase alike. ## Request limits A few steps around connecting and paying are rate-limited: * **Registering an MCP client and revoking a token** are rate-limited: repeated registration or revocation attempts are refused once they arrive faster than the limit allows. A normal connect — one registration, one consent — stays well inside the limit. A request that hits this limit comes back as a standard HTTP 429 with a `Retry-After` header and the `X-RateLimit-Limit`, `X-RateLimit-Remaining`, and `X-RateLimit-Reset` headers, so a client can wait exactly as long as the response asks and then retry. * **The first time an agent reaches a payment endpoint URL nobody has registered yet** counts against that agent's limit. Once an endpoint URL is registered — whether or not a payment on it completes — later calls to that URL are not limited. A new path under a merchant the agent already knows still counts as first contact if that exact URL hasn't been registered before. A payment tool call that hits this limit returns an error naming the limit; retry shortly. * **Every request body is capped at 2 MiB.** A request that declares a body larger than that is refused with a `413` before it reaches the requested action — unless another protection, such as cross-origin request blocking, refuses it first. A request sent without a declared size — for example, chunked transfer encoding — that turns out to exceed the cap is refused once the cap is hit while reading it. ## Stopping a runaway agent **\$1,000 per UTC day, per agent, across both rails** — no approval can override it. **\$250 per single payment, on both rails** — also beyond any approval. A crypto payment or a linked-card purchase above that amount is declined outright, and it stays declined however much room the agent's budget has left. Approving a payment lets that one payment proceed past the agent's budget cap, and later payments are still measured against the same cap; the per-payment limit sits above budgets and holds either way. The per-payment limit is the smaller of two limits Anchorage sets independently: a per-payment cap, $250 today, and a travel-rule block of $2,099 that no agent payment may exceed whatever the cap is raised to. Today the $250 cap is the smaller of the two, so $250 is the limit an agent meets. Raising the cap raises the limit only as far as \$2,099. The two limits are separate controls, and both apply to every payment: the daily cap bounds what an agent spends across a UTC day, the per-payment limit bounds any one payment. Anchorage checks each request against both, and the tighter one for that payment is what declines it. The daily cap is checked per request against the agent's running total for the day, so the two controls bind in different places: a $600 payment is declined by the per-payment limit even on an agent that has spent nothing that day, and a $200 payment is declined by the daily cap once that day's total is already at \$900. To spend beyond what the two limits allow, a person pays it directly. **Revoke the agent's identity** from the web UI to stop it instantly yourself, with no grace window: its credentials are permanently invalidated, every session is revoked, and tool calls fail right away. This is permanent — the revoked agent can never complete OAuth consent again, so reconnecting means creating a new agent and consenting for that one. Anchorage can also pause an agent — for example during an account freeze — which has the same immediate effect on tool calls and sessions. A paused agent shows as **Paused** in the web UI; unlike a revoke, pausing doesn't touch the agent's identity, so once Anchorage lifts the pause the same agent reconnects with a fresh OAuth consent. Both controls reach the agent's API keys too. A revoked agent's keys stop working immediately and permanently. A paused agent's keys stop working at the pause and are revoked outright, so a client that resumes after Anchorage lifts the pause needs a freshly minted key. Removing a member from your organization revokes the API keys of every agent that acts for that member, and stops those agents. # Budgets Source: https://docs.anchorage.com/agentic-banking/concepts/budgets How agents are pre-authorized to spend on the crypto rail. A **budget** is a pre-authorized USD spend limit for crypto payments. It is the spend control on the crypto rail; linked-card purchases use per-purchase passkey approval instead and are covered separately. A budget exposes a spend limit to the agent. Every budget references one [account](/agentic-banking/concepts/accounts) — the funding pool the spend draws against — but the agent only ever sees the limit, not the account's balance. ## What an org admin configures today The org settings page exposes one budget per network the org runs on (typically mainnet and/or testnet). Each budget is **org-wide**: it applies to every member of the org, and each member gets their own independent USD cap. The fields the admin sets are: * **Name** — a label (e.g., "Research travel"). * **Cap (USD)** — the per-member limit. * **Merchant scope** — either **all merchants** (every merchant Anchorage has screened and promoted to Active) or a **specific allowlist** picked from the merchant catalog. A specific allowlist must name at least one merchant; saving an empty selection is rejected. When Anchorage consolidates duplicate catalog entries for one merchant, allowlists naming the duplicate follow to the surviving entry automatically — the budget keeps admitting the same real-world merchant, and its cap and spend-to-date stay untouched. That's the full set of pilot configuration. The underlying model supports period rollover, parent/child cascades, and per-agent or shared-pool variants; those will reach the org-settings UI in later releases. ## Period Pilot budgets are **fixed**: spend accumulates against the cap until the admin raises it. Daily, weekly, and monthly calendar-period caps are on the roadmap. ## States and actions Each budget is in one of three states; the admin can transition between them from the org settings page: | State | Meaning | Available actions | | ------- | ------------------------------------ | ------------------- | | Active | Budget admits payments under the cap | Edit, Pause, Revoke | | Paused | Budget rejects all payments | Resume, Revoke | | Revoked | Budget is permanently disabled | (none) | ## Two gates per payment Every crypto payment runs through two distinct gates: 1. **Compliance gate** — the merchant must be Active and on the budget's allowlist. A failure here is a hard reject with no approval path. 2. **Spending gate** — the requested amount, plus existing holds, must fit inside the cap. See [Approvals](/agentic-banking/concepts/payments#approvals) for what happens when a payment crosses the cap. ## What the agent sees Through MCP, the agent reads its own allotted cap, its spend-to-date, and the merchant allowlist that applies to it. The agent's view is scoped to its own slice. ## What the org member sees A member's profile page in the web UI shows their own slice of each org budget — the cap, the merchants admitted, and a progress bar for spend-to-date. Each member's view stays scoped to their own slice. # Linked cards Source: https://docs.anchorage.com/agentic-banking/concepts/cards Link your own card; the agent gets a one-shot scoped credential per purchase. With **linked cards**, the agent itself completes the merchant's checkout. Anchorage Agentic Banking mints a one-shot credential scoped to that merchant; the agent uses it to fill in the merchant's own form. The charge then flows directly through the card network to the issuer. ## Cards belong to the user, not the org Each linked card is owned by exactly one user. The user links their own card through a card-verification flow (one-time code plus passkey). An agent spending on a card always spends on a card the **approving user** linked themselves — when the approval page asks the user to pick a card, the picker shows only that user's own cards. Org admins see a read-only roster of members' linked cards and can revoke on a member's behalf, but they cannot link, pause, or activate someone else's card. ## Lifecycle of a card purchase The agent requests a purchase with amount, currency, description, and a fresh idempotency key. Anchorage Agentic Banking creates a `PurchaseRequest` in `pending_approval` and returns a link the user opens to approve. The user opens the approval link in their browser, picks one of their own linked cards, and passkey-approves the purchase. The PurchaseRequest moves to `approved`. The agent waits for the verdict via a long-poll (\~25 s) using the same idempotency key. Requests expire 2 hours after creation. The agent requests credentials, passing the merchant name, URL, country code, and (for physical goods) the shipping block. Anchorage Agentic Banking returns card credentials scoped to that merchant — a **one-shot** retrieval, bound to the merchant at the credential-mint moment. The agent fills the merchant's checkout form with the credential. The merchant's payment processor charges the issuer directly through the card network. ## Approvals Every linked-card purchase requires a fresh passkey approval — see Approve and Long-poll above for the mechanics. Every pending approval also lists in the Anchorage Agentic Banking web UI under **Approvals**, alongside the direct link from the purchase request itself. When the user denies a request, the agent mints a new PurchaseRequest with a new idempotency key to try again — the denied key stays bound to the denied request. ## Scoped per purchase Linked-card spend is gated per purchase by passkey approval. Each PurchaseRequest is its own event, bounded by the amount the user approved. Card purchases also count toward the same cross-rail daily safety cap as crypto payments — see [Stopping a runaway agent](/agentic-banking/concepts/agents#stopping-a-runaway-agent). ## Idempotency `(AgentID, IdempotencyKey)` is the uniqueness shape. The same key from a different agent on the same owner mints a fresh PurchaseRequest. Use a fresh key per intent. ## What Anchorage Agentic Banking captures When the agent retrieves credentials, Anchorage Agentic Banking captures the merchant context (name, URL, country, optional products, optional shipping block) into the consumed PurchaseRequest's audit fields. The credential is bound to that merchant at issuance, so the card network rejects any use at a different merchant. ## Compliance screening Linking a card runs compliance screening before the link is registered. A card that does not pass is refused at link time and shown in your card list with the reason — the row stays visible for audit, and no purchase ever reaches that card. Re-trying the same card returns the same refusal. Each linked-card purchase runs compliance screening before the scoped credential is minted. A purchase that does not pass is refused with the reason, and the PurchaseRequest is recorded as rejected. ## Failure modes | Verdict | What it means | What to do | | ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Card compliance mismatch | The card itself did not pass compliance screening | Link a different card | | Card enrollment declined by the network | The card network could not set up the card for agentic payments with its issuer; the error names the network and the issuer when the network reports them | Link a different card | | Purchase compliance mismatch | The purchase did not pass compliance screening | Mint a new PurchaseRequest with a new idempotency key | | Credential retrieval — temporary failure | The card network was indeterminate (5xx) | Retry credential retrieval on the same PurchaseRequest — it stays `approved` | | Credential retrieval — rejected | The card network refused the request (4xx) | Mint a new PurchaseRequest with a new idempotency key | # Discovery Source: https://docs.anchorage.com/agentic-banking/concepts/discovery How an agent finds Anchorage Agentic Banking and the services it can pay, before it holds any credentials. An agent that arrives at `agentic.anchorage.com` with no account can read what the product offers and search the service catalog. Both answers come from files and an endpoint served at the domain root, so an agent author can point a client at the host and let it read the rest for itself. ## Index at the domain root `agentic.anchorage.com/llms.txt` describes this host for an agent in the [llms.txt](https://llmstxt.org) format: a short summary of what Anchorage Agentic Banking does, then a linked list of the paths an agent uses. It names the catalog endpoint, the authenticated endpoint that holds the wallet and payment actions, the public API description, and this documentation site. An agent reads it before it has a token, which makes it the entry point for a client that knows only the hostname. ## Searching the catalog without an account `agentic.anchorage.com/public-mcp` answers catalog queries over MCP without authentication. An agent describes what it needs in plain words and gets back the matching merchant services, each with its name, description, tags, owning merchant, and the payment methods it accepts. Given one of those services, the agent can pull its endpoint URLs and the merchant's API and documentation links. This route runs without a session. Results span every network and endpoints come back unfiltered, which leaves the agent two things to check. Pick the endpoint on the network you intend to transact on. And read the payment methods before treating a service as payable, because a service with no live endpoint still matches a search here and reports none. Searching is how an agent finds a service. Walking the site does not work, because the catalog pages render results for a query rather than listing every service. The same catalog is available to a connected agent, scoped to the network that agent is pinned to. That scope is what drops the services this route keeps. See [finding merchants to pay](/agentic-banking/concepts/agents#finding-merchants-to-pay) for what a connected agent gets back. Registering a wallet, checking a budget, and paying for a service need a connected agent. Those actions live behind the authenticated endpoint, which answers an unauthenticated request with a `401` and a header naming the metadata a client needs to start the sign-in flow. See [connect an agent](/agentic-banking/guides/connect-an-agent) to link a client. ## What crawlers may read `agentic.anchorage.com/robots.txt` names the public paths a crawler may read and denies everything else. The file itself is the list, so read it there rather than relying on a copy. It covers the landing page, the public paths named in the agent index, the merchant search page with its service and merchant detail pages, and the styles, webfonts, and favicon the landing page needs to render. The agent index also names the authenticated endpoint, which stays denied because a crawler without an OAuth session gets a 401 there. Denying the rest is deliberate. Almost every other path requires a session and answers a signed-out request with a sign-in page, so a crawler let loose on the host would collect thousands of near-identical sign-in pages. A crawler reading the policy the way RFC 9309 describes therefore indexes the pages meant to be public and skips the sign-in redirects. Some older crawlers read the rules more narrowly and skip the public pages as well. That costs those crawlers a listing rather than exposing anything, and an agent fetching `/llms.txt` or the catalog endpoint directly is unaffected either way. # Crypto payments Source: https://docs.anchorage.com/agentic-banking/concepts/payments How Anchorage Agentic Banking settles a paid URL on the crypto rail. Anchorage Agentic Banking's crypto rail lets an agent pay any URL that quotes a price. Merchants quote in one of two protocols and the platform speaks both: [**x402**](https://x402.org), an HTTP-402 challenge/response that turns a URL into a paywall, and the [**Machine Payments Protocol**](https://mpp.dev), which quotes in a `WWW-Authenticate: Payment` header instead. From the agent's perspective it is a single call either way: supply a URL, an idempotency key, and the budget to draw on; the platform reads which protocol the URL speaks and does the rest. ## What Anchorage Agentic Banking does for you The agent only supplies a URL. Anchorage Agentic Banking owns every merchant-side interaction: Anchorage Agentic Banking issues the agent's GET or POST to the merchant URL. On the Machine Payments Protocol only a GET is payable: a price quoted in answer to a write means the merchant already took the write, and paying for it would leave the agent unable to tell whether calling again repeats the change. The merchant responds with its price: on x402, an HTTP 402 carrying an `accepts` array of the rails it takes; on the Machine Payments Protocol, a `WWW-Authenticate: Payment` header naming one. Where the merchant offers a choice, Anchorage Agentic Banking picks the cheapest payable entry among the chains the agent is set up to pay on. Today: USDC on Base (EVM) and USDC on Solana. Compliance and spending gates run. Failures here return a structured error to the agent. Anchorage Agentic Banking signs the payment authorization for the selected chain — an off-chain EIP-3009 authorization on Base, or an SPL token transfer on Solana. A Machine Payments Protocol quote is payable on Solana only, and one naming another chain is refused. On x402, Anchorage Agentic Banking re-issues the request carrying the payment credential, and the merchant's facilitator broadcasts to chain. On the Machine Payments Protocol the credential goes straight to the merchant's charge endpoint rather than back to the agent, and the merchant's sponsor broadcasts it and pays the network fee. On x402 the merchant's response body — the paid resource — lands in the agent's tool result. On the Machine Payments Protocol what lands there is the merchant's charge-endpoint response, and Anchorage Agentic Banking reads it for the merchant's acknowledgement that it took the payment. An acknowledged charge completes; Anchorage Agentic Banking treats the acknowledgement as a claim and confirms it against the chain before the payment is final. A merchant that answers without acknowledging the charge — no readable acknowledgement, one naming a different charge, or one reporting failure — returns an error that quotes the merchant's own response. The payment reached the merchant and the merchant may still settle it, so paying again risks paying twice. Confirm settlement on chain, or with Anchorage, before re-attempting: the merchant holds the credential and is the party that would submit it, so its own answer cannot settle the question. The protected resource is not re-fetched either, so treat an acknowledged charge's body as a receipt rather than as the content. ## Approvals When a crypto payment exceeds the budget cap (but passes compliance), the payment is queued as `pending_approval`. The agent gets a structured response naming the approval; an org admin sees the request in the Anchorage Agentic Banking web UI under **Approvals** and approves or denies it. After an org admin approves, the agent polls for the verdict and then re-issues the payment with the **same** idempotency key to resume. An agent polls the verdict for the payments it created. A payment another agent created stays invisible to it, even inside the same organization. If the organization is frozen, approving a queued payment is rejected with a message naming the reason, and the payment stays in the approval queue. The same check runs when an approved payment is re-issued, so a freeze that lands after approval still stops the payment. Once the organization is unfrozen, approving or re-issuing works without any new request. Pending approvals expire after 24 hours and auto-deny. After that, the agent mints a new request with a new idempotency key to try again. Compliance failures (merchant not on allowlist, merchant inactive) are hard rejects — they stay outside the approval queue. ## Settlement After signing, the payment stays pending briefly while the merchant's side broadcasts to chain (its facilitator on x402, its sponsor on the Machine Payments Protocol). Settlement normally lands in seconds. If the signed authorization can no longer settle (it expired unused, and the chain shows no settlement), the payment declines automatically and its reserved funds normally release back to the account in the same pass — in the rare case the release needs another step, Anchorage resolves it. Either way no action is needed from the agent; an agent that still wants the resource makes a new request with a new idempotency key. A payment whose settlement did land on chain is never declined this way — it completes as usual. ## Receiving payments When your account receives a crypto payment — for example, a facilitator or another Anchorage Agentic Banking customer paying a priced URL you host — compliance screening runs on the payment before the funds become available. Each received payment carries one of these labels: | Label | Meaning | | ---------------------------- | ----------------------------------------------- | | Screened | Screening review completed; funds are available | | Under review | Screening is in progress; funds stay held | | Blocked on screening | Screening did not pass; funds stay held | | Not screened | No screening ran for this payment | | Screening status unavailable | The screening status couldn't be retrieved | A received payment shows its label on the payments page next to the transaction, and on the payment's own detail page. Outbound payments you send carry no screening label. ## Idempotency `idempotency_key` is **agent-scoped**: two calls from the same agent with the same key collapse to one transaction; the same key from a different agent is a separate transaction. Use a fresh key for every distinct intent. ## What the agent sees The agent sees the URL it asked for and the merchant response body it gets back. Negotiation detail — which protocol the merchant quoted in, the accepts array, the signed payload, the facilitator's address, the funding account's balance — is handled inside Anchorage Agentic Banking and stays internal. ## Failure modes | Verdict | What it means | What to do | | ---------------------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | Compliance mismatch | Merchant not on allowlist or inactive | Pick a different merchant | | Spending mismatch | Over the budget cap | Ask an org admin to approve, then poll for the approval verdict | | Daily safety cap reached | Hard reject, no approval path | See [Stopping a runaway agent](/agentic-banking/concepts/agents#stopping-a-runaway-agent) | | Agent deactivated | Hard reject, no approval path | See [Stopping a runaway agent](/agentic-banking/concepts/agents#stopping-a-runaway-agent) | | Account locked or frozen | Hard reject, no approval path | Contact Anchorage support — resolution requires staff action | | Insufficient account balance | Hard reject, no approval path | Fund the account, then retry | | Resource mismatch | The merchant's quote names a resource at a different address (host or port) than the URL actually reached | Hard reject, no approval path. The merchant endpoint is misconfigured; pick a different merchant | | Schema mismatch | Request body doesn't match the merchant's published schema | Fix the request body and retry with a **new** idempotency key | | Upstream 5xx | Merchant indeterminate | Retry with the **same** idempotency key — repeat calls collapse to one settlement | | Interrupted while signing | The payment stopped before an authorization was recorded; reserved funds stay held | Retry with the **same** idempotency key — contact Anchorage support if retries keep failing | # Buy with a linked card Source: https://docs.anchorage.com/agentic-banking/guides/buy-with-a-linked-card What the agent supplies on a card purchase. For mechanics, see Linked cards. A card purchase takes three steps and one human passkey approval. For the lifecycle, approval flow, ownership model, and per-purchase invariants (one-shot credentials, merchant binding, terminal denials), see [Linked cards](/agentic-banking/concepts/cards). This page lists what the agent supplies. ## Purchase request * Amount and currency. * A short merchant-facing description. * An idempotency key, unique per intent. * Optionally, a hint for which card the approval page should default to. Anchorage Agentic Banking returns a `purchase_request_id`, a `pending_approval` status, and an `approval_url` for the user to open. ## Polling and expiry The agent long-polls for the verdict (\~25 s per call) using the same idempotency key. PurchaseRequests expire 2 hours after creation; until then the agent can keep polling. ## Credential retrieval After the user approves, the agent requests credentials, providing: * Merchant name and URL. * Merchant country code. * For physical goods, the shipping block: `shipping_line1`, `shipping_line2`, `shipping_city`, `shipping_region`, `shipping_postal_code`, `shipping_country`, and an optional `products` JSON. Anchorage Agentic Banking returns a card credential — number, expiry, CVC. The agent fills the merchant's checkout form with the returned credential. # Check your budget Source: https://docs.anchorage.com/agentic-banking/guides/check-your-budget What the agent can see, and what the user sees in the UI. ## From the agent The agent gets every budget it may draw on inline on its first turn, by introspecting its own identity — see [Agents](/agentic-banking/concepts/agents) for what that introspection returns. The agent can also fetch, on demand: * Every budget it is authorized for on its network. * The primary budget's limit, spend-to-date, and period bounds (or a "no spend limit configured" placeholder). The agent sees a spend limit, not a wallet balance — see [Budgets](/agentic-banking/concepts/budgets) for how the cap is enforced. A \$1,000/day/agent safety cap also applies on top of any budget's own limit; see [Stopping a runaway agent](/agentic-banking/concepts/agents#stopping-a-runaway-agent). ## From the user See [What the org member sees](/agentic-banking/concepts/budgets#what-the-org-member-sees) for where a member's own budget slice appears in the web UI. # Connect an agent Source: https://docs.anchorage.com/agentic-banking/guides/connect-an-agent How an MCP client links to one of your agents. Anchorage Agentic Banking exposes its tools over MCP. Any MCP-capable client can connect. For programmatic discovery, see [Discovery](/agentic-banking/concepts/discovery). ## Prerequisites * A signed-in Anchorage Agentic Banking account. Sign in with your work SSO, or with a one-time code sent to your email. Repeated code attempts for one email address are limited; if a correct code is rejected, wait a moment and try again. * At least one agent created on the **Agents** page in the web UI, with a budget assigned by your org admin. ## How linking works When an MCP client connects to Anchorage Agentic Banking, it triggers an OAuth consent flow in your browser. During that flow, you pick which of your agents this MCP session is linking to. The chosen agent's identity is what the client will act under — every tool call from that session is attributed to that agent, and every spend draws on that agent's budget. If you have not picked an organization yet — on your first sign-in, or when you belong to several — the flow sends you to the organization picker first, where you pick one, accept an invitation, or join an organization open to your email domain. Picking one returns you to the consent screen, so you finish linking without restarting from the client. Two cases do need a restart from the client: taking more than thirty minutes to pick, or a client authorize request too long for the browser to remember, both of which land you on the dashboard after you pick. Registering a client and revoking a token carry request limits — see [Request limits](/agentic-banking/concepts/agents#request-limits). ## Per-client setup Per-client configuration snippets, the MCP endpoint URL, and the OAuth consent itself all live on the **Agents** page at [agentic.anchorage.com](https://agentic.anchorage.com). Tested clients today: **Claude Desktop**, **Claude Code**, **Hermes**, **ChatGPT**, **OpenClaw**, **Replit**. Any other MCP-capable client should work via the standard MCP OAuth flow. ## Headless and server-side clients A client that runs with no browser authenticates with an API key instead of an OAuth session. Mint the key on the agent's page at [agentic.anchorage.com](https://agentic.anchorage.com), copy it while the page shows it, and send it to the MCP endpoint as a bearer token in the client's `Authorization` header. Revoke it from the same page. For what a key authenticates as and which operations still need the OAuth session, see [Agents](/agentic-banking/concepts/agents#authorization-model). ## First call The agent's first turn should introspect its own identity. The response includes the agent's name, status, linked account, network scope, and its budgets — enough to start paying without a second round trip. # Make a crypto payment Source: https://docs.anchorage.com/agentic-banking/guides/make-a-crypto-payment What the agent supplies on a paid URL. For mechanics, see Crypto payments. The crypto rail is a single action. The agent supplies a URL, an idempotency key, and the budget to draw on; Anchorage Agentic Banking does the rest. For the full under-the-hood flow, approvals, and failure modes, see [Crypto payments](/agentic-banking/concepts/payments). ## What the agent provides * The URL to fetch. * An idempotency key, unique per intent. * The budget to draw on (`budget_id`). * Optional: HTTP method, headers, body. Defaults to `GET` with no body. ## Estimating cost first If the agent wants to know what a URL will cost before drawing on the budget, it can pre-flight the URL to get the price back — without committing any spend. ## Retry cheat sheet The full table lives in [Crypto payments → Failure modes](/agentic-banking/concepts/payments#failure-modes). At a glance: * **Over the budget cap** → poll for the approval verdict, then re-issue with the **same** idempotency key. * **Compliance failure** (merchant inactive / not on allowlist) → switch merchants. * **Schema mismatch** → fix the request body, retry with a **new** idempotency key. * **Upstream 5xx** → retry with the **same** idempotency key — repeat calls collapse to one settlement. * **Daily safety cap reached** → hard reject, no approval path — see [Crypto payments → Failure modes](/agentic-banking/concepts/payments#failure-modes). # Quickstart Source: https://docs.anchorage.com/agentic-banking/quickstart From zero to first agent payment. Go to [agentic.anchorage.com](https://agentic.anchorage.com), choose **Sign in**, and use your org's SSO or the account your admin set up for you. Your first sign-in lands you on the organization picker, which lists every organization you can enter: accept a pending invitation, or join an organization that is open to your email domain. Once you belong to one, signing in takes you straight there. An organization is open to your email domain when it admits anyone with an address at that domain. If one matches an address you have verified and you are not a member, it appears under **Organizations you can join**, with a Join button. You join at the standard member role, so accept an invitation instead when someone invited you as an admin. Look for it on the organization picker when you have no organization yet, and on **Settings** once you do — an organization that opens up after your first sign-in shows up there without your having to sign in again. An organization is ready to use from the moment Anchorage creates it, so there is no activation step between your invitation and your first sign-in. If an organization's setup did not finish, that invitation admits you once Anchorage completes the setup, or sooner if another of your invitations or memberships already points somewhere active; until then it waits on your pending invitations marked **Setup incomplete**. Point any MCP-capable agent at Anchorage Agentic Banking. The MCP endpoint and OAuth consent are linked from the **Agents** page in the web UI. See [Connect an agent](/agentic-banking/guides/connect-an-agent) for tested clients and per-client setup. Once connected, your agent introspects its own identity on its first turn: name, linked account, and the budgets it can spend against — everything it needs to start paying. Ask the agent to fetch a paid URL. The agent pays the URL using its standing budget. Anchorage Agentic Banking checks the budget and the merchant allowlist, settles the payment, and returns the merchant's response to the agent — which returns it to you. For card purchases, the agent requests a purchase and you passkey-approve the spend on a browser approval page. ## Next steps How agents are pre-authorized to spend, and what the spend limit means. Per-client setup walkthroughs. The mechanics behind the crypto rail. Per-purchase passkey approval and one-shot credentials. How an agent is authorized, and how to revoke one instantly. # Verifying addresses Source: https://docs.anchorage.com/knowledge-base/api-reference/address-verification Verify deposit address authenticity and integrity using Anchorage Digital's V1 and V2 signature schemes. The addresses REST API endpoints return signatures of the address strings and other metadata that prove the address was generated by Anchorage Digital for your organization. Verify the address signature and all accompanying metadata before using any address. This confirms authenticity and integrity. ## Signature schemes The API supports two address verification schemes. Check the `signatureVersion` field to determine which applies. | Scheme | How it works | | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **V1** | Verify signature against a fixed Ed25519 public key unique to your organization, distributed out-of-band by Anchorage Digital. Must be kept tamper-proof. | | **V2** | Verify signature against the public key of the leaf certificate in an X.509 certificate chain returned with the response, then verify the chain against the Anchorage Digital Address Signing Root CA (hard-coded by the client). | *** ## V1 address signature verification ### Steps 1. **Verify the signature:** * Decode `addressSignaturePayload` from hex to bytes. * Decode `signature` from hex to bytes. * Using your organization's fixed public key, verify that `signatureBytes` is a valid Ed25519 signature of `addressSignaturePayloadBytes`. 2. **Verify the signed address matches the address to be used:** * Decode `addressSignaturePayload` from hex to bytes. * Parse the bytes as JSON. * Verify the address matches the `TextAddress` property in the JSON. Validating the signature alone is insufficient. You must also confirm that `TextAddress` in the decoded payload matches the address you intend to use. ### V1 signed payload fields | Field | Description | | ------------- | ---------------------------------------- | | `TextAddress` | The text format of the on-chain address. | ```json theme={null} { "TextAddress": "2N19AcihQ1a4MxQW658UFHTioUNnMkiHPkw" } ``` ### Sample V1 validation code ```go theme={null} package main import ( "crypto/ed25519" "encoding/hex" "encoding/json" "fmt" ) // V1SignedPayload represents the JSON structure in the addressSignaturePayload for V1 signatures type V1SignedPayload struct { TextAddress string `json:"TextAddress"` } // verifyV1AddressSignature verifies a V1 address signature. // // Parameters: // - address: The address string from the API response // - addressSignaturePayload: Hex-encoded bytes that were signed // - signature: Hex-encoded Ed25519 signature // - orgPublicKeyHex: Hex-encoded Ed25519 public key for your organization (obtained out-of-band) // // Returns an error if verification fails. func verifyV1AddressSignature(address, addressSignaturePayload, signature, orgPublicKeyHex string) error { // Step 1: Check the validity of the signature // Decode the addressSignaturePayload from hex to bytes payloadBytes, err := hex.DecodeString(addressSignaturePayload) if err != nil { return fmt.Errorf("failed to decode addressSignaturePayload: %w", err) } // Decode the signature from hex to bytes signatureBytes, err := hex.DecodeString(signature) if err != nil { return fmt.Errorf("failed to decode signature: %w", err) } // Decode the organization public key from hex publicKeyBytes, err := hex.DecodeString(orgPublicKeyHex) if err != nil { return fmt.Errorf("failed to decode organization public key: %w", err) } if len(publicKeyBytes) != ed25519.PublicKeySize { return fmt.Errorf("invalid public key size: got %d bytes, expected %d", len(publicKeyBytes), ed25519.PublicKeySize) } publicKey := ed25519.PublicKey(publicKeyBytes) // Verify the Ed25519 signature if !ed25519.Verify(publicKey, payloadBytes, signatureBytes) { return fmt.Errorf("signature verification failed") } // Step 2: Verify the signed address matches the address to be used // Parse the payload bytes as JSON var signedPayload V1SignedPayload if err := json.Unmarshal(payloadBytes, &signedPayload); err != nil { return fmt.Errorf("failed to parse signed payload: %w", err) } // Verify the TextAddress matches if signedPayload.TextAddress != address { return fmt.Errorf("signed TextAddress does not match: signed=%q, expected=%q", signedPayload.TextAddress, address) } return nil } func main() { // Sample API response data address := "2N19AcihQ1a4MxQW658UFHTioUNnMkiHPkw" addressSignaturePayload := "7b225465787441646472657373223a22324e313941636968513161344d78515736353855464854696f554e6e4d6b6948506b77227d" signature := "b18f6848dc0fef01a069e7ac26046383bf5cd130203994dc2d72b5a9097351b1e8b67115b63124fbc8c16673566416a635913c670b676089339c62a7824baa03" // Organization public key - obtained out-of-band from Anchorage Digital beforehand // Unique per Organization, fixed for the lifetime of that Organization // Must be kept tamper-proof orgPublicKeyHex := "8a88e3dd7409f195fd52db2d3cba5d72ca6709bf1d94121bf3748801b40f6f5c" // Verify the signature if err := verifyV1AddressSignature(address, addressSignaturePayload, signature, orgPublicKeyHex); err != nil { fmt.Printf("✗ V1 Address signature verification failed: %v\n", err) return } fmt.Println("✓ V1 Address signature verified successfully!") fmt.Printf(" Address: %s\n", address) fmt.Println("\nYou may now safely use this address for deposits.") } ``` *** ## V2 address signature verification Addresses with `signatureVersion: V2` include a `certChain` field containing an X.509 certificate chain in PEM format. ### Steps 1. **Verify the certificate chain:** * Parse `certChain` as PEM-encoded X.509 certificates. * Verify the chain from the leaf to the trusted Anchorage Digital Root CA. * Verify all certificates are temporally valid (both `notAfter` and `notBefore`). * Verify the leaf certificate's Subject Alternative Names include `address-provider.anchorage.internal`. * Verify the leaf certificate's `KeyUsage` includes both `digitalSignature` and `nonRepudiation` (also known as `contentCommitment`). * Extract the public key from the leaf certificate. Currently only Ed25519 keys are supported, but this may change. The leaf certificate is at index 0, followed by zero or more intermediates. The root cert is excluded from the response. The number of certificates in the chain may change. Follow standard X.509 verification procedures — not all libraries perform all checks by default. 2. **Verify the signature:** * Decode `addressSignaturePayload` from hex to bytes. * Decode `signature` from hex to bytes. * Using the leaf certificate's public key, verify `signatureBytes` is a valid signature of the payload bytes. 3. **Verify the signed details:** * Parse `addressSignaturePayload` bytes as JSON. * Verify `SignatureExpiresAt` ≥ current UTC Unix timestamp. * Verify `TextAddress` matches the address to be used. * Verify `VaultId` matches your expected Vault ID. * Verify `NetworkId` matches the expected network for this address. `NetworkName` is included for human readability and does not need to be verified. Do not use a "strict" JSON parser that rejects extra properties — future versions may add fields. Anchorage Digital periodically refreshes V2 signatures and the Address Signing Root CA before expiration. The deposit address itself will not change — only the signature, certificate chain, and Root CA are updated. ### V2 signed payload fields | Field | Description | | -------------------- | ------------------------------------------------------------- | | `TextAddress` | The text format of the on-chain address. | | `VaultId` | Identifies the vault this address belongs to. | | `NetworkId` | Identifies the network this address can receive deposits on. | | `NetworkName` | Human-readable version of `NetworkId`. | | `SignatureExpiresAt` | Unix timestamp after which the signature must not be trusted. | ```json theme={null} { "VaultId": "dae6089e7c0836705f0562af0f1e4e1f", "TextAddress": "bcrt1q709skemgf5skpsnysvgme2s3ztehkutl390yl0wp29lnmum5uw7qg0qrwm", "NetworkName": "Bitcoin Regnet", "NetworkId": "BTC_R", "SignatureExpiresAt": 1769450713 } ``` ### Anchorage Digital Address Signing Root CAs Hard-code the appropriate Root CA for the environment you are targeting. This value must be tamper-proof. ``` -----BEGIN CERTIFICATE----- MIIBXTCCAQ+gAwIBAgIUQZI+MSvYTXQHra+3OAKnwAMzotUwBQYDK2VwMCAxHjAc BgNVBAMMFWNhLmFuY2hvcmFnZS5pbnRlcm5hbDAeFw0yNjAxMjYwMDAwMDBaFw0y NzAxMjYwMDAwMDBaMCAxHjAcBgNVBAMMFWNhLmFuY2hvcmFnZS5pbnRlcm5hbDAq MAUGAytlcAMhADTh1nctgIHtAKNW8ww/bY606pJ3OP2dyZYcQrU2kG5jo1swWTAP BgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwICBDAUBgorBgEEAYaNHwEBBAYW BHJvb3QwIAYDVR0RBBkwF4IVY2EuYW5jaG9yYWdlLmludGVybmFsMAUGAytlcANB ANkkdudEjH9RTKbRAxrRXyMSS/TgmdSrAVYOZzoRDJlyc+5oD+a0pmmwWVe86xZi 37YbN1GzVlXcJAPpV6ceEQU= -----END CERTIFICATE----- ``` ``` -----BEGIN CERTIFICATE----- MIIBXDCCAQ6gAwIBAgITOfTQ4rYUsghgvdl8YCJSC67uGDAFBgMrZXAwIDEeMBwG A1UEAwwVY2EuYW5jaG9yYWdlLmludGVybmFsMB4XDTI2MDEyNDAwMDAwMFoXDTI3 MDEyNDAwMDAwMFowIDEeMBwGA1UEAwwVY2EuYW5jaG9yYWdlLmludGVybmFsMCow BQYDK2VwAyEAPlBo2/+kPPL0WRpT+B/yHsU25AN/M6HP2bzC61yHb4ajWzBZMA8G A1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgIEMBQGCisGAQQBho0fAQEEBhYE cm9vdDAgBgNVHREEGTAXghVjYS5hbmNob3JhZ2UuaW50ZXJuYWwwBQYDK2VwA0EA YsJxVI9n42liCF9f+Ou7uuC1QGFwaHwFsfOm0WFofSlE1trWqzj4ruzjPYSRJc8H t2A7XCAfXkG0mzKpL/wQDg== -----END CERTIFICATE----- ``` ### Sample V2 validation code ```go theme={null} package main import ( "crypto/ed25519" "crypto/x509" "encoding/hex" "encoding/json" "encoding/pem" "fmt" "time" ) // V2SignedPayload represents the JSON structure in the addressSignaturePayload for V2 signatures type V2SignedPayload struct { TextAddress string `json:"TextAddress"` VaultId string `json:"VaultId"` NetworkId string `json:"NetworkId"` NetworkName string `json:"NetworkName"` SignatureExpiresAt int64 `json:"SignatureExpiresAt"` // Unix timestamp } // verifyV2AddressSignature verifies a V2 address signature. // // Parameters: // - now: The "current" time. Note that conforming implementations must use // a trusted source for the current time. // - address: The address string from the API response // - addressSignaturePayload: Hex-encoded bytes that were signed // - signature: Hex-encoded signature // - certChainPEM: PEM-encoded certificate chain (leaf first, then intermediates) // - rootCAPEM: PEM-encoded Root CA certificate (hard-coded by client) // - expectedVaultId: Your Vault ID to verify against the signed VaultId // - expectedNetworkId: Expected network ID for this address (e.g., "BTC", "ETH") // // Returns an error if verification fails. func verifyV2AddressSignature( now time.Time, address, addressSignaturePayload, signature, certChainPEM, rootCAPEM, expectedVaultId, expectedNetworkId string, ) error { // Step 1: Verify the certificate chain // Parse the certificate chain from PEM certs, err := parsePEMCertificates([]byte(certChainPEM)) if err != nil { return fmt.Errorf("failed to parse certificate chain: %w", err) } if len(certs) == 0 { return fmt.Errorf("certificate chain is empty") } leafCert := certs[0] var intermediateCerts []*x509.Certificate if len(certs) > 1 { intermediateCerts = certs[1:] } // Parse the Root CA rootCACerts, err := parsePEMCertificates([]byte(rootCAPEM)) if err != nil { return fmt.Errorf("failed to parse Root CA: %w", err) } if len(rootCACerts) != 1 { return fmt.Errorf("expected exactly one Root CA certificate, got %d", len(rootCACerts)) } rootCA := rootCACerts[0] // Verify the leaf certificate's KeyUsage includes both // digitalSignature and nonRepudiation (AKA contentCommitment) if leafCert.KeyUsage&x509.KeyUsageDigitalSignature == 0 { return fmt.Errorf("leaf certificate KeyUsage missing DigitalSignature") } if leafCert.KeyUsage&x509.KeyUsageContentCommitment == 0 { return fmt.Errorf("leaf certificate KeyUsage missing NonRepudiation (ContentCommitment)") } // Verify the certificate chain from leaf to Root CA roots := x509.NewCertPool() roots.AddCert(rootCA) intermediates := x509.NewCertPool() for _, cert := range intermediateCerts { intermediates.AddCert(cert) } // NOTE: Not all x509 libraries are created equal and are not // guaranteed to verify exactly the same things! // // Always review the library you plan to use and ensure it covers the // checks described in the User Guide! // // For example, the Go implementation checks all Certificates for // temporal validity (notBefore and notAfter against CurrentTime), for // valid signatures up the chain, and checks that the Subject // Alternative Names include the values in DNSNames below. // // However it does not check the KeyUsage bits, hence the additional // checks above. opts := x509.VerifyOptions{ DNSNames: []string{"address-provider.anchorage.internal"}, Roots: roots, Intermediates: intermediates, CurrentTime: now, // NOTE: This allows for any Extended Key Usage, but does not // check the Key Usage bits, hence the additional checks above. KeyUsages: []x509.ExtKeyUsage{x509.ExtKeyUsageAny}, } if _, err := leafCert.Verify(opts); err != nil { return fmt.Errorf("certificate chain verification failed: %w", err) } // Extract the public key from the leaf certificate leafPublicKey, ok := leafCert.PublicKey.(ed25519.PublicKey) if !ok { return fmt.Errorf("leaf certificate does not use Ed25519 (got type %T)", leafCert.PublicKey) } // Step 2: Verify the signature // Decode the addressSignaturePayload from hex to bytes payloadBytes, err := hex.DecodeString(addressSignaturePayload) if err != nil { return fmt.Errorf("failed to decode addressSignaturePayload: %w", err) } // Decode the signature from hex to bytes signatureBytes, err := hex.DecodeString(signature) if err != nil { return fmt.Errorf("failed to decode signature: %w", err) } // Verify the signature using the leaf certificate's public key if !ed25519.Verify(leafPublicKey, payloadBytes, signatureBytes) { return fmt.Errorf("signature verification failed") } // Step 3: Verify the signed details // Parse the payload bytes as JSON var signedPayload V2SignedPayload if err := json.Unmarshal(payloadBytes, &signedPayload); err != nil { return fmt.Errorf("failed to parse signed payload: %w", err) } // Verify SignatureExpiresAt is not in the past if now.Unix() > signedPayload.SignatureExpiresAt { expiryTime := time.Unix(signedPayload.SignatureExpiresAt, 0) return fmt.Errorf("signature has expired at %s", expiryTime) } // Verify TextAddress matches if signedPayload.TextAddress != address { return fmt.Errorf("signed TextAddress does not match: signed=%q, expected=%q", signedPayload.TextAddress, address) } // Verify VaultId matches if signedPayload.VaultId != expectedVaultId { return fmt.Errorf("signed VaultId does not match: signed=%q, expected=%q", signedPayload.VaultId, expectedVaultId) } // Verify NetworkId matches if signedPayload.NetworkId != expectedNetworkId { return fmt.Errorf("signed NetworkId does not match: signed=%q, expected=%q", signedPayload.NetworkId, expectedNetworkId) } return nil } // parsePEMCertificates parses PEM-encoded certificates and returns them as a slice func parsePEMCertificates(pemData []byte) ([]*x509.Certificate, error) { var certs []*x509.Certificate for { block, rest := pem.Decode(pemData) if block == nil { break } if block.Type != "CERTIFICATE" { pemData = rest continue } cert, err := x509.ParseCertificate(block.Bytes) if err != nil { return nil, fmt.Errorf("failed to parse certificate: %w", err) } certs = append(certs, cert) pemData = rest } return certs, nil } func main() { // Sample API response data address := "bcrt1q709skemgf5skpsnysvgme2s3ztehkutl390yl0wp29lnmum5uw7qg0qrwm" addressSignaturePayload := "7b225661756c744964223a226461653630383965376330383336373035663035363261663066316534653166222c225465787441646472657373223a22626372743171373039736b656d676635736b70736e797376676d653273337a7465686b75746c333930796c30777032396c6e6d756d357577377167307172776d222c224e6574776f726b4e616d65223a22426974636f696e205265676e6574222c224e6574776f726b4964223a224254435f52222c225369676e6174757265457870697265734174223a313736393435303731337d" signature := "951eb2fb560e660aa9c3d1ccd120d3ad1a19d90d8747347057e48bf174330eb386089e3232d822fd66b8183cce8059c91183afde299b920a0e0c05c5b167360e" certChainPEM := `-----BEGIN CERTIFICATE----- MIIBYTCCAROgAwIBAgIUMLKt+K9eFku+P7BbefE1xAHg0hcwBQYDK2VwMAAwHhcN MjYwMTI2MTcwNDEzWhcNMjcwMTI2MTcwNTEzWjAuMSwwKgYDVQQDEyNhZGRyZXNz LXByb3ZpZGVyLmFuY2hvcmFnZS5pbnRlcm5hbDAqMAUGAytlcAMhAPsgM70aWFYs ZaLHawtYJpl42BkiTLyCq96+OXe4FxrVo3EwbzAOBgNVHQ8BAf8EBAMCBsAwDAYD VR0TAQH/BAIwADAfBgNVHSMEGDAWgBS0usSFeB2gjC+wcowtxN3MeKSH7zAuBgNV HREEJzAlgiNhZGRyZXNzLXByb3ZpZGVyLmFuY2hvcmFnZS5pbnRlcm5hbDAFBgMr ZXADQQCXmvIkuPnUgCHxWmFmzvgWdv9lUlt84oZCel+OeJW9n8PR88tGxAcD1E3+ KDBXVpO0GcRA0W9+xqqICAo2ROEJ -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIBKDCB26ADAgECAhRGsD05KldIse+uIEa976AijTqlxjAFBgMrZXAwADAeFw0y NjAxMjYxNzA0MTNaFw0yNzAxMjYxNzA1MTNaMAAwKjAFBgMrZXADIQCNpyY5Sr21 FHNvvLkBKG8AEMKdhqtajmV5d2QaZlmtAqNnMGUwDgYDVR0PAQH/BAQDAgIEMBIG A1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFLS6xIV4HaCML7ByjC3E3cx4pIfv MCAga1UdEQEB/wQWMBSCEmFuY2hvcmFnZS5pbnRlcm5hbDAFBgMrZXADQQCIgw6k LMIwhd3ACjG03cJ5z/ZZp8aXXycFq2ZC9TLhieJ3rncyMH6ZdyJ3Ai1eVaHs4vn DCv54Vdh83vvSky4K -----END CERTIFICATE----- ` // NOTE: This is a FAKE Root CA used just for this example. // NOTE: Conforming client implementations should hard-code the real // Anchorage Digital Address Signing Root CA for the environment they // are making requests to. rootCAPEM := `-----BEGIN CERTIFICATE----- MIIBGzCBzqADAgECAhQ2qQwArneTuF0dbNDs8i/ExuyW2DAFBgMrZXAwADAeFw0y NjAxMjYxNzA0MTNaFw0yNzAxMjYxNzA1MTNaMAAwKjAFBgMrZXADIQB+gEnytXKn uAMonIWGWnB0qyTqa0aw3l9u5VRbu86UgaNaMFgwDgYDVR0PAQH/BAQDAgIEMA8G A1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFOj64tL1teJHkojsiblnnK34Tw+EMBYGN A1UdEQEB/wQMMAqCCGludGVybmFsMAUGAytlcANBAAg2IcVEXmWKSivhUNSatNfM mASxi83QscIuyP/sIW2sRIuCqQJoo9lN6TaxzyV62cQMzthFOCZcgRE+k0JV7Ao= -----END CERTIFICATE----- ` // Your Vault ID - obtained from your application context expectedVaultId := "dae6089e7c0836705f0562af0f1e4e1f" // Expected network ID for this address expectedNetworkId := "BTC_R" // Implementations should use the actual current time // now := time.Now() now := time.Unix(1769450600, 0) // Fake time so that this example passes. // Verify the signature if err := verifyV2AddressSignature( now, address, addressSignaturePayload, signature, certChainPEM, rootCAPEM, expectedVaultId, expectedNetworkId, ); err != nil { fmt.Printf("✗ V2 Address signature verification failed: %v\n", err) return } fmt.Println("✓ V2 Address signature verified successfully!") fmt.Printf(" Address: %s\n", address) fmt.Printf(" Vault ID: %s\n", expectedVaultId) fmt.Printf(" Network: %s\n", expectedNetworkId) fmt.Println("\nYou may now safely use this address for deposits.") } ``` # Authentication Source: https://docs.anchorage.com/knowledge-base/api-reference/authentication Authenticate Anchorage Digital API requests with API keys and signatures. All API requests require the `Api-Access-Key` header. ```http theme={null} Api-Access-Key: YOUR_API_KEY ``` Some endpoints also require: ```http theme={null} Api-Timestamp: 1577880000 Api-Signature: 4bf42054bf7db1f8... ``` For how permission groups, keys, and signatures work together, see [API setup](/knowledge-base/platform/developers/setting-up) and [Request signing](/knowledge-base/platform/developers/request-signing). ## How authentication works API authentication has three layers. Every request needs all the layers that apply to the endpoint you're calling. A permission group defines which vaults a key can access and what operations it can perform. An access key identifies the caller and is required on every request. An Ed25519 signature authorizes sensitive endpoints, such as withdrawals. # API Changelog Source: https://docs.anchorage.com/knowledge-base/api-reference/changelog Subscribe to Anchorage API updates, additions, and breaking changes. [2026](/knowledge-base/api-reference/changelog) · [2025](/knowledge-base/api-reference/changelog-2025) · [2024](/knowledge-base/api-reference/changelog-2024) ## Clarified `dateTime` Field in Transaction Responses **Improved** The description for the `dateTime` field in transaction-related responses has been updated to clarify its meaning. **Category**: Transactions **Endpoints Affected**: * `GET /transactions` * `GET /transactions/{transactionId}` **Impact**: The `dateTime` field now explicitly represents "The timestamp of when the transaction was created or when it reached its final state (completion or failure)." This provides more accurate context for transaction lifecycle tracking. No integration changes are required. ## Added Stablecoin Reserves Endpoints **Added** two new endpoints to the Stablecoins API for retrieving reserve information. **Category**: Stablecoins **Endpoints Added**: * `GET /stablecoins/reserves`: Retrieves the history of stablecoin reserves. * `GET /stablecoins/reserves/entitled-stablecoins`: Gets a list of stablecoins for which the organization is entitled to view reserves. **Impact**: These new endpoints allow users to programmatically access stablecoin reserve data and history. ## Improved Response Structure for the List Tags Endpoint **Improved** The response body for the `GET /tags` endpoint now nests the list of tags within a `data` object for consistency with other API endpoints. **Category**: Tagging **Endpoint Changed**: * `GET /tags`: Returns the list of tags nested under a `data` object instead of at the top level. **Impact**: This is a breaking change. Integrations must be updated to read the list of tags from `response.data.tags` instead of the top-level `response.tags`. **Example**: *Previous Response Structure:* ```json theme={null} { "tags": [ { "name": "urgent", "tagType": "client" } ] } ``` *New Response Structure:* ```json theme={null} { "data": { "tags": [ { "name": "urgent", "tagType": "client" } ] } } ``` ## Improved Field Naming for Creating Wallets on Compatible Networks **Improved** The `createOnAllCompatibleNetworks` field for creating wallets has been renamed to `activateAllCompatibleNetworks`. **Category**: Wallets **Endpoint Changed**: * `POST /vaults/{vaultId}/wallets`: The `createOnAllCompatibleNetworks` boolean property was removed and replaced by `activateAllCompatibleNetworks`. **Impact**: This is a breaking change. Integrations using `createOnAllCompatibleNetworks` must switch to `activateAllCompatibleNetworks` to avoid request failures. The field's behavior is unchanged: when set to `true`, it activates the new wallet on every network that is key-compatible with the primary `networkId` and enabled for your organization. ## Improved Wallet Creation and Activation Across Compatible Networks **Improved** wallet creation and activation to support all compatible networks with a single flag. **Category**: Wallets **Endpoints Changed**: * `POST /vaults/{vaultId}/wallets`: Accepts a new optional boolean parameter, `createOnAllCompatibleNetworks`. * `POST /wallets/{walletId}/activate`: Accepts a new optional boolean parameter, `activateAllCompatibleNetworks`. **Impact**: This provides a more efficient way to manage wallets across multiple networks. Instead of listing every compatible network ID, you can use a single boolean flag to create or activate a wallet on all available compatible networks for your organization. The new `...AllCompatibleNetworks` parameters are mutually exclusive with the existing `compatibleNetworkIds` parameter, so you must provide exactly one of them. ## Added Endpoints for Tag Management **Added** a new Tags API to create, list, and manage tags for entities. **Category**: Tags **Endpoints Added**: * `GET /tags`: Lists tags. * `POST /tags`: Creates a tag. * `POST /tags/apply`: Applies tags to an entity. * `DELETE /tags/apply/{entityId}/{tagName}`: Removes a tag from an entity. * `GET /tags/search`: Searches for entities by tag. **Impact**: This introduces a new feature for users to programmatically organize, categorize, and search for their resources using tags. ## Improved Asset Type Details with Compatible Network IDs **Improved** The `GET /asset-types` endpoint response now includes a list of compatible network IDs. **Category**: Asset Types **Endpoint Changed**: * `GET /asset-types`: The `AssetTypeDetails` object now contains `compatibleNetworkIds`, an array of network IDs that share wallet key derivation with the asset's primary network. **Impact**: This helps you identify which networks can be used when creating a new wallet or activating an existing wallet on additional networks. **Example**: ```json theme={null} { "data": [ { "assetType": "ETH", "name": "Ethereum", "decimals": 18, "networkId": "ETH", "onchainIdentifier": null, "featureSupport": [ "TRANSFERS", "HOLDS" ], "compatibleNetworkIds": [ "POLYGON", "AVAX_C" ] } ] } ``` ## Added Tax Lot Selection for Async Orders **Added** the ability to specify a tax lot ID for async sell orders for tax reporting. **Category**: Trading **Endpoints Changed**: * `POST /trading/async-order`: Accepts a new optional `specLotId` field to specify a tax lot to retire for `SELL` orders with a `timeInForce` of `FOK`; the `rejectReason` field in the response now includes `InvalidSideForSpecLotID` and `InvalidTimeInForceForSpecLotID`. * `POST /trading/async-order/cancel`: The `rejectReason` field in the response now includes `InvalidSideForSpecLotID` and `InvalidTimeInForceForSpecLotID`. **Impact**: You can now programmatically manage tax lot retirement for specific `SELL` orders, enhancing tax reporting capabilities. ## Improved Collateral Package Endpoint with Value and Price Details **Improved** The response for the collateral packages endpoint now includes additional value and pricing details for each package and its underlying assets. **Category**: Collateral Management **Endpoint Changed**: * `GET /collateral_management/packages`: The response now includes optional `exposureValue` and `packageValue` fields at the top level of each package, plus `price`, `quantity`, and `weightedValue` for each asset in the `collateralAssets` array. **Impact**: This is a non-breaking change that gives you a more complete financial overview of each collateral package directly in the list view. **Example**: ```json theme={null} { "data": [ { "packageId": "unique-package-id", "clientReferenceId": "client-ref-123", "active": true, "exposureValue": "50000.00", "packageValue": "100000.00", "collateralAssets": [ { "asset": { "assetType": "BTC", "type": "ANCHORAGECUSTODY" }, "price": "60000.00", "quantity": "1.5", "weight": "0.9", "weightedValue": "81000.00" } ], // ... other fields } ], "page": { "next": null } } ``` ## Added Endpoint to Request Collateral Decrease **Added** a new endpoint that lets users request a collateral decrease for a specified collateral package. **Category**: Collateral Management **Endpoint Added**: * `POST /collateral_management/packages/{packageId}/collateral-decrease`: Initiates a two-way Atlas settlement to return assets from the secured party's collateral wallets to the pledgor's return wallets. **Impact**: This lets either the pledgor or the secured party programmatically initiate the return of collateral assets. A successful call creates an Atlas settlement, and the `settlementId` is returned in the response for tracking. **Example**: ```json theme={null} { "assetAmounts": [ { "assetTypeID": "BTC", "value": "1.1" }, { "assetTypeID": "ETH", "value": "20.62" } ], "idempotencyKey": "decrease-2024-01-15-pkg-abc", "useGasStation": false } ``` ## Added Endpoint to Activate Wallets on Additional Networks **Added** a new endpoint to activate an existing wallet on additional compatible networks. **Category**: Wallets **Endpoint Added**: * `POST /wallets/{walletId}/activate`: Activates an existing wallet on additional compatible networks. **Impact**: This lets you enable a single wallet for use across multiple networks that share the same key family, streamlining asset management without needing to create separate wallets. ## Added Fiat Details to Transaction Responses **Added** A new `fiatDetails` object is now included in transaction responses to provide banking details for fiat transactions. **Category**: Transactions **Endpoints Changed**: * `GET /transactions`: The response now includes a `fiatDetails` object for fiat-related transactions. * `GET /transactions/{transactionId}`: The response now includes a `fiatDetails` object for fiat-related transactions. **Impact**: This provides key banking information, such as account number, bank name, and FedWire number, which aids in reconciliation and tracking. **Example**: ```json theme={null} "fiatDetails": { "accountNumber": "123456789", "bankId": "987654321", "bankName": "Anchorage Digital Bank", "fedWire": "WIRE12345", "memo": "Q1 Payout", "name": "Jane Doe" } ``` ## Added Endpoint to List All Subaccounts **Added** a new endpoint to retrieve all subaccounts associated with an organization. **Category**: Subaccounts **Endpoint Added**: * `GET /subaccounts/customers/accounts`: Lists all subaccounts for your organization, with filtering by `subaccountIds`, `externalIds`, `endDate`, and `statuses`, plus pagination via `afterId` and `limit`. **Impact**: This provides a comprehensive, organization-level view of all subaccounts, enabling more efficient and complete data retrieval than fetching subaccounts on a per-customer basis. ## Improved Transfers and Withdrawals with Trusted Destination Support **Improved** Transfers and withdrawals can now use a Trusted Destination as the destination, and wallet responses can reflect it as a resource type. **Category**: Transfers, Transactions, Wallets **Endpoints Changed**: * `POST /transactions/withdrawal`: Accepts `TRUSTED_DESTINATION` as a `destination.type` value. * `POST /transfers`: Accepts `TRUSTED_DESTINATION` as a `destination.type` value. * `GET /transfers`: Can return `TRUSTED_DESTINATION` as a destination type in the response. * `GET /transfers/{transferId}`: Can return `TRUSTED_DESTINATION` as a destination type in the response. * `GET /vaults/{vaultId}/wallets`: Can return `TRUSTED_DESTINATION` as a wallet resource type. * `POST /vaults/{vaultId}/wallets`: Can return `TRUSTED_DESTINATION` as a wallet resource type. * `GET /wallets`: Can return `TRUSTED_DESTINATION` as a wallet resource type. * `GET /wallets/{walletId}`: Can return `TRUSTED_DESTINATION` as a wallet resource type. **Impact**: This simplifies withdrawal and transfer workflows. You can send funds to a pre-configured Trusted Destination by providing its ID, without needing to re-specify address details, memos, or destination tags in each API call. Using Trusted Destinations also reduces the risk of sending funds to an incorrect address. **Example**: ```json theme={null} { "assetType": "XRP", "amount": "100.00", "source": { "id": "1c920f4241b78a1d483a29f3c24b6c4c", "type": "WALLET" }, "destination": { "id": "your_trusted_destination_id", "type": "TRUSTED_DESTINATION" } } ``` ## Removed Wallet Activation Endpoint **Removed** The endpoint for activating an existing wallet on additional compatible networks has been removed. **Category**: Wallets **Endpoint Removed**: * `POST /wallets/{walletId}/activate` **Impact**: You can no longer programmatically activate an existing wallet on additional compatible networks. ## Added Endpoint to Activate Wallets on Additional Networks **Added** a new endpoint to activate an existing wallet on additional compatible networks. **Category**: Wallets **Endpoint Added**: * `POST /wallets/{walletId}/activate`: Activates an existing wallet on additional compatible networks that share the same key family, without creating a new wallet. **Impact**: This lets you enable a single wallet for use across multiple networks that share the same key family, streamlining asset management by reusing a single wallet instead of creating a new one for each network. ## Added Endpoint for Collateral Decrease Requests **Added** a new endpoint that lets users request a collateral decrease. **Category**: Collateral Management **Endpoint Added**: * `POST /collateral_management/packages/{packageId}/collateral-decrease`: Enables programmatic requests to decrease collateral for a specified package. **Impact**: This lets you programmatically initiate a decrease in collateral for a specific package. ## Added Compatible Networks Support to Wallet Creation **Added** an optional `compatibleNetworkIds` field for activating a new wallet on additional compatible networks at the time of creation. **Category**: Wallets **Endpoint Changed**: * `POST /vaults/{vaultId}/wallets`: Accepts a new optional `compatibleNetworkIds` field (an array of strings). **Impact**: This lets you create a wallet and activate it on multiple compatible networks in a single API call. All specified networks must share the same key family as the primary `networkId`, and activation happens synchronously after wallet creation. **Example**: ```json theme={null} { "networkId": "ETH", "walletName": "My EVM Wallet", "compatibleNetworkIds": [ "POLYGON", "AVAX" ] } ``` ## Improved Memo Handling for Fiat Trusted Destinations **Improved** The behavior of the `memo` field for fiat transfers and withdrawals to Trusted Destinations has been clarified. **Category**: Transactions, Transfers, and Trusted Destinations **Endpoints Changed**: * `POST /transactions/withdrawal`: The `memo` field within `assetParametersFiatTrustedDestination` is now optional; if omitted, the default memo from the saved Trusted Destination is used. * `POST /transfers`: The `memo` field within `assetParametersFiatTrustedDestination` is now optional; if omitted, the default memo from the saved Trusted Destination is used. * `GET /trusted_destinations`: The response now specifies that the `memo` for a fiat destination has a maximum length of 140 characters. **Impact**: This simplifies API calls by letting you rely on the pre-configured memo on a Trusted Destination, reducing the need to specify it in every withdrawal or transfer request. ## Improved Stablecoin History Response Field Naming **Improved** In the response for the stablecoin history endpoint, the `issueRedeemId` field has been renamed to `id`. **Category**: Stablecoins **Endpoint Changed**: * `GET /stablecoins/history`: The unique identifier for an issue or redeem operation is now returned as `id` instead of `issueRedeemId`. **Impact**: This is a breaking change. Integrations that parse `issueRedeemId` must switch to the new `id` field. **Example**: *Before:* ```json theme={null} { "data": [ { "issueRedeemId": "b1a1c1...", "operationType": "ISSUE", ... } ] } ``` *After:* ```json theme={null} { "data": [ { "id": "b1a1c1...", "operationType": "ISSUE", ... } ] } ``` ## Improved Stablecoin History Endpoint Pagination and Status Detail **Improved** The stablecoin history response now aligns with the standard paginated format and includes more detailed status information. **Category**: Stablecoins **Endpoint Changed**: * `GET /stablecoins/history`: The response now returns a `data` array plus a `page` object for pagination (replacing `hasNextPage`), adds `destinationOperationId` and `sourceOperationId`, adds a `status` field (`INITIATED`, `EXECUTING`, `COMPLETED`, `FAILED`, `UNKNOWN`), adds an optional `subStatus` field, and expands `operationType` to include `BRIDGE` and `SWAP`. **Impact**: This is a breaking change. The `conversions` array is now nested under `data`, and pagination uses a `page.next` URL instead of the previous `hasNextPage` boolean. Integrations must be updated to parse the new response structure. **Example**: ```json theme={null} { "data": [ { "issueRedeemId": "...", "operationType": "ISSUE", "status": "COMPLETED", "subStatus": null, "sourceAssetTypeId": "USD", "destinationAssetTypeId": "USDC", "amount": "100.00", "sourceOperationId": "...", "destinationOperationId": "..." } ], "page": { "next": "/v2/stablecoins/history?..." } } ``` ## Improved Order Type Support with LIMIT\_ALL\_IN **Improved** Added `LIMIT_ALL_IN` as a new possible enum value for the `orderType` field in trading order responses. **Category**: Trading **Endpoints Changed**: * `GET /trading/orders`: The `orderType` field in the response may now include `LIMIT_ALL_IN`. * `GET /trading/orders/{orderId}`: The `orderType` field in the response may now include `LIMIT_ALL_IN`. **Impact**: Responses from the list orders and get order by ID endpoints may now include `LIMIT_ALL_IN` as an `orderType`. Make sure your client can handle this new value. ## Improved Statements with Correction Timestamps and Filtering **Improved** Added filtering and timestamp information for corrected statements, so you can track and query statements updated after their initial generation. **Category**: Statements **Endpoints Changed**: * `GET /statements`: Accepts two new optional query parameters, `correctedAfter` and `correctedBefore`, to filter for statements corrected at or after or before a given time. * `GET /statements/{statementId}`: The response now includes a `correctedAt` field indicating when a correction was made. **Impact**: You can now programmatically identify and filter for statements that have been corrected, improving audit and reconciliation workflows. **Example**: ```json theme={null} { "data": { "customerId": "fbcdb420fca4439d919089e60d59cd5b12b692d215694681b636bffb6cb1618c", "createdAt": "2025-09-01T00:47:16.937934Z", "correctedAt": "2025-09-15T10:00:00.000000Z", "displayName": "ETF Statement September 2025", "id": "8de0fc33-7443-4dcf-bbf1-4ca8d0e0509f", "typeId": "058da362-31a7-4e2b-ae3e-77b095389a5f" } } ``` ## Added Subaccount ID Filter for Deposit Attributions **Added** You can now filter deposit attributions by one or more `subaccountIds`. **Category**: Deposit Attribution **Endpoint Changed**: * `GET /deposit-attributions/attributions`: Accepts a new query parameter, `subaccountIds`. **Impact**: This allows for more granular filtering of deposit attributions, making it easier to retrieve records associated with specific subaccounts. **Example**: `GET /v2/deposit-attributions/attributions?subaccountIds=subaccount_id_1,subaccount_id_2` ## Improved Permission Requirements for Stablecoin History **Improved** permission requirements for the stablecoin history endpoint. **Category**: Stablecoins **Endpoint Changed**: * `GET /stablecoins/history`: Now uses the more specific `Read Stablecoin Conversions` permission as the primary requirement. **Impact**: For backward compatibility, the endpoint continues to accept the older `Read vault activity` permission too, so no immediate changes are required for existing integrations. ## Added Stablecoin Conversion History Endpoint **Added** a new endpoint to retrieve the history of stablecoin issuance and redemption operations. **Category**: Stablecoins **Endpoint Added**: * `GET /stablecoins/history`: Returns a historical list of your stablecoin issuance and redemption operations. **Impact**: You can now programmatically access your stablecoin conversion history for tracking and reporting purposes. ## Added Binance as a Price Source for Collateral Management **Added** support for `BINANCE` as a price source in Collateral Management. **Category**: Collateral Management **Endpoints Changed**: * `GET /collateral_management/price_sources`: Now returns `BINANCE` as an available source and accepts it as a filter in the `exchange` query parameter. * `POST /collateral_management/packages`: The `priceSource` field now accepts `BINANCE`. * `PATCH /collateral_management/packages/{packageId}`: The `priceSource` field now accepts `BINANCE`. * `POST /collateral_management/exposures`: The `priceSource` field now accepts `BINANCE`. **Impact**: This allows for more flexible pricing options when creating and managing collateral packages and exposures. **Example**: ```json theme={null} "collateralAssetsConfig": [ { "asset": { "assetType": "BTC", "type": "ANCHORAGECUSTODY" }, "priceSource": "BINANCE", "weight": "1.0", "liquidationPriority": 1 } ] ``` ## Added Accelerated Margin Call for Collateral Management **Added** A new `acceleratedMarginCall` configuration level for collateral packages, letting you set an additional margin call threshold with its own LTV, cure period, and action. **Category**: Collateral Management **Endpoints Changed**: * `POST /collateral_management/packages`: Accepts a new `acceleratedMarginCall` object in the request body. * `PATCH /collateral_management/packages/{packageId}`: Accepts a new `acceleratedMarginCall` object in the request body. * `GET /collateral_management/packages`: The response now includes the `acceleratedMarginCall` object. **Impact**: You can now define and monitor an additional, accelerated margin call level for your collateral packages, providing more granular risk management. ## Removed TRUSTED\_DESTINATION Resource Type from Transfers and Wallets **Removed** The `TRUSTED_DESTINATION` enum value from the `destination.type` field for transfer and withdrawal requests, and from the `type` field in several Wallet and Transfer responses. **Category**: Transfers, Transactions, and Wallets **Endpoints Changed**: * `POST /transactions/withdrawal`: `destination.type` no longer accepts `TRUSTED_DESTINATION`; the `assetParametersATOM` field is now deprecated in favor of `assetParametersCosmos`. * `POST /transfers`: `destination.type` no longer accepts `TRUSTED_DESTINATION`; the `assetParametersATOM` field is now deprecated in favor of `assetParametersCosmos`. * `GET /transfers`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`. * `GET /transfers/{transferId}`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`. * `GET /vaults/{vaultId}/wallets`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`. * `POST /vaults/{vaultId}/wallets`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`. * `GET /wallets`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`. * `GET /wallets/{walletId}`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`. **Impact**: This is a breaking change. Requests that specify `destination.type` as `TRUSTED_DESTINATION` will now fail. To send funds to a trusted destination, use `destination.type: 'ADDRESS'` with the specific blockchain address, and update any logic that parses the `type` field in Wallet and Transfer responses. Users are encouraged to migrate from the deprecated `assetParametersATOM` to `assetParametersCosmos`. ## Improved Order Filtering Parameter Description **Improved** the description for the `orderTypes` query parameter to enhance clarity. **Category**: Trading **Endpoint Changed**: * `GET /trading/orders`: The description for the `orderTypes` parameter was updated. **Impact**: This is a non-breaking documentation change. No integration updates are required. ## Improved Statement Filtering and Response Structure **Improved** the Statements endpoints with updated filtering parameters and a restructured response body. **Category**: Statements **Endpoints Changed**: * `GET /statements`: Removed the `statementIds`, `statementTypes`, `accountIds`, `affiliateIds`, `vaultGroupIds`, and `subaccountIds` filter parameters, and added `ids`, `typeIds`, and `customerIds`. The response no longer includes `accountId`, `affiliateId`, `subaccountId`, `vaultGroupId`, or the required `type` field, and now includes `customerId` and the new required `typeId` field (`type` is now optional). * `GET /statements/{statementId}`: The response no longer includes `accountId`, `affiliateId`, `subaccountId`, `vaultGroupId`, or the required `type` field, and now includes `customerId` and the new required `typeId` field (`type` is now optional). **Impact**: This is a breaking change. Integrations using the `/statements` endpoints must be updated to use the new query parameters and handle the modified response structure. ## Improved Order Type Support with MANUAL **Improved** Added support for a new `MANUAL` order type. **Category**: Trading **Endpoints Changed**: * `GET /trading/orders`: The `orderType` field in the response can now include `MANUAL`. * `GET /trading/orders/{orderId}`: The `orderType` field in the response can now include `MANUAL`. **Impact**: Clients should update their integrations to handle this new enum value when listing or retrieving orders. ## Improved Fiat Trusted Destination Response Structure **Improved** The structure of the `fiat` object in the trusted destinations response has been refactored for clarity, with beneficiary and financial institution details now grouped into nested `beneficiary` and `beneficiaryBank` objects, plus new `intermediaryBank` and `usage` fields. **Category**: Trusted Destinations **Endpoint Changed**: * `GET /trusted_destinations`: The `fiat` object's flat beneficiary and institution properties are now nested under `beneficiary` and `beneficiaryBank`, and the object gains `intermediaryBank` and `usage` fields. **Impact**: This is a breaking change. Integrations that parsed the flat properties within the `fiat` object must be updated to handle the new nested structure. The new `usage` field indicates whether the recipient account is owned by your organization or a third party. **Example**: *Before:* ```json theme={null} { "fiat": { "beneficiaryName": "Satoshi Nakamoto", "beneficiaryAccount": "*****1234", "institutionName": "The Bank of New York Mellon", "institutionId": "IRVTUS3N", //... other flat properties } } ``` *After:* ```json theme={null} { "fiat": { "beneficiary": { "name": "Satoshi Nakamoto", "account": "*****1234", //... other beneficiary properties }, "beneficiaryBank": { "name": "The Bank of New York Mellon", "id": "IRVTUS3N", //... other bank properties }, "intermediaryBank": {}, "usage": "MY_ORGANIZATION" } } ``` ## Added Fiat Support for Trusted Destinations **Added** support for fiat (bank account) trusted destinations. **Category**: Trusted Destinations **Endpoint Changed**: * `GET /trusted_destinations`: The response now includes details for fiat-based trusted destinations. **Impact**: When listing trusted destinations, a fiat destination now has a `type` of `fiat` and contains a new `fiat` object with detailed bank account information. **Example**: ```json theme={null} { "data": [ { "id": "td_fiat_12345", "name": "Corporate Bank Account", "description": "Primary USD account", "type": "fiat", "owner": { "id": "customer_abc", "type": "CUSTOMER" }, "fiat": { "beneficiaryName": "Example Corp", "beneficiaryAccount": "987654321", "beneficiaryType": "BUSINESS", "institutionName": "Example Bank", "institutionId": "121000358", "institutionCode": "ABA", "memo": "For operating expenses" }, "crypto": null } ] } ``` ## Improved Order Allocation Details with Filled Quantity **Improved** The `allocation` object in trading order responses now includes the `cumQty` field, which specifies the filled quantity for each subaccount allocation. **Category**: Trading **Endpoints Changed**: * `POST /trading/order`: The `allocation` object in the response now includes the required `cumQty` field. * `GET /trading/orders`: The `allocation` object in the response now includes the required `cumQty` field. * `GET /trading/orders/{orderId}`: The `allocation` object in the response now includes the required `cumQty` field. * `POST /trading/async-order`: The `allocation` object in the response now includes the required `cumQty` field. * `POST /trading/async-order/cancel`: The `allocation` object in the response now includes the required `cumQty` field. **Impact**: This is a non-breaking change that provides more granular data on order fills at the subaccount level. **Example**: ```json theme={null} "allocation": [ { "subaccountId": "905272f0-52f9-404e-b6cd-ad879e671790", "quantity": "10000", "cumQty": "10000", "counterQtyAllIn": "10000", "counterQtyAllInToSettle": "10000", "fee": "10000" } ] ``` ## Improved Collateral Management Price Sources Endpoint **Improved** Added a new `501 Not Implemented` response and clarified the `exchange` query parameter description. **Category**: Collateral Management **Endpoint Changed**: * `GET /collateral_management/price_sources`: Now returns a `501 Not Implemented` error if the price sources feature is disabled; the `exchange` parameter description was simplified. **Impact**: API consumers will now receive a `501 Not Implemented` error if the price sources feature is disabled. ## Improved Clarity for Tax Reporting Deposit Transaction Endpoints **Improved** descriptions for the Tax Reporting endpoints to clarify that cost basis management applies specifically to deposit transactions. **Category**: Tax Reporting **Endpoints Changed**: * `PATCH /tax/accounts/{accountId}/transactions/{transactionId}`: The endpoint and `hasCostBasis` parameter descriptions were improved for accuracy. * `GET /tax/accounts/{accountId}/transactions`: The endpoint and `hasCostBasis` parameter descriptions were improved for accuracy. **Impact**: This is a documentation-only change to improve clarity. The functionality of the endpoints remains unchanged. ## Improved Async Order Responses with Counter Currency Details **Improved** Added `counterCurrency`, `counterQty`, and `counterQtyAllIn` fields to the responses for placing and canceling async orders. **Category**: Trading **Endpoints Changed**: * `POST /trading/async-order`: The response now includes `counterCurrency`, `counterQty`, and `counterQtyAllIn`. * `POST /trading/async-order/cancel`: The response now includes `counterCurrency`, `counterQty`, and `counterQtyAllIn`. **Impact**: The responses for placing and canceling an async order now include the counter currency, the filled quantity of the counter currency, and the filled quantity including all fees. **Example**: ```json theme={null} { "data": { "clOrderId": "6fb5fc79-0bb4-446d-82dd-d4687fb56a02", "orderId": "a94c8d75-6c9d-4903-95f3-5b0893e76cb7", // ... existing fields "counterCurrency": "BTC", "counterQty": "0.4760680586896702", "counterQtyAllIn": "0.4760544606302961", "transactTime": "2023-03-12T22:22:09.925050Z" } } ``` ## Added Collateral Management Price Sources Endpoint **Added** a new endpoint to get available price sources and their supported assets. **Category**: Collateral Management **Endpoint Added**: * `GET /collateral_management/price_sources`: Returns supported price sources and the specific assets available for each source. **Impact**: This lets clients programmatically retrieve supported price sources, which can be used to validate configurations for collateral packages. ## Improved Price Strategy Options for Collateral Management **Improved** The `priceStrategy` options for creating and managing collateral packages and exposures now include `MID` and `LAST`; `VWAP` has been removed. **Category**: Collateral Management **Endpoints Changed**: * `POST /collateral_management/packages`: The `priceStrategy` field now accepts `MID` and `LAST`; `VWAP` is no longer supported. * `PATCH /collateral_management/packages/{packageId}`: The `priceStrategy` field now accepts `MID` and `LAST`; `VWAP` is no longer supported. * `POST /collateral_management/exposures`: The `priceStrategy` field now accepts `MID` and `LAST`; `VWAP` is no longer supported. **Impact**: This is a breaking change. Integrations using the `priceStrategy` field must switch from `VWAP` to `MID` or `LAST`. ## Added Fiat Parameters for Trusted Destination Transfers and Withdrawals **Added** A new `assetParametersFiatTrustedDestination` object to the request body for fiat transfers and withdrawals to Trusted Destinations. **Category**: Transactions, Transfers **Endpoints Changed**: * `POST /transactions/withdrawal`: Accepts a new optional `assetParametersFiatTrustedDestination` object with `memo` and `purpose` fields. * `POST /transfers`: Accepts a new optional `assetParametersFiatTrustedDestination` object with `memo` and `purpose` fields. **Impact**: This lets you provide additional context when sending fiat assets to a Trusted Destination, which is useful for record-keeping and compliance. **Example**: ```json theme={null} { "assetType": "USD", "amount": "5000.00", "source": { "id": "1c920f4241b78a1d483a29f3c24b6c4c", "type": "WALLET" }, "destination": { "id": "td_123abc...", "type": "TRUSTED_DESTINATION" }, "assetParametersFiatTrustedDestination": { "memo": "Q1 Payout", "purpose": "INVESTMENT" }, "idempotentId": "unique-withdrawal-id-123" } ``` ## Improved Offchain Vesting Schedule Response with Asset Type **Improved** the response for listing offchain vesting schedules to include the asset type. **Category**: Vesting **Endpoint Changed**: * `GET /offchainvesting/schedules`: Each schedule object in the `data` array now includes the `assetType` field, specifying the asset abbreviation (for example, BTC or ETH). **Impact**: This is a non-breaking, additive change that makes it easier to identify the asset associated with each vesting schedule directly from the list endpoint. ## Improved Transfers and Withdrawals with Trusted Destinations **Improved** You can now use pre-configured Trusted Destinations when creating transfers and withdrawals, sending funds to a `TRUSTED_DESTINATION` ID instead of a full address. **Category**: Transfers & Withdrawals **Endpoints Changed**: * `POST /transfers`: The `destination.type` field now accepts `TRUSTED_DESTINATION`. * `POST /transactions/withdrawal`: The `destination.type` field now accepts `TRUSTED_DESTINATION`. * `GET /transfers`: The response can now reflect `TRUSTED_DESTINATION` as a destination type. * `GET /transfers/{transferId}`: The response can now reflect `TRUSTED_DESTINATION` as a destination type. **Impact**: When sending to a `TRUSTED_DESTINATION`, you no longer need to include asset-specific parameters like `assetParametersXRP` or `assetParametersXLM` — the destination tag or memo is inherited automatically from the trusted destination's configuration. **Example**: ```json theme={null} // POST /transactions/withdrawal { "assetType": "XRP", "amount": "100.0", "source": { "id": "your_wallet_id", "type": "WALLET" }, "destination": { "id": "your_trusted_destination_id", "type": "TRUSTED_DESTINATION" }, "idempotentId": "unique-id-for-withdrawal-123" } ``` ## Improved Market Data Endpoint with Amount-Based Depth **Improved** The market data endpoint now supports returning market depth by notional value, such as USD, in addition to asset size. **Category**: Trading **Endpoint Changed**: * `GET /trading/marketdata`: A new `amount` field has been added to the `bids` and `offers` objects, returned when using the `amountBuckets` query parameter; the existing `size` field is returned when using `sizeBuckets`. **Impact**: This is a non-breaking change that lets you request market depth in notional terms instead of, or alongside, asset size. **Example**: ```json theme={null} // Request using amountBuckets GET /trading/marketdata?symbol=BTC-USD&amountBuckets=10000,50000 // Sample Response Snippet "bids": [ { "price": "65000.00", "amount": "10000.00" // New field: value in USD }, { "price": "64950.00", "amount": "50000.00" // New field: value in USD } ] ``` ## Added Endpoint to Propose Trusted Counterparties **Added** A new endpoint to propose a new trusted counterparty. **Category**: Atlas Settlement Network **Endpoint Added**: * `POST /atlas/directory/counterparties`: Proposes a new trusted counterparty. **Impact**: You can now programmatically propose new trusted counterparties, streamlining the process of adding new settlement partners. ## Improved Market Data Parameter Descriptions **Improved** descriptions for the `sizeBuckets` and `amountBuckets` query parameters to clarify their usage and impact on the response. **Category**: Trading **Endpoint Changed**: * `GET /trading/marketdata`: `sizeBuckets` is clarified as a comma-separated list; `amountBuckets` is clarified as a comma-separated list of USD values, with a note that using it affects how `size` is represented in the response. **Impact**: This is a non-breaking documentation change that provides better guidance for querying market depth. ## Improved Cost Basis Reporting with Tax Lots **Improved** the Tax Reporting endpoints to support lot-level cost basis management for more granular and accurate tax data. **Category**: Tax Reporting **Endpoints Changed**: * `PATCH /tax/accounts/{accountId}/transactions/{transactionId}`: The request body now requires a `lots` array (each with `lotId`, `quantity`, and `costBasis`) in place of the previous `data`, `acquisitionDatetime`, and `assetType` fields. * `GET /tax/accounts/{accountId}/transactions`: The response now includes a required top-level `assetType` field per transaction, and an `acquisitionDatetime` field on each lot in the `receivedAssets` array. **Impact**: This moves cost basis reporting from a per-transaction model to a per-lot model, letting you specify and retrieve cost basis information for individual lots within a single transaction. ## Added Market Data Endpoint **Added** a new endpoint to retrieve a snapshot of market data. **Category**: Trading **Endpoint Added**: * `GET /trading/marketdata`: Returns a snapshot of current market data. **Impact**: You can now programmatically access market data for pricing, analysis, and other trading-related activities. See the [Market Data Guide](https://developers.anchorage.com/docs/websocket-api-market-data) for more information. ## Improved Transaction Types and Settlement Parameter Documentation **Improved** Added the `FIAT_INTEREST` transaction type and clarified the `applyPostLock` parameter description. **Category**: Transactions, Atlas Settlement Network **Endpoints Changed**: * `GET /transactions`: The `transactionType` field in the response can now include `FIAT_INTEREST`, representing fiat interest payments. * `GET /transactions/{transactionId}`: The `transactionType` field in the response can now include `FIAT_INTEREST`, representing fiat interest payments. * `POST /atlas/settlements`: The description for the `applyPostLock` parameter now clarifies it applies only to clients using Atlas settlements integrated with Anchorage Vesting. **Impact**: Clients should update their systems to handle the new `FIAT_INTEREST` transaction type. The `applyPostLock` documentation change is non-breaking and only clarifies existing behavior. ## Deprecated `totalDistribution` Field in Tax Tagging **Deprecated** the `totalDistribution` field for tagging tax transactions. **Category**: Tax **Endpoint Changed**: * `POST /tax/transaction/{transactionId}/tag`: The `totalDistribution` field in the request body is now deprecated and ignored if provided. **Impact**: Any value passed in `totalDistribution` is disregarded — total distribution status is now calculated automatically from account balances. Remove this field from your requests, since it no longer has any effect. ## Added Post-Settlement Locking for Atlas Settlements **Added** a new `applyPostLock` parameter to automatically create post-settlement holds on funds received through the Atlas Settlement Network. **Category**: Atlas Settlement Network **Endpoint Changed**: * `POST /atlas/settlements`: Accepts a new optional boolean `applyPostLock` parameter; when `true`, indefinite holds are placed on the acceptor's destination wallets after a successful settlement. **Impact**: This enables the automatic creation of post-settlement vesting schedules on received funds, streamlining workflows that require funds to be locked after settlement. ## Added Vesting Schedules Endpoint and Tax Transaction Cost Basis Filter **Added** a new endpoint for listing offchain vesting schedules and a new filter for tax transactions. **Category**: Vesting, Tax Reporting **Endpoints Changed**: * `GET /offchainvesting/schedules`: New endpoint that lists all offchain vesting schedules for your organization. * `GET /tax/accounts/{accountId}/transactions`: Accepts a new `hasCostBasis` query parameter to filter transactions that do or don't have a cost basis. **Impact**: This provides programmatic access to vesting schedules and lets you filter tax transactions by whether they have a cost basis, improving transparency and reporting. ## Improved Transaction Types with Priority Fee Reward **Improved** The `transactionType` field in transaction-related endpoints now includes `PRIORITY_FEE_REWARD` to represent priority fee rewards. **Category**: Transactions **Endpoints Changed**: * `GET /transactions`: The `transactionType` field in the response can now include `PRIORITY_FEE_REWARD`. * `GET /transactions/{transactionId}`: The `transactionType` field in the response can now include `PRIORITY_FEE_REWARD`. **Impact**: This new type identifies priority fee rewards, such as those from Jito priority fee distributions on Solana. ## Improved Clarity for Trusted Destination Asset Type **Improved** The description for the `assetType` field has been updated to provide better clarity when creating a trusted destination. **Category**: Trusted Destinations **Endpoint Changed**: * `POST /trusted_destinations`: The description for `assetType` in the `trustedDestinations` array now clarifies what an asset type is and points to `GET /asset-types` for a list of supported types. **Impact**: This is a non-breaking documentation change. The endpoint's functionality remains the same. ## Improved Security with Signature Requirements for Collateral Management **Improved** security by requiring `Api-Signature` and `Api-Timestamp` headers for write operations on Collateral Management endpoints. **Category**: Collateral Management **Endpoints Changed**: * `PATCH /collateral_management/operations/{operationId}`: Now requires `Api-Signature` and `Api-Timestamp` headers. * `PATCH /collateral_management/packages/{packageId}`: Now requires `Api-Signature` and `Api-Timestamp` headers. * `POST /collateral_management/exposures`: Now requires `Api-Signature` and `Api-Timestamp` headers. * `POST /collateral_management/operations`: Now requires `Api-Signature` and `Api-Timestamp` headers. * `POST /collateral_management/packages`: Now requires `Api-Signature` and `Api-Timestamp` headers. **Impact**: This is a breaking change. Requests to these endpoints will now fail if they don't include valid signature and timestamp headers. See the Request Signatures section of the documentation for instructions on generating a valid signature. ## Improved Wallet Responses with Unvested and Unstakeable Balances **Improved** Wallet-related endpoints now include more detailed balance information for offchain vesting. **Category**: Wallets **Endpoints Changed**: * `GET /vaults/{vaultId}/wallets`: The `assets` object now includes `unvestedBalance` and `unvestedUnstakeableBalance` fields. * `POST /vaults/{vaultId}/wallets`: The `assets` object now includes `unvestedBalance` and `unvestedUnstakeableBalance` fields. * `GET /wallets`: The `assets` object now includes `unvestedBalance` and `unvestedUnstakeableBalance` fields. * `GET /wallets/{walletId}`: The `assets` object now includes `unvestedBalance` and `unvestedUnstakeableBalance` fields. **Impact**: This is a non-breaking change. Responses now contain additional balance details for assets in offchain vesting contracts, where applicable. ## Improved Vesting Balance Retrieval for Multiple Allocations **Improved** vesting balance retrieval by adding a new endpoint to fetch balances for multiple allocations in a single request. **Category**: Vesting **Endpoint Added**: * `POST /vesting/balances`: Retrieves vesting balances for multiple allocations in a single request. **Impact**: This allows for more efficient retrieval of balance data by fetching information for multiple allocations at once, reducing the number of required API calls. ## Improved Security with Request Signing for Atlas Settlement Endpoints **Improved** security by adding request signing to key Atlas Settlement Network endpoints, which now require `Api-Signature` and `Api-Timestamp` headers. **Category**: Atlas Settlement Network **Endpoints Changed**: * `POST /atlas/settlements`: Now requires `Api-Signature` and `Api-Timestamp` headers. * `POST /atlas/settlements/{settlementId}/accept`: Now requires `Api-Signature` and `Api-Timestamp` headers. * `POST /atlas/settlements/{settlementId}/authorize`: Now requires `Api-Signature` and `Api-Timestamp` headers. * `POST /atlas/settlements/{settlementId}/reject`: Now requires `Api-Signature` and `Api-Timestamp` headers. **Impact**: This is a breaking change. Requests made to the listed endpoints will now fail if they don't include the required signature headers. See the Request Signatures section of the documentation for instructions on generating the required signatures. ## Improved Stablecoin Conversion Documentation **Improved** the description for the `sourceAssetType` field in the stablecoin conversion request body for clarity. **Category**: Stablecoins **Endpoint Changed**: * `POST /stablecoins/conversion`: The `sourceAssetType` description now clarifies that it must be `USD` for an issuance, and the asset being redeemed for a redemption. **Impact**: This is a non-breaking documentation change. ## Improved Staking Request Descriptions **Improved** The descriptions for the `parameters` object and the `stakingProviderAddress` field for Solana staking requests have been updated for clarity. **Category**: Transactions **Endpoint Changed**: * `POST /transactions/stake`: The description for the `parameters` object was updated, and within `SOLStakingParameters`, `stakingProviderAddress` now describes "the validator's vote account address" instead of "the validator's staking address". **Impact**: This is a non-breaking documentation change to provide better clarity for clients creating Solana (SOL) staking requests. ## Added Endpoint for Consolidating Stakes **Added** a new endpoint to create a consolidate stake request. **Category**: Transactions **Endpoint Added**: * `POST /transactions/consolidate-stake`: Initiates a request to consolidate staking positions. **Impact**: This feature enhances staking management by allowing users to consolidate stakes directly through the API. See the [staking guide](https://developers.anchorage.com/docs/ethereum-pectra-staking-api#consolidate-pectra-to-pectra-validator) for instructions on use. ## Improved Backward Compatibility by Re-introducing the VAULT Resource Type **Improved** backward compatibility by re-introducing the `VAULT` enum value for source and destination resources; it's accepted but deprecated in favor of `WALLET`. **Category**: Transfers, Wallets, and Transactions **Endpoints Changed**: * `POST /transactions/withdrawal`: Accepts `VAULT` again as a resource type, though deprecated in favor of `WALLET`. * `POST /transfers`: Accepts `VAULT` again as a resource type, though deprecated in favor of `WALLET`. * `GET /transfers`: Accepts `VAULT` again as a resource type, though deprecated in favor of `WALLET`. * `GET /transfers/{transferId}`: Accepts `VAULT` again as a resource type, though deprecated in favor of `WALLET`. * `GET /vaults/{vaultId}/wallets`: Accepts `VAULT` again as a resource type, though deprecated in favor of `WALLET`. * `POST /vaults/{vaultId}/wallets`: Accepts `VAULT` again as a resource type, though deprecated in favor of `WALLET`. * `GET /wallets`: Accepts `VAULT` again as a resource type, though deprecated in favor of `WALLET`. * `GET /wallets/{walletId}`: Accepts `VAULT` again as a resource type, though deprecated in favor of `WALLET`. **Impact**: This restores backward compatibility for integrations still using the `VAULT` resource type. We strongly recommend updating existing code to use `WALLET` instead, since support for `VAULT` will be removed in a future release. ## Fixed AML Questionnaire Requirement by Organization Type **Fixed** The `trustedDestinationAmlQuestionnaire` field is now conditionally required based on the organization type. **Category**: Trusted Destinations **Endpoint Changed**: * `POST /trusted_destinations`: The `trustedDestinationAmlQuestionnaire` field is now required for Anchorage Digital organizations and must be omitted for Porto organizations. **Impact**: Requests to create a trusted destination will now fail if `trustedDestinationAmlQuestionnaire` is included for a Porto organization or omitted for an Anchorage Digital organization. ## Added Endpoints for Tax Account Management **Added** new endpoints to the Tax API for managing tax accounts and their associated transactions. **Category**: Tax **Endpoints Added**: * `GET /tax/accounts`: Lists tax accounts. * `GET /tax/accounts/{accountId}/transactions`: Retrieves transactions for a specific tax account. * `PATCH /tax/accounts/{accountId}/transactions/{transactionId}`: Updates the cost basis of a transaction for tax reporting. **Impact**: These new endpoints let you list tax accounts, retrieve transactions for a specific account, and update the cost basis of a transaction for tax reporting purposes. ## Removed TRUSTED\_DESTINATION as a Resource Type **Removed** The `TRUSTED_DESTINATION` value as a valid enum for the resource `type` field. **Category**: Transfers, Withdrawals, Wallets **Endpoints Changed**: * `POST /transactions/withdrawal`: The `destination.type` field no longer accepts `TRUSTED_DESTINATION`. * `POST /transfers`: The `destination.type` field no longer accepts `TRUSTED_DESTINATION`. * `GET /transfers`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`. * `GET /transfers/{transferId}`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`. * `GET /vaults/{vaultId}/wallets`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`. * `POST /vaults/{vaultId}/wallets`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`. * `GET /wallets`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`. * `GET /wallets/{walletId}`: The `type` field in responses no longer returns `TRUSTED_DESTINATION`. **Impact**: This is a breaking change. API calls using `destination.type: TRUSTED_DESTINATION` will now fail. Specify the underlying `ADDRESS` or `WALLET` directly when creating transfers or withdrawals. ## Improved Tax Transaction Tagging with IRS Combination Codes **Improved** The `distributionCode` field for tagging tax transactions now supports IRS combination codes. **Category**: Tax **Endpoint Changed**: * `POST /tax/transaction/{transactionId}/tag`: The `distributionCode` field now accepts combination codes (for example, `1B`, `4G`, `7B`) as valid enum values. **Impact**: This allows for more accurate tax reporting when a distribution has multiple applicable IRS classifications, such as using `4G` for a death-related direct rollover. ## Improved Collateral Management Operations with Liquidation Details **Improved** The response for Collateral Management Operations now includes liquidation details and an update timestamp. **Category**: Collateral Management **Endpoints Changed**: * `PATCH /collateral_management/operations/{operationId}`: The `CMOperation` model now includes `updatedAt`, `liquidationCollateralPackageId`, `liquidationProceedAsset`, and `liquidationProceedQuantity`. * `GET /collateral_management/operations`: The `CMOperation` model now includes `updatedAt`, `liquidationCollateralPackageId`, `liquidationProceedAsset`, and `liquidationProceedQuantity`. **Impact**: This provides more comprehensive data on operations, particularly those involving liquidations. ## Improved API Key Info Response with WRITE\_TAX Permission **Improved** Added the new `WRITE_TAX` permission type, which now appears in the response for the get API key info endpoint. **Category**: API Key **Endpoint Changed**: * `GET /apikey`: The `permissions` array in the response now includes `WRITE_TAX` for API keys that have this permission. **Impact**: This is a non-breaking change. **Example**: ```json theme={null} { "data": { "id": "b5a58566763e77e2d87a53463013981be7c0b048c1c0dd39ba44e77c99bc1351", "permissions": [ { "permission": "READ", "vaultIds": [ "1c920f4241b78a1d483a29f3c24b6c4c" ] }, { "permission": "WRITE_TAX" } ] } } ``` ## Added AML Questionnaire to Trusted Destination Creation **Added** an optional `trustedDestinationAmlQuestionnaire` object to the request body for creating trusted destinations, so Anti-Money Laundering information can be submitted upfront. **Category**: Trusted Destinations **Endpoint Changed**: * `POST /trusted_destinations`: Accepts an optional `trustedDestinationAmlQuestionnaire` object within each item of the `trustedDestinations` array. **Impact**: This is a non-breaking change. Providing AML information when creating a trusted destination can streamline the approval process for future withdrawals to that address. **Example**: ```json theme={null} { "idempotentId": "1ca86e65-4340-4876-85f4-8334852b9c43", "owner": { "type": "CUSTOMER", "id": "your-customer-id" }, "trustedDestinations": [ { "assetType": "BTC", "address": "2N19AcihQ1a4MxQW658UFHTioUNnMkiHPkw", "name": "My Exchange Wallet", "description": "BTC wallet at Example Exchange", "trustedDestinationAmlQuestionnaire": { "destinationType": "FINANCIAL_INSTITUTION", "institutionName": "Example Exchange", "institutionCountry": "US", "recipientType": "DESTINATION_INSTITUTION" } } ] } ``` ## Improved Deposit Address Security with V2 Signatures **Improved** security by introducing a V2 signature scheme for deposit addresses. **Category**: Addresses, Wallets **Endpoints Changed**: * `GET /vaults/{vaultId}/addresses`: Signed address responses can now include `signatureVersion` and `certChain` fields. * `POST /wallets/{walletId}/addresses`: Signed address responses can now include `signatureVersion` and `certChain` fields. * `GET /vaults/{vaultId}/wallets`: Signed address responses can now include `signatureVersion` and `certChain` fields. * `POST /vaults/{vaultId}/wallets`: Signed address responses can now include `signatureVersion` and `certChain` fields. * `GET /wallets`: Signed address responses can now include `signatureVersion` and `certChain` fields. * `GET /wallets/{walletId}`: Signed address responses can now include `signatureVersion` and `certChain` fields. **Impact**: This is a backward-compatible change that gives clients a more robust, certificate-based way to verify deposit address authenticity. When `signatureVersion` is `V2`, the `certChain` field contains an x509 certificate chain for verification against a trusted Anchorage Digital Root CA; if `certChain` is absent, use the existing V1 signature verification method. See the [Address Verification guide](https://developers.anchorage.com/docs/address-verification) for instructions. ## Added MINT Transaction Type **Added** `MINT` as a new transaction type to represent assets minted or created on the blockchain. **Category**: Transactions **Endpoints Changed**: * `GET /transactions`: The `types` query parameter now accepts `MINT` to filter transactions, and the `transactionType` field in the response can now return `MINT`. * `GET /transactions/{transactionId}`: The `transactionType` field in the response can now return `MINT`. **Impact**: You can now filter for and identify `MINT` transactions across both the list and single-transaction endpoints. ## Improved Error Handling for Collateral Package Updates **Improved** error handling by adding a new `422 Unprocessable Entity` error response to the update collateral package endpoint. **Category**: Collateral Management **Endpoint Changed**: * `PATCH /collateral_management/packages/{packageId}`: Now returns `422 Unprocessable Entity` for requests that are syntactically correct but semantically invalid. **Impact**: This lets clients differentiate between a bad request (`400`), a resource not found (`404`), and an unprocessable entity (`422`). ## Improved Pricing Options for Collateral Management **Improved** Added new options for price strategy and price source to provide more flexibility in Collateral Management configurations. **Category**: Collateral Management **Endpoints Changed**: * `POST /collateral_management/packages`: The `priceStrategy` field now accepts `VWAP`, and the `priceSource` field now accepts `KAMINO`. * `PATCH /collateral_management/packages/{packageId}`: The `priceStrategy` field now accepts `VWAP`, and the `priceSource` field now accepts `KAMINO`. * `POST /collateral_management/exposures`: The `priceStrategy` field now accepts `VWAP`, and the `priceSource` field now accepts `KAMINO`. **Impact**: You can now specify `VWAP` (Volume-Weighted Average Price) as a pricing strategy and `KAMINO` as a price source when creating or updating collateral packages and exposures. ## Added BURN Transaction Type **Added** a new `BURN` transaction type to represent assets that are burned or destroyed on the blockchain. **Category**: Transactions **Endpoints Changed**: * `GET /transactions`: The `types` query parameter now accepts `BURN` to filter transactions, and the `transactionType` field in the response can now return `BURN`. * `GET /transactions/{transactionId}`: The `transactionType` field in the response can now return `BURN`. **Impact**: This helps with clearer categorization of on-chain asset destruction events. ## Removed priceSourceProvider from Collateral Management Endpoints **Removed** the `priceSourceProvider` field from the request bodies of several Collateral Management endpoints. **Category**: Collateral Management **Endpoints Changed**: * `POST /collateral_management/packages`: The `priceSourceProvider` field is no longer available in `collateralAssetsConfig`. * `PATCH /collateral_management/packages/{packageId}`: The `priceSourceProvider` field is no longer available in `collateralAssetsConfig`. * `POST /collateral_management/exposures`: The `priceSourceProvider` field is no longer available in `assetTrackingConfig`. **Impact**: API requests that include the `priceSourceProvider` field will now result in an error. Update your integrations to remove this field to ensure successful requests. ## Improved Collateral Management Operations with GAS\_FEE Action **Improved** the `CMOperation` model to include a new `GAS_FEE` action type. **Category**: Collateral Management **Endpoints Changed**: * `PATCH /collateral_management/operations/{operationId}`: The `action` field in the response can now include `GAS_FEE`. * `GET /collateral_management/operations`: The `action` field in the response can now include `GAS_FEE`. **Impact**: This provides more granular detail on operation types. ## Improved Fiat Deposit Instructions with Memo Field **Improved** A `memoField` has been added to the `depositInstruction` object returned for fiat wallets. **Category**: Wallets **Endpoints Changed**: * `GET /vaults/{vaultId}/wallets`: The `depositInstruction` object for fiat wallets now includes `memoField`. * `POST /vaults/{vaultId}/wallets`: The `depositInstruction` object for fiat wallets now includes `memoField`. * `GET /wallets`: The `depositInstruction` object for fiat wallets now includes `memoField`. * `GET /wallets/{walletId}`: The `depositInstruction` object for fiat wallets now includes `memoField`. **Impact**: This is a non-breaking, additive change. Include this memo on wire deposits to ensure funds are attributed correctly to the wallet. **Example**: ```json theme={null} "depositInstruction": { "memoField": "123456789", "bankName": "Example Bank", "bankRoutingNumber": "123456789", "bankAddress": "123 Main Street, Anytown, USA 12345", "bankSwiftCode": "12345678", "beneficiaryName": "John Doe", "beneficiaryAddress": "123 Main Street, Anytown, USA 12345", "beneficiaryAccountNumber": "12345678" } ``` ## Improved Wallet Details with Fiat Deposit Instructions **Improved** Wallet-related endpoints now include a `depositInstruction` object with banking details for fiat wallets, distinct from crypto wallet addresses. **Category**: Wallets **Endpoints Changed**: * `GET /vaults/{vaultId}/wallets`: The response now conditionally includes the `depositInstruction` object for fiat wallets. * `POST /vaults/{vaultId}/wallets`: The response now conditionally includes the `depositInstruction` object for fiat wallets. * `GET /wallets`: The response now conditionally includes the `depositInstruction` object for fiat wallets. * `GET /wallets/{walletId}`: The response now conditionally includes the `depositInstruction` object for fiat wallets. **Impact**: The `depositAddress` object remains for crypto wallets. The description for the `assets` array has also been clarified to state that it may be empty. **Example**: ```json theme={null} "depositInstruction": { "bankName": "Example Bank", "bankAddress": "123 Finance St, New York, NY", "bankRoutingNumber": "123456789", "bankSwiftCode": "EXMPUS33", "beneficiaryName": "Anchorage Digital Bank, N.A.", "beneficiaryAddress": "456 Custody Ave, Sioux Falls, SD", "beneficiaryAccountNumber": "987654321", "memoField": "For further credit to [Your Org Name]" } ``` ## Improved Collateral Management Package Updates and API Refinements **Improved** the Collateral Management API for more comprehensive control and clarity, including support for partial updates to a package's entire configuration. **Category**: Collateral Management **Endpoints Changed**: * `PATCH /collateral_management/packages/{packageId}`: You can now update nearly all configuration details of a package, including `clientReferenceId`, `collateralAssetsConfig`, `ltvRoundingPrecision`, `priceStrategy`, and settings for `critical`, `marginCall`, `marginReturn`, and `autoDeleveraging` levels; omitted fields remain unchanged. * `PATCH /collateral_management/operations/{operationId}`: The `type` field no longer accepts the `LIQUIDATION` enum value, and the `typeId` description was improved for clarity. * `POST /collateral_management/operations`: The `type` field no longer accepts the `LIQUIDATION` enum value, and the `typeId` description was improved for clarity. * `GET /collateral_management/exposures`: Field descriptions were updated for accuracy and clarity. * `POST /collateral_management/packages`: Field descriptions were updated for accuracy and clarity. * `GET /collateral_management/packages`: Field descriptions were updated for accuracy and clarity. **Impact**: These changes provide significantly more flexibility for programmatically managing collateral packages and improve the overall clarity and usability of the Collateral Management API. ## Added Collateral Management Operation Actions **Added** new `action` types for creating and updating Collateral Management operations. **Category**: Collateral Management **Endpoints Changed**: * `POST /collateral_management/operations`: The `action` field now supports `CLOSE_RETURN`, `REHYPE_IN`, and `REHYPE_OUT`. * `PATCH /collateral_management/operations/{operationId}`: The `action` field now supports `CLOSE_RETURN`, `REHYPE_IN`, and `REHYPE_OUT`. **Impact**: You can now create and update operations to manage the closing of returns and rehypothecation for collateral packages. ## Added Fields for Tax Transaction Tagging **Added** new conditional fields for tagging tax transactions to support more detailed reporting. **Category**: Tax **Endpoint Changed**: * `POST /tax/transaction/{transactionId}/tag`: The request body now supports `distributionCode` (required when `tag` is `distribution`), `totalDistribution` (required when `tag` is `distribution`), and `postponedLateReason` (required when `tag` is `postponed` or `late-rollover`). **Impact**: When tagging transactions with `distribution`, `postponed`, or `late-rollover`, you must now provide these additional details for more accurate tax reporting. **Example**: ```json theme={null} { "accountId": "SubaccountID", "tag": "distribution", "taxYear": "2024", "distributionCode": "1", "totalDistribution": true } ``` ## Improved Collateral Management API Clarity and Field Support **Improved** several Collateral Management endpoints for clarity and functionality, with updated field descriptions and examples throughout. **Category**: Collateral Management **Endpoints Changed**: * `POST /collateral_management/packages`: Removed the `defaultGroupId` parameter from the request body. * `GET /collateral_management/packages`: Removed `acceleratedMarginCall` from the response, and added `CURE_PERIOD_EXPIRED` and `DEFAULTED` to the `state` enum. * `POST /collateral_management/exposures`: Descriptions improved for clarity. * `GET /collateral_management/exposures`: Descriptions improved for clarity. * `POST /collateral_management/operations`: Removed several unsupported enum values from the `action` field to reflect currently available actions. * `GET /collateral_management/operations`: Descriptions improved for clarity. * `PATCH /collateral_management/operations/{operationId}`: Removed several unsupported enum values from the `action` field to reflect currently available actions. **Impact**: Descriptions were improved across all listed endpoints for parameters such as `clientReferenceId`, `pledgorId`, `curePeriod`, `ltv`, and `topUpType`, giving clearer guidance when configuring collateral packages, exposures, and operations. ## Improved Price Strategy Options with BID and ASK **Improved** Added `BID` and `ASK` as valid options for the `priceStrategy` field when creating collateral packages and exposures. **Category**: Collateral Management **Endpoints Changed**: * `POST /collateral_management/packages`: The `priceStrategy` field now accepts `BID` and `ASK`. * `POST /collateral_management/exposures`: The `priceStrategy` field now accepts `BID` and `ASK`. **Impact**: This provides more granular control over pricing strategy, letting you specify whether the bid or ask price should be used when creating new collateral packages and exposures. ## Improved Filtering for List Orders Endpoint **Improved** order filtering capabilities by adding a new `orderTypes` parameter. **Category**: Trading **Endpoint Changed**: * `GET /trading/orders`: Accepts a new optional `orderTypes` query parameter, an array of strings to filter by order type (`LIMIT`, `MARKET`, `STOP_LOSS`, `STOP_LIMIT`, `TAKE_PROFIT_LIMIT`, `TWAP`, `VWAP`, `PEGGED`, `POV`, `OTHER`). **Impact**: This allows for more granular querying of orders, letting you retrieve only the specific order types you're interested in. **Example**: `GET /v2/trading/orders?orderTypes=LIMIT,STOP_LIMIT` ## Improved Customer Onboarding with Single-Call Submission **Improved** the customer onboarding workflow by adding an optional `submit` parameter. **Category**: Onboarding **Endpoint Changed**: * `POST /onboarding/customers`: Accepts a new optional boolean `submit` parameter. **Impact**: This is a non-breaking change. When `submit` is `true`, the application is created and submitted in a single call, eliminating the need for a separate submission request and reducing the number of required API calls. ## Improved Price Source Options with KRAKEN **Improved** Added `KRAKEN` as a supported price source for collateral management. **Category**: Collateral Management **Endpoints Changed**: * `POST /collateral_management/packages`: The `priceSource` field now accepts `KRAKEN`. * `POST /collateral_management/exposures`: The `priceSource` field now accepts `KRAKEN`. **Impact**: This provides more flexibility by letting you select Kraken as the data source for asset pricing when configuring collateral. # Errors, rate limits, and pagination Source: https://docs.anchorage.com/knowledge-base/api-reference/errors-pagination Understand Anchorage API status codes, rate limits, idempotent retries, and cursor pagination. Standard HTTP status codes with a human-readable error message when requests fail. Know your limits when accessing the Anchorage API to avoid 429 errors. Required on certain endpoints to avoid duplicative operations. Paginate through pages of API results. ## Status codes | Code | Meaning | | ----------------------- | -------------------------------------------------------------------------------------------------------------------- | | `200 OK` | The request was successful. | | `400 Bad Request` | The request was improperly formed, often due to invalid syntax, insufficient funds, or a missing required parameter. | | `401 Unauthorized` | The request was missing a valid API key. | | `403 Forbidden` | The API key does not have permission to perform the requested action. | | `404 Not Found` | The requested resource does not exist. | | `409 Conflict` | The requested action cannot proceed because the resource is not in the required state. | | `429 Too Many Requests` | Too many requests were sent in a given amount of time. | | `5xx` | Something went wrong on Anchorage Digital's side. | ### Common money movement errors These are the failures developers hit most often when moving assets, and how to resolve each. | Symptom | Likely cause | Resolution | | :------------------------------------------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `403` on an external transfer (`Cannot find role permission action for external transfers`) | The key's permission group doesn't have external transfers enabled, or a destination-scoped permission isn't connected to the destination. | Enable external transfers on the permission group. If the permission is scoped to specific destinations, connect the trusted destination to the group and endorse it. See [Permission groups and API keys](/knowledge-base/platform/developers/move-money/setup/permission-groups). | | `403` on any movement | The key lacks the required permission for the source vault (for example `Transfer funds` or `Initiate withdrawals`). | Grant the permission to the key's group and re-endorse. | | `400` insufficient funds | The amount plus the network fee exceeds the wallet's available balance. | Lower the amount, or on transfers set `deductFeeFromAmountIfSameType: true` to net the fee out of the amount. | | `400` invalid or unsupported | A required field is missing, or the source wallet or destination doesn't support the asset. | Confirm the asset (`GET /v2/asset-types`) and that both source and destination support it. | | `409` conflict on a withdrawal | A withdrawal is already in flight from the source wallet—withdrawals don't queue. | Wait for the in-flight withdrawal to broadcast or fail, then retry. | | `429` too many requests | The org-wide rate limit was exceeded. | Back off and retry (see [Retries and backoff](#retries-and-backoff)). | A request that returns `201` can still fail at execution—after quorum approval or at broadcast—if there are insufficient funds for the network fee or a blockchain-level failure occurs. Track terminal status via [Track movement status](/knowledge-base/platform/developers/move-money/operate/track-status). ## Rate limits Keys provisioned by an organization share one common rate limit. API requests are limited to `20 requests/second` per organization, allowing bursts of up to `100 requests` within a single second. ## Idempotency Certain endpoints support idempotent requests so retries do not perform the same operation twice. For example, if a transfer request does not respond because of a network issue, retry with the same idempotent ID to ensure only one transfer is created. For supported endpoints, include a unique `idempotentId` in the `POST` request body. ```json theme={null} { "idempotentId": "9f8fbb54-7f5b-4993-829b-758b4c5f7e65" } ``` ## Retries and backoff Retry `429` and `5xx` responses with exponential backoff—for example, 1s, 2s, 4s, then 8s. When retrying a `POST`, reuse the same `idempotentId` so a request that succeeded but didn't return its response doesn't execute twice. Don't retry other `4xx` responses: they indicate a request that needs to be corrected, not repeated. ## Pagination Cursor pagination is used for endpoints that return multiple records. Responses include a `next` cursor in the `page` attribute when more results are available. ```http theme={null} GET /v2/transfers?afterId=1968b94b09b8a1a8a381775d1f04978c424d891d50e517774bf984297985b471&limit=100 ``` | Parameter | Description | | --------- | ------------------------------------------------------------------------------------------------------------------- | | `afterId` | Request a page after, or older than, this pagination ID. | | `endDate` | Request records older than this date in `YYYY-MM-DD` format. Used for `/trading/trades` and `/trading/settlements`. | | `limit` | Maximum number of results requested. Defaults vary by resource. | # Introduction Source: https://docs.anchorage.com/knowledge-base/api-reference/introduction Introduction for the Anchorage Digital REST API v2.0 The Anchorage Digital API is a REST API that consists of 100+ operations across custody, wallets, transfers, trading, Atlas settlement, onboarding, tax, subaccounts, webhook notifications, and more. Building with an AI assistant? Connect the Anchorage Digital docs MCP server or start from ready-made prompts. See [Build with AI](/knowledge-base/build-with-ai/overview). ## Base URLs | Environment | Base URL | | :---------- | :---------------------------------- | | Sandbox | `https://api.anchorage-staging.com` | | Production | `https://api.anchorage.com` | ## Send your first API call Define which vaults and operations the API key can access. See [Permission groups](/knowledge-base/platform/developers/permission-groups). Generate a key assigned to the permission group. See [API keys](/knowledge-base/platform/developers/api-keys). Sensitive endpoints require an Ed25519 signature in addition to the API key. See [Request signing](/knowledge-base/platform/developers/request-signing). Include your API key in the `Api-Access-Key` header on every request. Add `Api-Signature` and `Api-Timestamp` on sensitive endpoints. ```bash theme={null} curl -X GET \ 'https://api.anchorage-staging.com/v2/apikey' \ -H 'Api-Access-Key: ' \ -H 'Api-Signature: ' \ -H 'Api-Timestamp: ' ``` ## Next steps Learn how requests are signed and attached to headers. Learn how requests are signed and attached to headers. Handle response codes, rate limits, and cursor pagination. # List all addresses for an asset Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/addresses/list-all-addresses-for-an-asset /knowledge-base/openapi/v2.yaml get /vaults/{vaultId}/addresses Permissions required: **Read vault activity** or **Create address** Get all addresses for the asset type within the specified `vaultId`. # Provision a deposit address for a wallet Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/addresses/provision-a-deposit-address-for-a-wallet /knowledge-base/openapi/v2.yaml post /wallets/{walletId}/addresses Permissions required: **Create address** This endpoint allows you to request an asynchronous provision of a signed deposit address for a given wallet. For UTXO-based wallets a new address will always be provisioned upon request. For account-based wallets only one address may be provisioned per wallet and subsequent attempts will return the previously provisioned address. Newly requested addresses may not be available for several minutes once requested. # List information for current API key Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/api-key/list-information-for-current-api-key /knowledge-base/openapi/v2.yaml get /apikey Permissions required: none Get the user information for your API key. As with any endpoint, a signature included in the request will be validated. This can be used to confirm the associated signing key as well information about the current API key. # List supported asset types Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/asset-types/list-supported-asset-types /knowledge-base/openapi/v2.yaml get /asset-types Permissions required: none List all of the supported asset types for your organization. Each asset type object includes the name of the asset (ex. Bitcoin) as well as the asset type (ex. BTC), which usually corresponds to the asset's ticker symbol. #### Filters You may optionally supply the following filters: - Specify the `asset types` to filter the organization asset types. Multiple asset types should be separated by commas. For example: To filter a single asset type to only Bitcoin we can use /v2/asset-types?assetTypes=BTC To filter multiple asset types for instance Bitcoin and Ethereum we could use /v2/asset-types?assetTypes=BTC,ETH - Specify the `feature types` to filter the organization asset types. Multiple features should be separated by commas. For example: To filter all organization assets that have the HOLD feature we can use /v2/asset-types?assetFeatures=HOLDS To filter all organization assets that have the HOLD or TRANSFERS feature we can use /v2/asset-types?assetFeatures=HOLDS,TRANSFERS # Accept a settlement Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/atlas-settlement-network/accept-a-settlement /knowledge-base/openapi/v2.yaml post /atlas/settlements/{settlementId}/accept Permissions required: **Propose and Accept settlements** and **Read vault activity** Accept a proposed settlement and select wallets to receive funds to and/or send funds from. # Authorize a settlement Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/atlas-settlement-network/authorize-a-settlement /knowledge-base/openapi/v2.yaml post /atlas/settlements/{settlementId}/authorize Permissions required: **Authorize Settlements** After your participant has proposed a settlement or accepted a settlement proposal, the details of the settlement must be authorized. To authorize via API, the API key must have a special permission. Otherwise, authorization takes place in the app according to organization policy. # Get a counterparty by ID Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/atlas-settlement-network/get-a-counterparty-by-id /knowledge-base/openapi/v2.yaml get /atlas/directory/counterparties/{counterpartyId} Permissions required: **Read vault activity** Get a single trusted counterparty by its ID. # Get a participant by ID Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/atlas-settlement-network/get-a-participant-by-id /knowledge-base/openapi/v2.yaml get /atlas/directory/participants/{participantId} Permissions required: **Read vault activity** Get a single participant by its ID. # Get a settlement by ID Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/atlas-settlement-network/get-a-settlement-by-id /knowledge-base/openapi/v2.yaml get /atlas/settlements/{settlementId} Permissions required: **Read vault activity** Get a single settlement by its ID. # List participants Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/atlas-settlement-network/list-participants /knowledge-base/openapi/v2.yaml get /atlas/directory/participants Permissions required: **Read vault activity** Get the list of participants you have access to. # List settlements Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/atlas-settlement-network/list-settlements /knowledge-base/openapi/v2.yaml get /atlas/settlements Permissions required: **Read vault activity** Get settlements proposed by you or proposed to you. # List trusted counterparties Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/atlas-settlement-network/list-trusted-counterparties /knowledge-base/openapi/v2.yaml get /atlas/directory/counterparties Permissions required: **Read vault activity** Get trusted counterparties. # Propose a settlement Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/atlas-settlement-network/propose-a-settlement /knowledge-base/openapi/v2.yaml post /atlas/settlements Permissions required: **Propose and Accept settlements** Propose a settlement with a counterparty for a list of assets coming from and/or arriving into wallets owned by your participant. Positive amounts indicate funds to be received and negative amounts indicate funds to be sent. ```json [ { "walletId": "d4578f401daadff65615236c5ad1e12c", "quantity": "-1.1", "assetType": "BTC" }, { "walletId": "43a9aeac02c851f4868f9d89aabde494", "quantity": "20.62", "assetType": "ETH" } ] ``` For example, the above wallet amounts indicate you will send 1.1 BTC from your wallet `d4578f401daadff65615236c5ad1e12c` and receive 20.62 ETH into your wallet `43a9aeac02c851f4868f9d89aabde494`. The steps to create a settlement are: 1. The proposer participant proposes it, selecting an acceptor, assets, amounts and wallets. 2. The proposer authorizes it, either through the API or mobile app signing. 3. The acceptor participant accepts it, selecting wallets to use. 4. (optional) The acceptor authorizes it, either through the API or mobile app signing. 5. The settlement is funded in the sending wallets. 6. The assets are transferred on-chain, as directed by the settlement. Steps 2 or 3 can happen out of order. Step 4 is skipped if the acceptor is not sending any assets. The settlement stays in the `ActionNeeded` state until it reaches step 6. Then it enters the `Executing` state and, after that, it enters one of the final states. # Propose a trusted counterparty Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/atlas-settlement-network/propose-a-trusted-counterparty /knowledge-base/openapi/v2.yaml post /atlas/directory/counterparties Permissions required: **Propose Trusted Counterparty** Propose adding a new trusted counterparty for a participant. # Reject a settlement proposal Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/atlas-settlement-network/reject-a-settlement-proposal /knowledge-base/openapi/v2.yaml post /atlas/settlements/{settlementId}/reject Permissions required: **Propose and Accept settlements** or **Authorize Settlements** Rejects a proposed settlement for your Atlas participant. Proposed settlements cannot be rejected if they have already been authorized. # Request a collateral decrease Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/collateral-decrease POST /collateral_management/packages/{packageId}/collateral-decrease Request a collateral decrease for a package. # Create a new collateral package Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/collateral-management/create-a-new-collateral-package /knowledge-base/openapi/v2.yaml post /collateral_management/packages Permissions required: **Manage Collateral Packages** and **Read vault activity** Creates a new collateral package in the Collateral Management service. # Create a new exposure Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/collateral-management/create-a-new-exposure /knowledge-base/openapi/v2.yaml post /collateral_management/exposures Permissions required: **Manage Collateral Exposures** and **Read vault activity** Creates a new exposure in the Collateral Management service. # Create a new operation Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/collateral-management/create-a-new-operation /knowledge-base/openapi/v2.yaml post /collateral_management/operations Permissions required: **Manage Collateral Packages** and **Read vault activity** Create a new operation in the Collateral Management service. # List collateral and exposure operations Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/collateral-management/list-collateral-and-exposure-operations /knowledge-base/openapi/v2.yaml get /collateral_management/operations Permissions required: **Read vault activity** Get all the operations that were booked for collateral packages and exposures. # List exposures Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/collateral-management/list-exposures /knowledge-base/openapi/v2.yaml get /collateral_management/exposures Permissions required: **Read vault activity** Get Exposures. # List packages Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/collateral-management/list-packages /knowledge-base/openapi/v2.yaml get /collateral_management/packages Permissions required: **Read vault activity** Get collateral packages. # Update a collateral package Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/collateral-management/update-a-collateral-package /knowledge-base/openapi/v2.yaml patch /collateral_management/packages/{packageId} Permissions required: **Manage Collateral Packages** and **Read vault activity** Updates an existing collateral package in the Collateral Management service. # Update an operation Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/collateral-management/update-an-operation /knowledge-base/openapi/v2.yaml patch /collateral_management/operations/{operationId} Permissions required: **Manage Collateral Packages** and **Read vault activity** Update an existing operation in the Collateral Management service. Only the fields provided in the request body will be updated. # Get collateral price sources Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/collateral-price-sources GET /collateral_management/price_sources Get available assets for specific price sources. # Attribute a deposit Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/deposit-attribution/attribute-a-deposit /knowledge-base/openapi/v2.yaml patch /deposit-attributions/{depositTransactionId} Permissions required: **Deposit Attribution**. Attribute a deposit by providing information about the originator. Only attributions in `PENDING` status can be attributed. Once the attribution is successfully performed the attribution status moves from `PENDING` to `UNDER_REVIEW`. For attributions performed via API the attributionType will always be `CLIENT_API`. # Attribute a deposit as spam Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/deposit-attribution/attribute-a-deposit-as-spam /knowledge-base/openapi/v2.yaml post /deposit-attributions/{depositTransactionId}/spam Permissions required: **Deposit Attribution**. Attribute a deposit as spam. Only attributions in `PENDING` status can be attributed. Once the attribution is successfully performed the attribution status moves from `PENDING` to `ATTRIBUTED`. For any spam attribution performed via API, the attributionType will automatically be set to `SPAM` and the deposit's funds will cease to be available. # List deposit attributions Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/deposit-attribution/list-deposit-attributions /knowledge-base/openapi/v2.yaml get /deposit-attributions/attributions Permissions required: **Read Deposit Attribution** or **Deposit Attribution**. Returns all Deposit Attributions for an Organization based on the provided query parameters. Default sorting will be ascending order by createdAt. # Off-chain vesting schedules Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/offchainvesting-schedules GET /offchainvesting/schedules Retrieve off-chain vesting schedules. # Begin new customer onboarding application Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/onboarding/begin-new-customer-onboarding-application /knowledge-base/openapi/v2.yaml post /onboarding/customers Permissions required: **Onboarding** Initiate onboarding application for a new customer of Anchorage Digital # Begin new customer subaccount onboarding application Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/onboarding/begin-new-customer-subaccount-onboarding-application /knowledge-base/openapi/v2.yaml post /onboarding/subaccounts Permissions required: **Onboarding** Initiate onboarding application for a new customer subaccount of Anchorage Digital # Creates a new agreement questionnaire of the given agreementType Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/onboarding/creates-a-new-agreement-questionnaire-of-the-given-agreementtype /knowledge-base/openapi/v2.yaml post /onboarding/agreements/{agreementType} Permissions required: **Onboarding** Creates a new agreement questionnaire # Request a signed URL for document image upload Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/onboarding/request-a-signed-url-for-document-image-upload /knowledge-base/openapi/v2.yaml post /onboarding/customers/{customerId}/document Permissions required: **Onboarding** Request a signed URL for uploading document images for the existing customer onboarding application Note that the URL expires after 15m, you can still generate a new URL if this one expires. If the image file is never uploaded, the document will show as missing in the `GET` response and a new signed URL must be requested. # Retrieve uploaded data and status of all customers onboarding Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/onboarding/retrieve-uploaded-data-and-status-of-all-customers-onboarding /knowledge-base/openapi/v2.yaml get /onboarding/customers Permissions required: **Onboarding** List all customers onboarding application status, missing information and previously uploaded information. # Retrieve uploaded data and status of all onboarding customer subaccounts Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/onboarding/retrieve-uploaded-data-and-status-of-all-onboarding-customer-subaccounts /knowledge-base/openapi/v2.yaml get /onboarding/subaccounts Permissions required: **Onboarding** List all customer subaccounts onboarding application status, missing information and previously uploaded information. # Retrieve uploaded data and status of customer onboarding Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/onboarding/retrieve-uploaded-data-and-status-of-customer-onboarding /knowledge-base/openapi/v2.yaml get /onboarding/customers/{customerId} Permissions required: **Onboarding** Get customer onboarding application status, missing information and previously uploaded information. # Retrieve uploaded data and status of customer subaccount onboarding Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/onboarding/retrieve-uploaded-data-and-status-of-customer-subaccount-onboarding /knowledge-base/openapi/v2.yaml get /onboarding/subaccounts/{subaccountId} Permissions required: **Onboarding** Get customer subaccount onboarding application status, missing information and previously uploaded information. # Retrieves all the agreements questionnaires for the specified agreement type Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/onboarding/retrieves-all-the-agreements-questionnaires-for-the-specified-agreement-type /knowledge-base/openapi/v2.yaml get /onboarding/agreements/{agreementType} Permissions required: **Onboarding** Retrieves all the agreements questionnaires for the specified agreement type # Retrieves the agreement questionnaire of the given agreement type and agreement ID Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/onboarding/retrieves-the-agreement-questionnaire-of-the-given-agreement-type-and-agreement-id /knowledge-base/openapi/v2.yaml get /onboarding/agreements/{agreementType}/{agreementId} Permissions required: **Onboarding** Retrieves the agreement questionnaire for the specified agreement type and agreement ID # Submit a completed customer onboarding application Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/onboarding/submit-a-completed-customer-onboarding-application /knowledge-base/openapi/v2.yaml post /onboarding/customers/{customerId}/submit Permissions required: **Onboarding** Indicate that a customer onboarding application is complete and can be submitted for screening # Submit a completed customer subaccount onboarding application Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/onboarding/submit-a-completed-customer-subaccount-onboarding-application /knowledge-base/openapi/v2.yaml post /onboarding/subaccounts/{subaccountId}/submit Permissions required: **Onboarding** Indicate that a customer subaccount onboarding application is complete and can be submitted for screening # Update customer onboarding application Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/onboarding/update-customer-onboarding-application /knowledge-base/openapi/v2.yaml put /onboarding/customers/{customerId} Permissions required: **Onboarding** Update an existing customer onboarding application. The application data will be updated to match the entries of the update payload. If any field is invalid, the entire update will fail and no data will be updated. # Update customer subaccount onboarding application Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/onboarding/update-customer-subaccount-onboarding-application /knowledge-base/openapi/v2.yaml put /onboarding/subaccounts/{subaccountId} Permissions required: **Onboarding** Update data of an existing customer subaccount onboarding application # Create a Stablecoin Conversion Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/stablecoins/create-a-stablecoin-conversion /knowledge-base/openapi/v2.yaml post /stablecoins/conversion Permissions required: **Convert Stablecoins** Create a stablecoin conversion, either issuance or redemption. Issuance is when USD is converted to the stablecoin. Redemption is when the stablecoin asset is converted to USD. # Get Issue/Redeem History Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/stablecoins/get-issueredeem-history /knowledge-base/openapi/v2.yaml get /stablecoins/history Permissions required: **Convert Stablecoins** Retrieve the history of stablecoin issuance and redemption operations for your organization. Results are paginated and ordered by creation time (newest first). # Get Stablecoin Reserves Entitled Stablecoins Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/stablecoins/get-stablecoin-reserves-entitled-stablecoins /knowledge-base/openapi/v2.yaml get /stablecoins/reserves/entitled-stablecoins Permissions required: **Read vault activity** List the stablecoins whose reserves history your organization is entitled to view. Pass any returned symbol as the `stablecoin` query parameter to `GET /stablecoins/reserves` to retrieve that stablecoin's daily reserves reconciliation history. Returns an empty array when your organization cannot view reserves history for any stablecoin. # Get Stablecoin Reserves History Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/stablecoins/get-stablecoin-reserves-history /knowledge-base/openapi/v2.yaml get /stablecoins/reserves Permissions required: **Read vault activity** Retrieve the daily reserves reconciliation history for a stablecoin your organization is entitled to. Results are paginated and ordered by creation time (newest first). # Download a statement Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/statement-download GET /statements/{statementId}/download Download a statement. # Get statement Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/statement-get GET /statements/{statementId} Get a statement. # List statement types Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/statement-types GET /statement-types List statement types. # List statements Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/statements-list GET /statements List statements. # Cancel Manual Billing Charge Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/subaccounts/cancel-manual-billing-charge /knowledge-base/openapi/v2.yaml delete /subaccounts/billing/charges/{chargeId} Permissions required: **Subaccount** Cancel Manual Billing Charge # Cancels a Withdrawal Request for a subaccount Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/subaccounts/cancels-a-withdrawal-request-for-a-subaccount /knowledge-base/openapi/v2.yaml delete /subaccounts/{subaccountId}/fiat/withdrawals/{transactionId} Permissions required: **Subaccount** Cancels a Withdrawal Request # Create a new subaccount for a given program customer Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/subaccounts/create-a-new-subaccount-for-a-given-program-customer /knowledge-base/openapi/v2.yaml post /subaccounts/customers/{customerId}/accounts Permissions required: **Subaccount** Open a new subaccount for the program customer DEPRECATED, please use /onboarding/accounts # Create a USD Withdrawal Request for a subaccount Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/subaccounts/create-a-usd-withdrawal-request-for-a-subaccount /knowledge-base/openapi/v2.yaml post /subaccounts/{subaccountId}/fiat/withdrawals Permissions required: **Subaccount** Creates a USD Withdrawal Request for an Asset within a Subaccount (FIAT only for now) This will trigger an e-mail to be sent to the program customer to authorize the withdrawal. # Create Manual Billing Charge Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/subaccounts/create-manual-billing-charge /knowledge-base/openapi/v2.yaml post /subaccounts/billing/charges Permissions required: **Subaccount** Create Manual Billing Charge # Create new allocations Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/subaccounts/create-new-allocations /knowledge-base/openapi/v2.yaml post /subaccounts/transactions/allocations Permissions required: **Subaccount** Create new allocation of pre-funded values between the Funding and Program Customers' subaccounts. This is a transactional operation, all transactions will be created successfully or none will. # Create new transactions Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/subaccounts/create-new-transactions /knowledge-base/openapi/v2.yaml post /subaccounts/transactions Permissions required: **Subaccount** Create new transactions between subaccounts of the same Program Customer. This is a transactional operation, all transactions will be created successfully or none will. # Fetches a set of filtered transactions allocations Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/subaccounts/fetches-a-set-of-filtered-transactions-allocations /knowledge-base/openapi/v2.yaml get /subaccounts/transactions/allocations Permissions required: **Subaccount** or **Read Subaccount** Retrieves a filtered set of transactions that are connected to funding allocations. # Fetches a set of Withdrawals Requests for a subaccount Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/subaccounts/fetches-a-set-of-withdrawals-requests-for-a-subaccount /knowledge-base/openapi/v2.yaml get /subaccounts/{subaccountId}/fiat/withdrawals Permissions required: **Subaccount** or **Read Subaccount** Retrieves a filtered set of Withdrawal Requests within a Subaccount (FIAT only for now). # Get list of transactions filter by ID Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/subaccounts/get-list-of-transactions-filter-by-id /knowledge-base/openapi/v2.yaml get /subaccounts/transactions/{transactionsIds} Permissions required: **Subaccount** or **Read Subaccount** Return the requested transactions, sorted by the creation date, the client has access too # Get USD Withdrawal Request for a subaccount Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/subaccounts/get-usd-withdrawal-request-for-a-subaccount /knowledge-base/openapi/v2.yaml get /subaccounts/{subaccountId}/fiat/withdrawals/{transactionId} Permissions required: **Subaccount** Get a USD Withdrawal Request # List all subaccounts Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/subaccounts/list-all-subaccounts /knowledge-base/openapi/v2.yaml get /subaccounts/customers/accounts Permissions required: **Subaccount** or **Read Subaccount** Return all subaccounts associated for an organization # List all transactions Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/subaccounts/list-all-transactions /knowledge-base/openapi/v2.yaml get /subaccounts/transactions Permissions required: **Subaccount** or **Read Subaccount** Return all the transactions, sorted by the creation date, the client has access to # List subaccounts Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/subaccounts/list-subaccounts /knowledge-base/openapi/v2.yaml get /subaccounts/customers/{customerId}/accounts Permissions required: **Subaccount** or **Read Subaccount** Return all subaccounts associated to a customerId # Return bank information for a subaccount Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/subaccounts/return-bank-information-for-a-subaccount /knowledge-base/openapi/v2.yaml get /subaccounts/accounts/{subaccountId}/bank-info Permissions required: **Subaccount** or **Read Subaccount** Return bank information for a subaccount # Return wallets linked to a subaccount Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/subaccounts/return-wallets-linked-to-a-subaccount /knowledge-base/openapi/v2.yaml get /subaccounts/accounts/{subaccountId}/wallets Permissions required: **Subaccount** or **Read Subaccount** Return wallets linked to a subaccount # Update an existing subaccount Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/subaccounts/update-an-existing-subaccount /knowledge-base/openapi/v2.yaml patch /subaccounts/accounts/{subaccountId} Permissions required: **Subaccount** Update a subaccount # Apply tags to an entity Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/tagging/apply-tags-to-an-entity /knowledge-base/openapi/v2.yaml post /tags/apply Apply a set of tags to an entity, replacing the entity's existing tags of the given tag type. Tags are auto-created if they do not exist, and an empty list clears the entity's tags of that type. # List tags Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/tagging/list-tags /knowledge-base/openapi/v2.yaml get /tags List tags filtered by ownership type and/or entity. When entityId is provided, returns tags applied to that entity. When type is provided, filters tag definitions by ownership type. # Remove a tag from an entity Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/tagging/remove-a-tag-from-an-entity /knowledge-base/openapi/v2.yaml delete /tags/apply/{entityId}/{tagName} Remove a specific tag from an entity. Tag name matching is case-insensitive. # Search entities by tag Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/tagging/search-entities-by-tag /knowledge-base/openapi/v2.yaml get /tags/search Search for entities that have specific tags applied. Supports cursor-based pagination. # List deposit transactions for account Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/tax-account-transactions GET /tax/accounts/{accountId}/transactions List deposit transactions for a tax account. # List tax accounts Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/tax-accounts GET /tax/accounts List tax accounts. # Update deposit transaction cost basis Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/tax-transaction-cost-basis PATCH /tax/accounts/{accountId}/transactions/{transactionId} Update the cost basis of a deposit transaction. # Add Tag to Transaction Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/tax/add-tag-to-transaction /knowledge-base/openapi/v2.yaml post /tax/transaction/{transactionId}/tag Permissions required: **Subaccount** Tag a prior transaction for tax purposes. ** Under development ** # Get Program Customer Tax Forms Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/tax/get-program-customer-tax-forms /knowledge-base/openapi/v2.yaml get /tax/clients/{customerId}/forms Permissions required: **Subaccount** Get a program customer's generated tax forms # Get Subaccount Tax Forms Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/tax/get-subaccount-tax-forms /knowledge-base/openapi/v2.yaml get /tax/subaccounts/{subaccountId}/forms Permissions required: **Subaccount** Get subaccount's generated tax forms # List Gains Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/tax/list-gains /knowledge-base/openapi/v2.yaml get /tax/gains/summary/{subaccountId} Permissions required: **Subaccount** List subaccount's gains for a period breakdown to short term, long term and total # List Gains Cost Basis Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/tax/list-gains-cost-basis /knowledge-base/openapi/v2.yaml get /tax/gains/costbasis/{subaccountId} Permissions required: **Subaccount** List subaccount's breakdown of combined cost basis, proceeds and gains/losses # List of the Inventory for an asset Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/tax/list-of-the-inventory-for-an-asset /knowledge-base/openapi/v2.yaml get /tax/inventory/{subaccountId}/{assetTypeId} Permissions required: **Subaccount** List user's inventory for an asset. # List summary of Inventory Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/tax/list-summary-of-inventory /knowledge-base/openapi/v2.yaml get /tax/inventory/summary/{subaccountId} Permissions required: **Subaccount** List user's inventory summary for all assets. # List Transactions Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/tax/list-transactions /knowledge-base/openapi/v2.yaml get /tax/transactions/{subaccountId} Permissions required: **Subaccount** List tax transactions of a subaccount. # Remove Tag from Transaction Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/tax/remove-tag-from-transaction /knowledge-base/openapi/v2.yaml delete /tax/transaction/{transactionId}/tag Permissions required: **Subaccount** Remove tax tag for a prior transaction. ** Under development ** # Update Transaction Cost Basis Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/tax/update-transaction-cost-basis /knowledge-base/openapi/v2.yaml patch /tax/transaction/{transactionId} Permissions required: **Subaccount** Update the cost basis for a deposit or withdraw transaction. # Accept a quote Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trading/accept-a-quote /knowledge-base/openapi/v2.yaml post /trading/quote/accept Permissions required: **Execute trades** Accept a quote by its quoteID and side. #### Idempotent Requests This endpoint supports [idempotent requests](#section/Idempotency) so that a quote cannot be accepted twice if an API call was interrupted and is retried. To send an idempotent request, include the `idempotentId` field in the body of the POST request. # Cancel an async order Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trading/cancel-an-async-order /knowledge-base/openapi/v2.yaml post /trading/async-order/cancel Permissions required: **Execute trades** Cancels an async order. # Get a trading account by id Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trading/get-a-trading-account-by-id /knowledge-base/openapi/v2.yaml get /trading/accounts/{accountId} Permissions required: **Read trade activity** Get trading account details by ID. # Get market data snapshot Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trading/get-market-data-snapshot /knowledge-base/openapi/v2.yaml get /trading/marketdata Permissions required: **Execute trades** or **Read trade activity** Get real-time market data snapshot for a trading symbol from the liquidity provider. # Get order by ID Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trading/get-order-by-id /knowledge-base/openapi/v2.yaml get /trading/orders/{orderId} Permissions required: **Read trade activity** or **Execute trades** (if order created by this API key) Get order by ID, where the ID can be anchorage generated orderId or clientOrderId # Get settlement by ID Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trading/get-settlement-by-id /knowledge-base/openapi/v2.yaml get /trading/settlements/{settlementId} Permissions required: **Execute trades** or **Read trade activity** Get settlement details by ID. # Get trade by ID Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trading/get-trade-by-id /knowledge-base/openapi/v2.yaml get /trading/trades/{tradeId} Permissions required: **Read trade activity** or **Execute trades** (if trade created by this API key) Get trade by ID. # Get trading account credit limit and usage Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trading/get-trading-account-credit-limit-and-usage /knowledge-base/openapi/v2.yaml get /trading/accounts/{accountId}/credit Permissions required: **Read trade activity** Get the credit limit and usage of a trading account per asset. Current USD prices are not returned, only assets and their quantity. Still under development, return empty replies. # List orders Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trading/list-orders /knowledge-base/openapi/v2.yaml get /trading/orders Permissions required: **Execute trades** or **Read trade activity** List all orders. With the permission **Read trade activity** all orders of the organization may be read. With the permission **Execute trades** only the orders created by this API key may be read. Orders are sorted in a descending order by their timestamp, i.e. the most recent order or the order with a timestamp closest to `endDate` is listed first. When filtering by `subaccountId`, the allocation information is included but filtered to show only the allocation for the requested subaccount. For multi-order requests without a subaccount filter, allocation information is not included. To get complete allocation information, use [GET `/v2/trading/orders/{orderId}`](#tag/Trading/operation/getOrderStatus) #### Filters You may optionally supply filters for the list of orders using query parameters below # List outstanding trading positions Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trading/list-outstanding-trading-positions /knowledge-base/openapi/v2.yaml get /trading/positions Permissions required: **Execute trades** or **Read trade activity** Get the list of outstanding trading positions. # List settlements Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trading/list-settlements /knowledge-base/openapi/v2.yaml get /trading/settlements Permissions required: **Execute trades** or **Read trade activity** List of all settlements. With permission **Read trade activity** all settlements of the organization may be read. With permission **Execute trades** only settlements this api key has created may be read. Settlements are sorted in a descending order by their timestamp, i.e. the most recent settlement or the settlement with a timestamp closest to `endDate` is listed first. #### Filters You may optionally supply the following filters: - Specify a one or multiple `status` to filter settlements. Multiple statuses should be separated by commas. # List supported trading pairs Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trading/list-supported-trading-pairs /knowledge-base/openapi/v2.yaml get /trading/pairs Permissions required: **Execute trades** or **Read trade activity** List all of the supported trading pairs for your organization. Each trading pair object includes a description and trading symbol (ex. BTC-USD), which usually corresponds to two asset ticker symbols. Optionally, a trading pair object includes a reference data object that details the trading precision context: minimum size increment and price increment. # List trades Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trading/list-trades /knowledge-base/openapi/v2.yaml get /trading/trades Permissions required: **Execute trades** or **Read trade activity** List all trades. With the permission **Read trade activity** all trades of the organization may be read. With the permission **Execute trades** only the trades created by this API key may be read. Trades are sorted in a descending order by their timestamp, i.e. the most recent trade or the trade with a timestamp closest to `endDate` is listed first. #### Filters You may optionally supply the following filters: - Specify a `tradingPair` to filter by the trading pair of the trade, for example `BTC-USD`. - Specify one or multiple `status` to filter trades. Multiple statuses should be separated by commas. - Specify a `side` to filter by the side of the trade. # List trades by settlement Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trading/list-trades-by-settlement /knowledge-base/openapi/v2.yaml get /trading/settlements/{settlementId}/trades Permissions required: **Execute trades** or **Read trade activity** List trades for the provided settlement. With the permission **Read trade activity** all trades of the organization may be read. With the permission **Execute trades** only the trades created by this API key may be read. Trades are sorted in a descending order by their timestamp (i.e. the most recent trade or the trade with a timestamp closest to `endDateTime` is listed first). # List trading account balances Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trading/list-trading-account-balances /knowledge-base/openapi/v2.yaml get /trading/accounts/{accountId}/balances Permissions required: **Read trade activity** Get the trading account balances of fiat and digital assets # List trading accounts Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trading/list-trading-accounts /knowledge-base/openapi/v2.yaml get /trading/accounts Permissions required: **Read trade activity** Get the list of trading accounts # Place an async order Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trading/place-an-async-order /knowledge-base/openapi/v2.yaml post /trading/async-order Permissions required: **Execute trades** Place an order, either Limit, StopLoss, StopLimit or TakeProfitLimit currently FillOrKill, ImediateOrCancel or GoodTillCancel are supported. One of `accountId` or `subaccountId` must be specified but not both. # Place an order Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trading/place-an-order /knowledge-base/openapi/v2.yaml post /trading/order Permissions required: **Execute trades** Place an order, either Market or Limit, currently only FillOrKill is supported. One of `accountId` or `subaccountId` must be specified but not both. # Request a quote Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trading/request-a-quote /knowledge-base/openapi/v2.yaml post /trading/quote Permissions required: **Execute trades** Request a quote #### Idempotent Requests This endpoint supports [idempotent requests](#section/Idempotency) so that quote is not requested twice if an API call was interrupted and must be retried. To send an idempotent request, include the `idempotentId` field in the body of the POST request. # Create a collect request Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/transactions/create-a-collect-request /knowledge-base/openapi/v2.yaml post /transactions/collect Permissions required: **Initiate Staking and Unstaking** In staking, the "collect" operation is the action of claiming inactive unstaked amount back to the available balance by moving them from the staking protocol or pool into a personal wallet. Once collected, these amounts are fully under wallet's owner control. *NOTE: This endpoint is under development.* # Create a consolidate stake request Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/transactions/create-a-consolidate-stake-request /knowledge-base/openapi/v2.yaml post /transactions/consolidate-stake Permissions required: **Initiate Staking and Unstaking** Consolidate a source staking position into a target staking position. Only supported for Ethereum 0x02 validators. # Create a stake request Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/transactions/create-a-stake-request /knowledge-base/openapi/v2.yaml post /transactions/stake Permissions required: **Initiate Staking and Unstaking** #### Identify the sending asset To initiate a staking operation, you must identify which asset you'd like to stake funds from. Provide a `source` and `assetType`. #### Permissions The provided API key must be associated with a [permission group](#section/Authentication-and-Security/Permission-Groups) that has Initiate Staking and Unstaking permission for the sending vault. #### Additional Metadata You may provide a `description` with each staking operation, that will be visible within your organization in the Anchorage Digital iOS Application. #### Successful Staking If the stake request is valid, the request will initiate a stake transaction from the sending wallet. It will still require a quorum of approvals on the Anchorage Digital iOS app and will undergo manual Anchorage Digital Risk Review. Like other transactions, these will be visible on the Anchorage Digital iOS Application, the Web Dashboard, and in the [list transactions](#operation/getTransactions) API endpoint. #### Unsuccessful Stakes A stake request may fail for any of the following reasons: - An ongoing stake already exists - The specified asset does not exist - The specified amount exceeds the available funds for this asset (insufficient funds) - The provided API key does not have permissions to initiate staking from this vault If the initiated stake is approved by the quorum, the transaction may fail for any of the following reasons: - There are insufficient funds to pay the blockchain network fee at the time of this transaction - There is a failure on the blockchain #### Feature under development Currently, specific assets parameters are under development and will not be considered in any staking request. These include: - Solana staking; - ETH Pectra staking. # Create a withdrawal request Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/transactions/create-a-withdrawal-request /knowledge-base/openapi/v2.yaml post /transactions/withdrawal Permissions required: **Initiate withdrawals** #### Identify the sending asset To initiate a withdrawal from a wallet to an external destination, you must identify which asset you'd like to withdraw funds from. Provide a `source` (with `id` and `type`). #### Identify the receiving resource Choose a resource to receive the funds as the `destination`. This resource may belong to your organization (wallet) or another organization (address, standing instruction). #### Permissions The provided API key must be associated with a [permission group](#section/Authentication-and-Security/Permission-Groups) that has Initiate withdrawals permission for the sending vault. #### Additional Metadata You may provide a `description` with each withdrawal, that will be visible within your organization in the Anchorage Digital iOS Application. #### Successful Withdrawals If the withdrawal request is valid, the request will initiate a withdrawal transaction from the sending wallet. This is a common withdrawal that, unlike Transfers, will still require a quorum of approvals on the Anchorage Digital iOS app and will undergo manual Anchorage Digital Risk Review. Like other transactions, these withdrawals will be visible on the Anchorage Digital iOS Application, the Web Dashboard, and in the [list transactions](#operation/getTransactions) API endpoint. #### Unsuccessful Withdrawals A withdrawal request may fail for any of the following reasons: - An ongoing withdrawal already exists (unlike transfers, withdrawal requests are not queued) - The specified asset does not exist - The specified amount exceeds the available funds for this asset (insufficient funds) - The destination address is invalid - The provided API key does not have permissions to initiate withdrawals from this wallet If the initiated withdrawal is approved by the quorum, the transaction may fail for any of the following reasons: - There are insufficient funds to pay the blockchain network fee at the time of this transaction - There is a failure on the blockchain # Create an unstake request Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/transactions/create-an-unstake-request /knowledge-base/openapi/v2.yaml post /transactions/unstake Permissions required: **Initiate Staking and Unstaking** #### Identify the sending asset To initiate an unstake transaction, you must identify which asset you'd like to unstake funds from. Provide a `source` and `assetType`. #### Permissions The provided API key must be associated with a [permission group](#section/Authentication-and-Security/Permission-Groups) that has Initiate Staking and Unstaking permission for the sending vault. #### Additional Metadata You may provide a `description` with each stake, that will be visible within your organization in the Anchorage Digital iOS Application. #### Successful Unstakes If the stake request is valid, the request will initiate a stake transaction from the sending wallet. It will still require a quorum of approvals on the Anchorage Digital iOS app and will undergo manual Anchorage Digital Risk Review. Like other transactions, these will be visible on the Anchorage Digital iOS Application, the Web Dashboard, and in the [list transactions](#operation/getTransactions) API endpoint. #### Unsuccessful Unstakes A unstake request may fail for any of the following reasons: - An ongoing unstake already exists - The specified asset does not exist - The specified amount exceeds the available funds to unstake for this asset (insufficient funds) - The provided API key does not have permissions to initiate staking from this vault If the initiated stake is approved by the quorum, the transaction may fail for any of the following reasons: - There are insufficient funds to pay the blockchain network fee at the time of this transaction - There is a failure on the blockchain # Get transaction by ID Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/transactions/get-transaction-by-id /knowledge-base/openapi/v2.yaml get /transactions/{transactionId} Permissions required: **Read vault activity** Get transaction by ID. # List supported delegation addresses Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/transactions/list-supported-delegation-addresses /knowledge-base/openapi/v2.yaml get /delegation-addresses/{assetType} Permissions required: **Initiate Staking and Unstaking** #### Identify the sending asset To initiate an operation, you must identify which asset you'd like to view the delegation addresses for. Provide an `assetType`. #### Permissions The provided API key must be associated with a [permission group](#section/Authentication-and-Security/Permission-Groups) that has Initiate Staking and Unstaking permission for the sending vault. # List transactions Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/transactions/list-transactions /knowledge-base/openapi/v2.yaml get /transactions Permissions required: **Read vault activity** List all transactions for the vaults permissioned to your API key. You can retrieve metadata about your API key from the [API Key](#tags/API-Key) endpoints. NOTE: price and USD value information is recent but does not reflect real-time data. **Filters** You may optionally supply the following filters: - Set a date range by providing the `startDate` and/or `endDate` query parameters. The date refers to the end time of a transaction: when the transaction succeeded or failed. If the date parameters are omitted, all transactions will be returned. - Select transactions involving a specific vault by providing the `vaultId` parameter. If the `vaultId` parameter is omitted, transactions for all vaults for which your API key is permissioned will be returned. - Filter transactions of one or more types with the `types` parameter. Multiple types should be separated by commas. - Select transactions involving a specific wallet by providing the `walletId` parameter. If the `walletId` parameter is omitted, transactions for all vaults for which your API key is permissioned will be returned. - Filter transactions by the receiving address with the `destinationAddress` parameter. # Reject a transaction Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/transactions/reject-a-transaction /knowledge-base/openapi/v2.yaml post /transactions/{transactionId}/reject Permissions required: **Reject Operations** Reject an in-progress transaction. The caller's API key must hold the `Reject Operations` permission for the source vault. Operations already in a final state return 409 Conflict. Only withdrawals, transfers, delegations, and generic operations (including bridge transactions) can be rejected via this endpoint; rejecting any other operation type returns 409 Conflict. A transaction can only be rejected before it has been submitted for signing and broadcast to the network. This endpoint cannot be used to cancel a transaction stuck in the broadcasting state due to a low gas fee. # Cancel a transfer request Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/transfers/cancel-a-transfer-request /knowledge-base/openapi/v2.yaml delete /transfers/{transferId} Permissions required: **Transfer funds** Cancel a transfer request. Transfer requests in the `QUEUED` state can always be cancelled. Transfer requests in the `IN_PROGRESS` state can sometimes be cancelled if the request has not been broadcast on the blockchain. Trying to cancel a request that cannot be cancelled will return a `409 Conflict` error code. Transfers can only be canceled by the API key responsible for creating that transfer (either created directly via CreateTransfer or indirectly via ExecuteHold) # Create a transfer request Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/transfers/create-a-transfer-request /knowledge-base/openapi/v2.yaml post /transfers Permissions required: **Transfer funds** #### Identify the sending resource and asset To initiate a transfer between resources, you must identify which resource you'd like to transfer funds from and the asset type to transfer. Provide a `source` and `assetType`. #### Identify the receiving resource Choose a resource to receive the funds as the `destination`. This resource may belong to your organization or another organization that also custodies with Anchorage Digital, or it may also be an approved blockchain address not custodied by Anchorage Digital (see [Permission Groups](#section/Authentication-and-Security/Permission-Groups) for more details). Please note: If you would like to use the Anchorage Digital API to transfer to approved blockchain addresses, please contact [api@anchorage.com](mailto:api@anchorage.com). #### Permissions The provided API key must be associated with a permission group that has Transfer permissions for the vault from which the assets are being sent. The receiving resource does not need Transfer permissions to receive a transfer of funds. #### Additional Metadata You may provide a transfer memo with each transfer. If the transfer API request is successful, a transfer transaction will be created that will include this transfer memo in the description. The resulting deposit will also include this memo. #### Successful Transfers If the transfer request is valid, the request will initiate a transfer transaction from the source. This is a special withdrawal that will not require a quorum of approvals and will undergo automated Anchorage Digital Risk Review. When the transaction is broadcasted and confirmed on the blockchain, a subsequent deposit will be detected for the destination. All of these transactions will be visible on the Anchorage Digital iOS Application, the Web Dashboard, and in the [list transactions](#operation/getTransactions) API endpoint. #### Unsuccessful Transfers A transfer request may fail for any of the following reasons: - The specified sending resource does not exist or does not support the specified asset type - The specified amount exceeds the available funds for this asset (insufficient funds) - The destination does not exist or does not support the specified asset type - The provided API key does not have permissions to initiate transfers from this wallet If the transfer request is successful, the actual transfer transaction may fail for any of the following reasons: - There are insufficient funds to pay the blockchain network fee at the time of this transaction - The transfer was successfully queued but there were insufficient funds by the time it was processed - There is a failure on the blockchain #### Idempotent Requests This endpoint supports [idempotent requests](#section/Idempotency) so that a transfer does not occur twice if an API call was interrupted and must be retried. To send an idempotent request, include the `idempotentId` field in the body of the POST request. #### Queueing Transfer requests are queued and processed in the order they were received. When transferring between wallets, multiple transfer requests may be queued for the same asset in a given wallet, but only one will be processed at a time. The other requests will remain in the `QUEUED` state until the prior transfer is completed or fails. #### Transferring Full Balance For assets with network fees paid in a separate asset type, transferring the full balance of an asset is no different than transferring any other amount for that asset. For assets with network fees paid in the same asset type, transferring the full balance is not possible without specifying to the server that the fee should be deducted from the transfer amount. See the `deductFeeFromAmountIfSameType` flag of the `TransfersRequest` model for more detail. # Get transfer by ID Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/transfers/get-transfer-by-id /knowledge-base/openapi/v2.yaml get /transfers/{transferId} Permissions required: **Transfer funds** Get transfer by ID. Restricted to transfers created by your API key, unless your API key's Transfer and Read permissions both cover the transfer's vault. NOTE: price and USD value information is recent but does not reflect real-time data. # List transfers Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/transfers/list-transfers /knowledge-base/openapi/v2.yaml get /transfers Permissions required: **Transfer funds** List transfers created by your API key. For a given vault, transfers on it created by other API keys in your organization are also included if your API key's Transfer and Read permissions both cover that vault. **Filters** You may optionally supply the following filters: - Set a date range by providing the `startDate` and/or `endDate` query parameters. If the date parameters are omitted, all transfers will be returned. - Specify a specific vault to return transfers for by specifying the `vaultId` parameter. If the `vaultId` parameter is omitted, transfers originating from all vaults will be returned. Providing both `vaultId` and `walletId` filters will result in an error. - Specify a specific wallet to return transfers for by specifying the `walletId` parameter. If the `walletId` parameter is omitted, transfers originating from all vaults and wallets will be returned. Providing both `vaultId` and `walletId` filters will result in an error. - Filter transfers of one or more statuses with the `statuses` parameter. Multiple statuses should be separated by commas. **Multiple Transfers** To fetch a specific batch of transfers, pass a comma-separated list of `transferIds` as the `transferIds` query parameter. # Cancel Trusted Destination creation Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trusted-destinations/cancel-trusted-destination-creation /knowledge-base/openapi/v2.yaml delete /trusted_destinations/{creationRequestId}/cancel Permissions required: **Manage Trusted Destinations** Cancel ongoing creation of Trusted Destinations # Check status of Trusted Destinations Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trusted-destinations/check-status-of-trusted-destinations /knowledge-base/openapi/v2.yaml get /trusted_destinations/{creationRequestId}/status Permissions required: **Read vault activity** Check status of Trusted Destinations # Create new Trusted Destinations Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trusted-destinations/create-new-trusted-destinations /knowledge-base/openapi/v2.yaml post /trusted_destinations Permissions required: **Manage Trusted Destinations** Create new Trusted Destinations # Delete Trusted Destination Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trusted-destinations/delete-trusted-destination /knowledge-base/openapi/v2.yaml delete /trusted_destinations/{trustedDestinationId} Permissions required: **Manage Trusted Destinations** Delete a Trusted Destination # List trusted destinations Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/trusted-destinations/list-trusted-destinations /knowledge-base/openapi/v2.yaml get /trusted_destinations Permissions required: **Read vault activity** List trusted destinations # Get vault by ID Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/vaults/get-vault-by-id /knowledge-base/openapi/v2.yaml get /vaults/{vaultId} Permissions required: **Read vault activity** Get vault by ID # List vaults Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/vaults/list-vaults /knowledge-base/openapi/v2.yaml get /vaults Permissions required: **Read vault activity** List vault metadata including name, ID, description, and assets. NOTE: price and USD value information is recent but does not reflect real-time data. # Get vesting balances Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/vesting-balances-batch POST /vesting/balances Get vesting balances for multiple allocations. # Get vesting balances for an allocation Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/vesting/get-vesting-balances-for-an-allocation /knowledge-base/openapi/v2.yaml get /vesting/balances/{allocationId} Get vesting balances for a specific allocation ID. Returns the current balance breakdown including available, unvested, and locked amounts. # Activate an existing wallet on additional networks Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/wallets/activate-an-existing-wallet-on-additional-networks /knowledge-base/openapi/v2.yaml post /wallets/{walletId}/activate Permissions required: **Create address** Activate the existing wallet identified by `walletId` on additional networks that share the same cryptographic key derivation (e.g. EVM-compatible chains). Each entry in `compatibleNetworkIds` produces a new wallet on that network with the same address as the source. Per-network failures are reported individually in the response without aborting the whole call: a target network that is not key-compatible with the source wallet's network, or that the organization has not enabled, returns a `FAILED` status for that entry while other entries continue. # Create a new wallet in a vault Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/wallets/create-a-new-wallet-in-a-vault /knowledge-base/openapi/v2.yaml post /vaults/{vaultId}/wallets Permissions required: **Create address** Create a wallet in the specified `vaultId`. # List all wallets for a vault Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/wallets/list-all-wallets-for-a-vault /knowledge-base/openapi/v2.yaml get /vaults/{vaultId}/wallets Permissions required: **Read vault activity** Get all wallets for the specified `vaultId`. # List all wallets for all vaults Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/wallets/list-all-wallets-for-all-vaults /knowledge-base/openapi/v2.yaml get /wallets Permissions required: **Read vault activity** List wallet metadata for the current user. # Staking positions for a wallet Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/wallets/staking-positions-for-a-wallet /knowledge-base/openapi/v2.yaml get /wallets/{walletId}/staking/positions Permissions required: **Read vault activity** Get wallet staking positions details for the specified `walletId`. # Staking rewards for a wallet Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/wallets/staking-rewards-for-a-wallet /knowledge-base/openapi/v2.yaml get /wallets/{walletId}/staking/rewards Permissions required: **Read vault activity** Get wallet rewards details for the specified `walletId`. # Wallet details for a wallet Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/wallets/wallet-details-for-a-wallet /knowledge-base/openapi/v2.yaml get /wallets/{walletId} Permissions required: **Read vault activity** Get wallet details for the specified `walletId`. # Cancel webhook subscription Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/webhook-notifications/cancel-webhook-subscription /knowledge-base/openapi/v2.yaml delete /webhook/endpoints/{endpointId}/subscriptions/{eventTypeId} Permissions required: **Configure Webhooks** Cancel a webhook subscription to stop receiving notifications for its event type in its webhook endpoint. # Create webhook endpoint Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/webhook-notifications/create-webhook-endpoint /knowledge-base/openapi/v2.yaml post /webhook/endpoints Permissions required: **Configure Webhooks** Create a new endpoint where you would like to receive webhook notifications. # Create webhook subscriptions Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/webhook-notifications/create-webhook-subscriptions /knowledge-base/openapi/v2.yaml post /webhook/endpoints/{endpointId}/subscriptions Permissions required: **Configure Webhooks** Subscribe to event types to receive notifications in a webhook endpoint. # Get webhook endpoint config Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/webhook-notifications/get-webhook-endpoint-config /knowledge-base/openapi/v2.yaml get /webhook/endpoints/{endpointId} Permissions required: **Configure Webhooks** Get the configuration details for an endpoint. # Get webhook validation key Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/webhook-notifications/get-webhook-validation-key /knowledge-base/openapi/v2.yaml get /webhook/validation-key Permissions required: **Configure Webhooks** Get key to validate webhook authenticity. # List webhook endpoint Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/webhook-notifications/list-webhook-endpoint /knowledge-base/openapi/v2.yaml get /webhook/endpoints Permissions required: **Configure Webhooks** List all of your webhook endpoints. # List webhook endpoint subscriptions Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/webhook-notifications/list-webhook-endpoint-subscriptions /knowledge-base/openapi/v2.yaml get /webhook/endpoints/{endpointId}/subscriptions Permissions required: **Configure Webhooks** List the subscriptions that you configured for a webhook endpoint. # List webhook event types Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/webhook-notifications/list-webhook-event-types /knowledge-base/openapi/v2.yaml get /webhook/event-types Permissions required: **Configure Webhooks** List the available webhook event types that you can subscribe to. # Update webhook endpoint Source: https://docs.anchorage.com/knowledge-base/api-reference/v2/webhook-notifications/update-webhook-endpoint /knowledge-base/openapi/v2.yaml patch /webhook/endpoints/{endpointId} Permissions required: **Configure Webhooks** Update the configuration for an endpoint. # Connect your AI assistant Source: https://docs.anchorage.com/knowledge-base/build-with-ai/connect-ai-assistant Add Anchorage Digital docs to your AI tools through the hosted MCP server. Connect our documentation to your AI assistant so it can answer questions and generate integration code grounded in the current docs. Anchorage Digital hosts a Model Context Protocol (MCP) server for this site. ## What the docs MCP server does The MCP server lets your assistant search these docs and read pages on demand. It's read-only documentation knowledge—it can't access your account, keys, or funds, and it can't move assets. To take actions, your integration calls the REST API with your own scoped keys. | Server | URL | Use for | | :----------------- | :-------------------------------------- | :------------------------------------------------------------ | | Public docs | `https://docs.anchorage.com/mcp` | Public documentation | | Authenticated docs | `https://docs.anchorage.com/authed/mcp` | Documentation restricted to your account, after OAuth sign-in | Opening `https://docs.anchorage.com/authed/mcp` directly in a browser returns `401 Unauthorized`. That endpoint is not a web page — it is an MCP transport, and authentication is browser-based OAuth triggered by your MCP client, not a token you paste in. Add the URL to an MCP client that supports OAuth (Claude Desktop, Claude Code, Cursor, VS Code, ChatGPT). When the client first connects, it opens a browser window to sign in with your Anchorage Digital account. There are no client IDs, secrets, or long-lived tokens to configure. If your client doesn't open a sign-in window, it doesn't support OAuth — use `https://docs.anchorage.com/mcp` instead. ## Quick install The fastest path is the one-line installer, which detects your installed tools: ```bash theme={null} npx add-mcp https://docs.anchorage.com/mcp ``` You can also open the AI menu at the top of any docs page and choose an install option, such as Cursor, VS Code, or Copy MCP. ## Set up by tool ### Claude Code ```bash theme={null} claude mcp add --transport http anchorage-docs https://docs.anchorage.com/mcp ``` ### Claude Desktop and Claude web In Settings, select **Connectors**, then select **Add custom connector**. Enter a name and the URL `https://docs.anchorage.com/mcp`, then save. ### Cursor Add the server to `mcp.json`: ```json theme={null} { "mcpServers": { "anchorage-docs": { "url": "https://docs.anchorage.com/mcp" } } } ``` ### VS Code (GitHub Copilot) Add the server to `.vscode/mcp.json`: ```json theme={null} { "servers": { "anchorage-docs": { "type": "http", "url": "https://docs.anchorage.com/mcp" } } } ``` ### ChatGPT and other clients In any client that supports custom MCP connectors, add a new connector with the URL `https://docs.anchorage.com/mcp`. To include documentation restricted to your account, use `https://docs.anchorage.com/authed/mcp` and sign in when prompted. The docs MCP server provides documentation only. It never has access to your API keys or the ability to move assets. See [AI security and guardrails](/knowledge-base/build-with-ai/security). ## Next steps With your assistant connected, start from a [ready-made prompt](/knowledge-base/build-with-ai/prompts), or review the [security guardrails](/knowledge-base/build-with-ai/security) before you write code that moves assets. # LLM-ready docs Source: https://docs.anchorage.com/knowledge-base/build-with-ai/llm-ready-docs Pull Anchorage Digital documentation into any AI tool as Markdown. Every page in these docs is available as clean Markdown that AI tools can read. Use whichever method fits the size of the task—a single page, a product area, or the whole site. ## Copy or open any page Every page has an AI menu at the top. Use it to copy the page as Markdown, view the raw Markdown, open the page in Claude, ChatGPT, Perplexity, or Google AI Studio, or add the docs to Cursor or VS Code. ## Get a page as Markdown Append `.md` to any page URL to get its Markdown directly: ```text theme={null} https://docs.anchorage.com/platform/developers/setting-up.md ``` This is the cleanest way to hand one page to an AI tool or fetch it programmatically. ## Get the whole site We publish the entire documentation set as a single file for LLM ingestion: ```text theme={null} https://docs.anchorage.com/llms-full.txt ``` The same file is mirrored at `https://docs.anchorage.com/.well-known/llms-full.txt`. `llms-full.txt` is large and can exceed an AI tool's context window. For focused work, connect the [MCP server](/knowledge-base/build-with-ai/connect-ai-assistant) or copy only the pages you need. ## Which method to use | You need | Use | | :--------------------------------- | :------------------------------------------------------------------- | | One page | The AI menu, or append `.md` to the URL | | A product area, searched on demand | The [MCP server](/knowledge-base/build-with-ai/connect-ai-assistant) | | The full documentation set | `llms-full.txt` | # Build with AI Source: https://docs.anchorage.com/knowledge-base/build-with-ai/overview Use AI assistants and coding agents to learn and integrate with Anchorage Digital faster. You can explore these docs and build your Anchorage Digital integration with AI assistants and coding agents. Ask questions in natural language, pull our documentation straight into your AI tool, and start from ready-made prompts—while keeping the guardrails a custodian requires. ## What you can do Add our docs to Claude, Cursor, VS Code, and more through the hosted MCP server. Copy any page as Markdown, open it in your AI tool, or pull the whole site. Start common integrations from copy-paste prompts. Keep AI agents safe when they touch institutional assets. ## New to AI-assisted development? An **AI coding assistant**—such as Claude, Cursor, GitHub Copilot, or Windsurf—writes and edits code alongside you. The **Model Context Protocol (MCP)** is an open standard that connects these assistants to outside knowledge and tools, like a universal adapter. The assistant is the **client**; a **server** supplies the knowledge or actions. Anchorage Digital hosts an MCP server for these docs, so your assistant can search and cite them directly instead of guessing. ## Recommended path Use Claude Code, Cursor, VS Code with Copilot, Windsurf, or the Claude and ChatGPT apps. Add our MCP server, or pull pages as Markdown, so your assistant answers from the current docs rather than guesswork. See [Connect your AI assistant](/knowledge-base/build-with-ai/connect-ai-assistant). Use a ready-made prompt for your task. See [Ready-made prompts](/knowledge-base/build-with-ai/prompts). Use scoped, read-only keys first, and keep a human in the loop before anything moves assets. See [AI security and guardrails](/knowledge-base/build-with-ai/security). Anchorage Digital moves institutional assets. Before you let an AI agent act on your account, read [AI security and guardrails](/knowledge-base/build-with-ai/security). ## Related * [Set up API access](/knowledge-base/platform/developers/setting-up) — Create permission groups and keys, and sign requests. * [API reference](/knowledge-base/api-reference/introduction) — The full REST API, generated from the OpenAPI spec. # Ready-made prompts Source: https://docs.anchorage.com/knowledge-base/build-with-ai/prompts Start common Anchorage Digital integrations from copy-paste AI prompts. Copy these prompts into your AI assistant to scaffold common integrations. For the best results, connect the [docs MCP server](/knowledge-base/build-with-ai/connect-ai-assistant) first so the assistant works from the current documentation. ## Integration prompts You are helping build an integration with the Anchorage Digital REST API (base URL [https://api.anchorage.com/v2](https://api.anchorage.com/v2)). Using the Anchorage Digital documentation, scaffold a typed API client that authenticates with the `Api-Access-Key` header and signs sensitive requests with an Ed25519 `Api-Signature` and `Api-Timestamp`. Cite the specific documentation pages you rely on, and confirm the current endpoint paths from the docs rather than assuming them. Using the Anchorage Digital documentation, outline and implement the steps to withdraw a digital asset: creating a permission group, generating an API key, adding a trusted destination, and submitting the withdrawal. Call out every step that requires quorum approval, and do not bypass human approval. Verify each endpoint against the docs before writing code. Using the Anchorage Digital documentation, help me subscribe to and verify webhooks for transfer and deposit events. Show how to validate webhook signatures and how to reconcile each event with the read APIs. Using the Anchorage Digital documentation, implement a stablecoin mint, redeem, and bridge with the conversion endpoint, and explain how to track each conversion to completion. Confirm the exact asset-type strings from the docs. ## Keep prompts available in your tool To reuse guidance across a project, save it in your tool's rules or instructions file: | Tool | Where to add project instructions | | :------------- | :---------------------------------------------- | | Claude Code | `CLAUDE.md` or `AGENTS.md` in your project root | | Cursor | Project rules in `.cursor/rules` | | GitHub Copilot | `.github/copilot-instructions.md` | | Windsurf | Workspace rules in `.windsurf/rules` | Exact file names change as tools evolve. Confirm the current path in your AI tool's documentation. ## Write your own Effective prompts share a few habits: point the assistant at our docs or the MCP server, name the exact task, ask it to cite the pages it used, and tell it to verify endpoints and asset types against the docs rather than relying on memory. Always review AI-generated code before running it, and test in the [sandbox](/knowledge-base/platform/developers/sandbox/sandbox-overview) before production. See [AI security and guardrails](/knowledge-base/build-with-ai/security). # AI security and guardrails Source: https://docs.anchorage.com/knowledge-base/build-with-ai/security Keep AI assistants and agents safe when building on Anchorage Digital. AI tools speed up integration, but you're operating on institutional assets. These guardrails keep AI assistants and autonomous agents from causing harm. ## The docs MCP server is read-only Our documentation MCP server only searches and returns docs. It has no access to your keys, account, or funds, and it can't move assets. Connecting it is safe. ## Use least-privilege API keys Give AI-assisted code only the access it needs. Scope keys with [permission groups](/knowledge-base/platform/developers/permission-groups), and start with read-only keys while you explore. Keep internal and external transfer permissions in separate permission groups and keys. ## Keep a human in the loop for asset movement Withdrawals and external transfers require quorum approval by design—never let an agent approve them. Treat every asset-moving action as human-approved, not automated. See [vault policies](/knowledge-base/platform/users/vault-policies) and the [move money overview](/knowledge-base/platform/developers/move-money/overview). ## Protect keys and signing material Never paste API keys, private keys, or signing secrets into a prompt or chat. Keep them out of your AI tool's context and in your secrets manager. Sensitive endpoints require an Ed25519 signature—generate signatures in your own environment. See [Request signing](/knowledge-base/platform/developers/request-signing). ## Treat AI output as untrusted * Review generated code before you run it. * Test against the [sandbox](/knowledge-base/platform/developers/sandbox/sandbox-overview) before production. * Watch for prompt injection: content an agent fetches from the web can carry hidden instructions, so don't act on it blindly. * Verify before you sign or broadcast any transaction. ## Verify against current docs AI models can generate outdated API patterns. Have your assistant cite the documentation pages it used, and confirm endpoint paths and asset types against the current docs or the [MCP server](/knowledge-base/build-with-ai/connect-ai-assistant). # Home Source: https://docs.anchorage.com/knowledge-base/index Run your business on a full-stack platform for digital assets. Anchorage Digital provides the complete infrastructure stack for institutions to participate in the digital asset economy.