What's new in the SET API: 9–10 November 2026

SET API (Platforms) and SET Merchant API · Live in staging and production since 2026-11-10

Four releases went live overnight on 9–10 November 2026. Every change adds to the API: no field was renamed or removed, and an integration that ignores the new fields works as it did before. This page lists the changes. Each edge case has its own guide.

At a glance

Change	Calls	Guide
Fair webhook delivery, and pausing an endpoint that always fails	event `webhook_endpoint.disabled`; `status` and `disabledAt` on endpoints	Webhook delivery when an endpoint fails
Several webhook endpoints	`/v1/webhook_endpoints` (list, add, change, delete, rotate)	List all webhook endpoints
Pin a key to your servers	`allowedCidrs` on `POST /v1/api_keys`; `POST /v1/api_keys/{id}/allowed_cidrs`; `403 ip_not_allowed`	Pinning a key to your servers
One key for both APIs	the `direct_deposit` scope	One key for both APIs
Exchange-rate drift guard	`maxRateDriftBps` on `POST /v1/payouts`	Exchange-rate drift on payouts
Data-subject requests	`POST /v1/data_requests`, `GET /v1/data_requests`; event `data_request.received`	Data-subject requests
Paying people in minutes	event `payable_payment.in_wallet` as proof of payment	Payout timing
Splitting a buyer's payment	settlement to a wallet, then one payout batch	Marketplace splits
Which API an event belongs to	`api` on every event: `set_api`, `direct_deposit` or `account`	One key for both APIs

Reliability

Webhook delivery is fair between businesses. One business's slow or failing endpoint no longer delays anyone else's events. Each endpoint's events still arrive in order.
An endpoint that always fails is paused. That means every delivery failed for at least 24 hours, and at least 20 times in a row. You get one webhook_endpoint.disabled event, every event stays listed at GET /v1/events, and setting the URL again resumes it. Events missed while it was paused are then sent.

Security

IP allowlists. Pin any key to up to 20 IPv4 or IPv6 addresses or CIDR ranges. A request from anywhere else is 403 ip_not_allowed. A key cannot shut itself out (409 would_lock_out). Each change raises api_key.allowed_cidrs_changed.
Data-subject requests. Record a person's request to see or erase what is held about them. The answer tells you what SET keeps, and what its provider keeps.
Screening. SET now asks a screening step when a Direct Deposit sender wallet is registered and when a payout is attributed. Until SET chooses a screening provider, every answer is not_screened and nothing is held.

Payouts

maxRateDriftBps on bank payouts in EUR, GBP, MXN, BRL or COP. If the rate moves further than you allow between creating the payout and sending it, the payout is held for review instead of being sent. No rate is locked; this is the nearest thing SET can offer.
Wallet-first timing. A Payable Email payment is the payee's USDC as soon as payable_payment.in_wallet arrives. The bank leg follows when the payee claims.
Marketplace splits need no new call: settle the buyer's payment to the merchant's wallet, then pay each share with one POST /v1/payout_batches.

Keys

POST /v1/api_keys takes the direct_deposit scope beside read, write and approve. A key with it also opens the SET Direct Deposit API (/api/partner/*) as your business, so a platform that uses both APIs needs one key.
Keys show allowedCidrs.

Events

Every event carries api: set_api, direct_deposit or account. A platform that also uses Direct Deposit gets both kinds in one list, and payout.* means a different object on each. Events recorded earlier carry it too.

Not in this release

A locked exchange rate: SET's provider offers none.
Batch payout items carry no rate-drift guard. Use single payouts with maxRateDriftBps where it matters.
An operator screen for data-subject requests. SET's operator answers each one; the request and its event are your record.
Published client libraries. Build a typed client from the OpenAPI document; see Get a sandbox key.