Skip to main content
POST
Archive a beneficiary
The field above is what you encrypt, not what goes on the wire. The body is always { "data": "<aes-256-gcm ciphertext>" } — see Authentication.
POST, not DELETE. The consumer API carries an AES-encrypted request body, which a DELETE cannot carry reliably — so the action is in the path and the id is in the encrypted payload.

This archives, it does not erase

The beneficiary’s status becomes archived. It can no longer be selected for a new payout, and payouts that already used it keep their own snapshot of the recipient — which is what preserves the audit trail on money that has already moved. There is no un-archive endpoint. Save the recipient again if you need it back.

Example request

The snippets assume you have already encrypted the body and signed the request — see the Quickstart for the full helper in Node and Python.
See Beneficiaries for how saving and reusing recipients fits together, and Errors for the envelope shape shared by every endpoint.

Authorizations

x-api-key
string
header
required

Identifies your account. Issued from Developer Tools in the dashboard.

Authorization
string
header
required

Short-lived token from /api/v1/user/login, bound to your account and mode. Expires in 900 seconds.

Headers

x-timestamp
integer<int64>
required

Unix epoch in seconds — not milliseconds. Must be within ±5 minutes of our clock, which is what makes a captured request unusable later. Keep your client's clock NTP-synced.

Example:

1748023400

x-signature
string
required

HMAC-SHA256 over the signing string, hex encoded. The timestamp is part of what is signed, so a replayed body cannot be re-dated. See https://docs.pontisglobe.com/authentication for how it is built.

Example:

"2f8a9b4c1d7e0a3f6b8c2d5e9f1a4b7c0d3e6f9a2b5c8d1e4f7a0b3c6d9e2f5a"

Body

application/json
beneficiary_id
string<uuid>
required

Response

Archived.

ok
enum<boolean>
Available options:
true
data
object