Not a developer? The SET API overview covers what it does, why platforms buy it and what it costs.

SET API · FOR DEVELOPERS

SET API technical reference: base URL, keys, routes, currencies and signed webhooks.

A REST API over HTTPS with JSON bodies, called server to server at https://wallet.simpleeasytransactions.com/v1/ with an Authorization: Bearer key. A set_test_ key works only in SET's sandbox and a set_live_ key only in production. Each key is shown once; SET stores only its SHA-256 hash. Errors are JSON with a stable code, and every event is listed at GET /v1/events and, once the platform gives SET a webhook URL, sent there signed with HMAC-SHA256.

See every route →Ask for a sandbox key

KEYS AND REQUESTS

How the SET API is called.

A key is set_live_ or set_test_ followed by 40 random characters. A live key works only in production and a test key only in the sandbox; the wrong one is refused with api_key_wrong_mode.
Each key belongs to one platform and carries scopes: read (GET) and write (create). A platform may hold several keys, so a key can be rotated and the old one revoked.
Sent as Authorization: Bearer set_live_…. Server to server only: a browser request marked cross-site is refused, and there is no CORS.
Errors are { "error": "<stable_code>", "message": "…" }. Every POST takes an Idempotency-Key header: the same key and body run again with Idempotent-Replayed: true; the same key with another body is refused with 422 idempotency_key_reused. Keys are kept 24 hours.

THE FLOW, AND ONE CALL PER WAY

Name the merchant, then one call per way.

01
Name the merchant
POST /v1/customers {externalId, type, name, email} returns Bridge's hosted terms and verification links for the merchant.
02
The merchant passes verification
The merchant completes Bridge's business verification. GET /v1/customers/{id} shows approved and the currencies Bridge approved it for.
03
Say how the merchant wants to be paid, with its details
One POST /v1/payment_setups carries the way and what the merchant gives for it: its wallet for way 1, its bank account for ways 2 and 3.
04
Hand the merchant what its payers pay into
The answer's payTo is that: the virtual account's bank details for ways 1 and 3, or the Cash-Out Address for way 2, with the merchant's details.

Every way needs a merchant Bridge has approved for the currencies it uses.

Way	Calls	Notes
Collect to a wallet	`POST /v1/payment_setups {customer, way: "wallet", currency?, asset, address, beneficiary}`	Creates a virtual account. payTo: its bank details. The platform or merchant supplies the wallet and says whose it is (beneficiary).
Cash out stablecoin	`POST /v1/payment_setups {customer, way: "cash_out", bankAccount, chain?, stablecoin?, rail?, reference?}`	Links the bank and creates the Cash-Out Address. payTo: the address, its chain and minimum, and the bank it pays.
Collect to the bank	`POST /v1/payment_setups {customer, way: "bank", currency?, bankAccount, chain?, stablecoin?, rail?, reference?}`	Links the bank, creates the Cash-Out Address, and opens a virtual account pointed at it. payTo: the account's bank details. currency is what payers send; by default the bank's own.
Convert crypto	`POST /v1/conversion_addresses {customer, chain, currency, destination: {asset, address, beneficiary}}`	Only the pairs listed at GET /v1/conversion_routes are opened.

way is "wallet" (or 1), "cash_out" (or 2) or "bank" (or 3). bankAccount is the merchant's bank details, as for POST /v1/bank_accounts with its currency, or the id of one already linked.
Return address: the platform registers one, once, with POST /v1/return_addresses {evm, solana} (one EVM address serves Base and Ethereum). Bridge returns any payment it cannot pay out there, and every Cash-Out or Conversion Address uses it unless a request names its own returnAddress. A merchant whose payment came back contacts its platform.
chain defaults to base, stablecoin to usdc, and rail to the bank's own (ach, sepa or faster_payments; wire for USD).
Everything is checked before anything is created at Bridge: the fields each way uses, the route for every pair, and Bridge's approval for every currency involved. A refused setup creates nothing.
Safe to send again: each step is content-idempotent, so a repeat answers with the same objects. If Bridge refuses a step, the answer names it (step) and lists what was already created; fix the request and send it again.
The separate routes (POST /v1/bank_accounts, /v1/cash_out_addresses, /v1/virtual_accounts) stay available and run the same code.

ROUTES

Every route. Each takes and returns JSON.

Method and path	What it does
`GET /v1/ping`	Which platform, key prefix, scopes and mode the key belongs to.
`POST /v1/customers`	Onboard a merchant: returns Bridge's hosted terms and verification links; endorsements picks base (USD), sepa (EUR) and faster_payments (GBP).
`GET /v1/customers/{id}`	The merchant's verification status, each currency's endorsement and what Bridge still needs, read from Bridge.
`POST /v1/customers/{id}/endorsements`	Bridge's hosted link to approve an existing merchant for another currency.
`POST /v1/return_addresses`	Register the platform's return address once: where Bridge returns a payment it cannot pay out. GET reads it back.
`POST /v1/payment_setups`	One call per way: how the merchant wants to be paid and its wallet or bank details in; everything that way needs created, and payTo, what the merchant's payers pay into, out.
`POST /v1/bank_accounts`	Add the merchant's own bank account: US (routing and account number), IBAN for euros, or UK sort code and account number for pounds.
`POST /v1/cash_out_addresses`	A permanent Cash-Out Address: USDC or EURC sent to it is paid to that bank by ACH, wire, SEPA or Faster Payments.
`POST /v1/cash_out_addresses/{id}`	Move an address to another of the merchant's bank accounts in the same currency.
`POST /v1/virtual_accounts`	Open a virtual account in USD, EUR or GBP that delivers each payment as stablecoin to a named wallet, or to the merchant's Cash-Out Address.
`POST /v1/virtual_accounts/{id}/deactivate`	Stop an account taking payments; /reactivate opens it again.
`GET /v1/virtual_accounts/{id}/microdeposits`	Verification deposits another app or bank sent to check the account before linking it, read from Bridge.
`GET /v1/deposits`	Payments into the merchant's virtual accounts, with who sent each one.
`POST /v1/deposits/{id}/sender`	Name the payer for the Travel Rule.
`GET /v1/cash_out_payments`	Payments into Cash-Out Addresses and their payout to the bank, with the amount and rate Bridge paid.
`POST /v1/cash_out_payments/{id}/sender`	Name the payer of a Cash-Out payment for the Travel Rule.
`GET /v1/conversion_routes`	Every stablecoin pair a Conversion Address may convert, with Bridge's minimum.
`POST /v1/conversion_addresses`	A permanent address that converts stablecoin, or moves it across chains, to a named wallet.
`GET /v1/conversion_payments`	Payments into Conversion Addresses, with amounts in and out, the rate and on-chain delivery.
`GET /v1/exchange_rates`	Bridge's current rate between USD, EUR, GBP and other currencies, with an estimate for an amount. Not a quote: Bridge offers no rate lock.
`GET /v1/events`	Every event for the platform, in order; also sent as signed webhooks to the platform's URL.
`POST /v1/events/{id}/redeliver`	Send one event to the webhook again.
`POST /v1/webhook_test`	A signed ping event to the platform's webhook.
`GET /v1/webhook_secret`	The platform's webhook URL and signing secret.
`GET /v1/reports/monthly`	A month's deposits and Cash-Out payments per currency: gross, fees and paid out, as exact decimal sums.
`POST /v1/sandbox/deposits`	Sandbox only: a simulated deposit, so the whole flow can be tested before any money moves.
`POST /v1/sandbox/cash_out_payments`	Sandbox only: a simulated payment into a Cash-Out Address and its payout.

Lists take limit and filters such as customer and createdSince. Single objects are read at /{id} on each collection. Writes need the write scope.

CURRENCIES AND ASSETS

Dollars, euros, pounds and stablecoins.

Bridge approves each merchant per currency: base (USD), sepa (EUR), faster_payments (GBP). Each bank account, virtual account and Cash-Out Address checks its own currency and answers 409 endorsement_required otherwise.
US dollar virtual accounts carry the merchant's name. For euro and pound accounts, payers must use the beneficiary name Bridge returns in depositInstructions: Bridge's own entity, unless Bridge grants payment on behalf of the merchant.
USD accounts deliver USDC on Base, Ethereum, Polygon, Arbitrum, Optimism, Avalanche or Solana, USDT on Ethereum or Solana, or PYUSD. EUR accounts deliver USDC on those seven chains or EURC on Base, Ethereum or Solana. GBP accounts deliver USDC where Bridge supports the pair, which Bridge confirms when the account is opened.
Cash-Out Addresses accept USDC on Base, Ethereum or Solana and EURC on Base, Ethereum or Solana, and pay out by ACH or wire (USD), SEPA (EUR) or Faster Payments (GBP), on the pairs Bridge's Route Explorer lists. Each answer shows the payout currency and minimum.
depositInstructions (routing and account numbers, IBAN and BIC, or sort code and account number, with the beneficiary name and rails) are read from Bridge on each answer and never stored.
In the EEA, Bridge supports only USDC and EURC.

TRAVEL RULE

Beneficiaries and senders.

Every Bridge movement carries Travel Rule data, and SET refuses a request without it before it reaches Bridge.
Collect to a wallet and Convert crypto name the destination wallet's owner: { "type": "customer", "walletType": "hosted" | "self_custodied", "ownershipVerifiedAt": "<ISO time>" } for the merchant's own wallet (held by the platform for the merchant, or by the merchant), or { "type": "platform" } for the platform's own wallet, named with the legal details SET holds for the platform.
A Cash-Out Address, and a virtual account that settles to one, name the merchant as beneficiary: the bank account is the merchant's own.
Who paid: for each deposit and each Cash-Out or Conversion payment, the platform sends { "type": "business" | "individual", "name", "address": { "country": "USA", … } } or { "type": "customer" } when the merchant paid itself. country (ISO 3166-1 alpha-3) is required; send what else is known. A refused submission can be corrected and sent again.

STATES AND FEES

How a payment moves, and what it shows.

A deposit's state follows Bridge: funds_scheduled (ACH in transit), funds_received, in_review, payment_submitted, payment_processed, and the refund states. delivered is true only once SET has read the transfer on chain at the destination.
A Cash-Out payment's state follows Bridge's drain: funds_received, payment_submitted, payment_processed (Bridge paid the bank: paidToBank), and returned, refunded and the other end states. sourceDeposit names the deposit it carried, for Collect to the bank.
States only move forward. Fees are shown as Bridge reports them: developerFee (SET's), and on deposits exchangeFee and gasFee.
A verification deposit under $1 (ACH microdeposit) never becomes a deposit and raises no event; read them at GET /v1/virtual_accounts/{id}/microdeposits.

EVENTS AND WEBHOOKS

Every change, in order, signed.

Event types include customer.updated, bank_account.created, cash_out_address.created and .updated, virtual_account.created, .deactivated and .activated, deposit.<state> and deposit.delivered, cash_out_payment.<state>, conversion_address.created and conversion_payment.<state>.
Each event is POSTed to the platform's webhook URL with SET-Signature: t=<unix time>,v1=<hex HMAC-SHA256 of "<t>.<raw body>" with the platform's secret>.
A 2xx answer is delivered; anything else is retried from 1 minute, doubling, at most a day apart, 15 tries. Delivery is at least once: deduplicate on the event id.

SANDBOX

Test the whole flow before money moves.

A set_test_ key runs against SET's staging Worker, which runs the production code with Bridge's sandbox. Bridge, word for word: “there is no real money movement in Sandbox” and “no webhook events will be sent”. So SET simulates what Bridge's sandbox cannot: POST /v1/sandbox/customers/{id}/approve, POST /v1/sandbox/deposits, POST /v1/sandbox/cash_out_payments and POST /v1/sandbox/conversion_payments, each with an /advance step, and signed webhooks reach your server. Everything simulated is labelled “Sandbox:” and no money moves.

RULES AND LIMITS

Every rule and limit, plainly.

Payers: Bridge allows third-party payments in most states except New York and Texas, under its own rules.
Rails in: ACH, wire and FedNow for dollars, SEPA for euros, Faster Payments for pounds. RTP is not offered; FedNow is the instant dollar rail.
Payouts to the bank go only to the merchant's own account. Payouts to third-party bank accounts are not built.
USDT on Tron is not supported. MXN, BRL and COP are not offered.
Exchange rates are Bridge's current rate and cannot be locked: Bridge offers no quote.
Bridge's own fees on each payment (exchange and network fees) are separate from SET's and are shown per payment through the API.
Server to server only: SET refuses browser calls marked cross-site, and there is no CORS.

WHAT BRIDGE SAYS

The rules it runs on, in Bridge's own words.

“KYC Links support individual and business customers from all over the world (US + international)”

Each merchant completes Bridge's own business verification on Bridge's hosted page.

Bridge KYC Links guide

“Third party payments in most states except for New York and Texas”

Bridge's rail-specific rules for who may pay a merchant's account.

Bridge rail-specific requirements

“a permanent payment route which ties a blockchain address to either a fiat or blockchain address”

A merchant's Cash-Out Address and a Conversion Address are Bridge liquidation addresses.

Bridge liquidation address guide

“the customer for POBO accounts, otherwise the Bridge legal entity. Senders should match this name”

Bridge, on the beneficiary name of euro and pound virtual accounts.

Bridge create a virtual account

QUESTIONS

What developers ask first.

How does a platform call the SET API?

Is the SET API the same as ServiceNow's Import Set API or Windows API sets?

No. The SET API is the payments API of Simple Easy Transactions (SET), a Missouri company. It is not ServiceNow's Import Set API, a REST API that loads records into ServiceNow staging tables and transforms them; not Microsoft's Windows API sets, which organize Win32 APIs into functional groups; and not an API for the Secure Electronic Transaction (SET) card protocol of the 1990s.

Ask for a sandbox key →See the rate card

FINE PRINT

Who provides what, and our sources.

Conversion and payouts are provided by Bridge, not by SET. “Services for U.S. residents are provided, where applicable, by Bridge Building Inc. (NMLS ID 2450917).” (Bridge website footer)

The SET API is the payments API of Simple Easy Transactions (SET), a Missouri company. It is not ServiceNow's Import Set API, a REST API that loads records into ServiceNow staging tables and transforms them; not Microsoft's Windows API sets, which organize Win32 APIs into functional groups; and not an API for the Secure Electronic Transaction (SET) card protocol of the 1990s.

Every provider fact on this page was opened 2026-11-05: