Webhooks

The widget notifies your backend of two things: a buy asks for your approval before it executes, and every operation — buy, sell, deposit or withdrawal — reports its result once it’s settled. Both are POST requests to the webhook URL configured on your account. Signatures go both ways, with the same scheme — Ed25519 over the raw body, sent as ed25519=<hex> — and a key pair on each side:

Direction	Header	Signed with	Verified with
Ripio → you (every request)	`X-Ripio-Signature-Ed25519`	Ripio’s private key	Ripio’s public key, which Ripio gives you at onboarding
You → Ripio (every response)	`X-Partner-Signature-Ed25519`	Your private key	Your public key, which you give Ripio at onboarding

Each side signs with a key only it holds, so a valid signature proves who produced the message — something a shared secret can’t do, since either side could have computed it. No secret is ever shared, in either direction.

This is a separate contract from the Crypto as a Service webhooks used by the core API — the widget’s events use their own envelope and their own signatures, documented below.

Envelope

Every message shares the same envelope:

{
  "schema_version": "2026-09-01",
  "message_type": "transaction_approval_request",
  "event_id": "0f1c9a3e-5b7d-4c21-9f0a-6d2e8b41c7a5",
  "timestamp": "2026-09-28T14:03:11.482913Z",
  "message": { "...": "..." }
}

Key	Type	Description
`schema_version`	string	Version of this contract. Currently `2026-09-01`.
`message_type`	string	`transaction_approval_request` or `transaction_result`.
`event_id`	string	Unique identifier of this delivery. A retry of the same `transaction_result` carries the same `event_id` — key your deduplication on it.
`timestamp`	string	RFC 3339 datetime, UTC (`Z` suffix), of when the message was issued.
`message`	object	The event’s own payload, described below.

Reject any message whose timestamp is more than 5 minutes old. The timestamp is part of the signed body, so it can’t be rewritten without breaking the signature — checking it is what stops a captured request from being replayed later.

Verifying the signature

Every request carries an X-Ripio-Signature-Ed25519 header: an Ed25519 signature of the raw request body, made with Ripio’s private key.

X-Ripio-Signature-Ed25519: ed25519=<hex-encoded Ed25519 signature of the body>

You verify it with Ripio’s public key, which your Ripio contact hands you during onboarding (a PEM PUBLIC KEY). There’s one key per environment: the sandbox key doesn’t verify production requests, and vice versa. The signature covers the exact bytes of the body as received (compact JSON, no whitespace). Verify it over the raw body before parsing it — re-serializing the parsed JSON won’t necessarily give you back the same bytes. Reject the request if the header is missing, doesn’t start with ed25519=, or doesn’t verify. Python (cryptography)

from cryptography.exceptions import InvalidSignature
from cryptography.hazmat.primitives.serialization import load_pem_public_key

with open("ripio_webhook_public.pem", "rb") as f:
    ripio_public_key = load_pem_public_key(f.read())

def verify_ripio_signature(raw_body: bytes, signature_header: str | None) -> bool:
    if not signature_header or not signature_header.startswith("ed25519="):
        return False
    try:
        signature = bytes.fromhex(signature_header.removeprefix("ed25519="))
        ripio_public_key.verify(signature, raw_body)
    except (InvalidSignature, ValueError):
        return False
    return True

Node.js

const crypto = require("crypto");
const fs = require("fs");

const ripioPublicKey = crypto.createPublicKey(
  fs.readFileSync("ripio_webhook_public.pem")
);

function verifyRipioSignature(rawBody, signatureHeader) {
  if (!signatureHeader || !signatureHeader.startsWith("ed25519=")) return false;
  const signature = Buffer.from(signatureHeader.slice("ed25519=".length), "hex");
  if (signature.length !== 64) return false;
  return crypto.verify(null, rawBody, ripioPublicKey, signature);
}

Test against the reference vector This throwaway test key is not valid for any environment. The body below, verified with it, must accept exactly this header — and reject it after any change to a single byte of the body:

Ripio public key (test only):
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAbQA4L242MtJl0Nzqws6LY9WJrSgocnqXBb2CkkGlvD4=
-----END PUBLIC KEY-----

Body (exact bytes):
{"schema_version":"2026-09-01","message_type":"transaction_approval_request","event_id":"11111111-1111-1111-1111-111111111111","timestamp":"2026-09-21T14:31:02.118473Z","message":{"id":"22222222-2222-2222-2222-222222222222","quote_id":"33333333-3333-3333-3333-333333333333","external_ref":"end-user-1","op_type":"BUY","amount":"15000.00","amount_currency":"fiat","currency":"ARS"}}

Header:
X-Ripio-Signature-Ed25519: ed25519=5d107af01845c9c87719db76cb8b5773e8757d31f4551c5544e53ff5def44d1c7e00ff5af1a7b1ec48e5c525fe719deea2f4bc6102b01bf6ce32cd84097d9704

Signing your response

Your answer to both messages — the decision on a transaction_approval_request and the acknowledgement of a transaction_result — is signed with an Ed25519 key pair that you generate and hold. You keep the private key; you hand the public key to Ripio during onboarding. Since only you hold the private key, a valid signature proves the answer came from your systems. Each response body includes the request’s event_id. That’s what binds each signature to a single delivery: without it, every {"approved": true} would be the same bytes and the same signature, reusable for any other purchase. 1. Generate the key pair

openssl genpkey -algorithm ed25519 -out partner_response_private.pem
openssl pkey -in partner_response_private.pem -pubout -out partner_response_public.pem

This needs OpenSSL 1.1.1 or later — the LibreSSL build that ships with macOS doesn’t support Ed25519; use Homebrew’s openssl or generate the pair with your language’s crypto library. Send partner_response_public.pem (a PEM PUBLIC KEY) to your Ripio contact. Keep the private key in your secrets manager — never share it. Your public key is required before Ripio can send webhooks to your account. 2. Sign the exact bytes you send Serialize the response body once, sign those bytes, and send those same bytes. If your framework re-serializes the object after you sign it (different key order, added whitespace), the signature won’t match. Python (cryptography)

import json
from cryptography.hazmat.primitives.serialization import load_pem_private_key

with open("partner_response_private.pem", "rb") as f:
    private_key = load_pem_private_key(f.read(), password=None)

def signed_response(payload: dict) -> tuple[bytes, dict]:
    body = json.dumps(payload, separators=(",", ":")).encode("utf-8")
    signature = private_key.sign(body).hex()
    headers = {
        "Content-Type": "application/json",
        "X-Partner-Signature-Ed25519": f"ed25519={signature}",
    }
    return body, headers  # send `body` as the raw response content

# Approval:        signed_response({"approved": True, "event_id": event_id})
# Acknowledgement: signed_response({"received": True, "event_id": event_id})

Node.js

const crypto = require("crypto");
const fs = require("fs");

const privateKey = crypto.createPrivateKey(
  fs.readFileSync("partner_response_private.pem")
);

function signedResponse(payload) {
  const body = Buffer.from(JSON.stringify(payload));
  const signature = crypto.sign(null, body, privateKey).toString("hex");
  return {
    body, // send these exact bytes, e.g. res.end(body)
    headers: {
      "Content-Type": "application/json",
      "X-Partner-Signature-Ed25519": `ed25519=${signature}`,
    },
  };
}

// Approval:        signedResponse({ approved: true, event_id: eventId })
// Acknowledgement: signedResponse({ received: true, event_id: eventId })

3. Test against the reference vectors Use this throwaway test key pair — it is not valid for any account — to confirm your implementation signs the way Ripio verifies. Signing each body below with the private key must produce exactly that signature (Ed25519 is deterministic):

Private key (test only):
-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEIM5+nJhBYxpo/mnya0QQZwhyjWhkobYDCvkz2RGHbS7l
-----END PRIVATE KEY-----

Public key (test only):
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAA+fXvBisuIQDioOnAfEh5iFUgtpug7fmfTTSW2DOcik=
-----END PUBLIC KEY-----

Approval body (exact bytes):
{"approved":true,"event_id":"11111111-1111-1111-1111-111111111111"}

Expected header:
X-Partner-Signature-Ed25519: ed25519=6add92a4d8c848718f440b3addcbb4edfbebf2cd4d3f1f70c0302351288c02057747f55568bfbd47b650170e666e6adbe3cf1ec4f145fde0c9bb7a145407ab09

Acknowledgement body (exact bytes):
{"received":true,"event_id":"11111111-1111-1111-1111-111111111111"}

Expected header:
X-Partner-Signature-Ed25519: ed25519=476ea624fccaad2b810b96f634e53d1bb46ce47934ea8dcb1ea62946581e3653ebeafe0a7dae74f872358d73c2cd29da95706f3ce40d1e1cf62f98f75a87f70e

`transaction_approval_request`

Sent before a buy executes, only if your account has transaction approval enabled. Ripio makes a single attempt with a 5-second timeout and does not follow redirects. If your endpoint doesn’t respond in time, or responds with anything other than a valid, signed approval, the operation does not execute — this request is fail-closed.

{
  "schema_version": "2026-09-01",
  "message_type": "transaction_approval_request",
  "event_id": "0f1c9a3e-5b7d-4c21-9f0a-6d2e8b41c7a5",
  "timestamp": "2026-09-28T14:03:11.482913Z",
  "message": {
    "id": "df9d41d8-ac80-5125-9738-ce1fcb8dc523",
    "quote_id": "cf6c57ea-03a1-41dc-99e8-b91cc1b7333e",
    "external_ref": "00010203-0405-0607-0809-0a0b0c0d0e0f",
    "op_type": "BUY",
    "amount": "1500",
    "amount_currency": "fiat",
    "currency": "ARS"
  }
}

Key	Type	Description
`id`	string	Identifier of the operation. Deterministic: a retry of the same quote carries the same `id`, and the `transaction_result` that follows carries it too — use it to correlate the two.
`quote_id`	string	The quote the user accepted.
`external_ref`	string	The user’s identifier, as you provided it on `POST /auth`.
`op_type`	string	Always `BUY` — a sell doesn’t need approval, since Ripio holds the custody of the crypto being sold.
`amount`	string	The amount the user entered, in the unit given by `amount_currency`.
`amount_currency`	string	`fiat` or `crypto` — which side of the operation `amount` is expressed in. The user can type the amount in either.
`currency`	string	Your account’s fiat currency (ISO 4217, e.g. `ARS`).

Don’t assume amount is fiat: when amount_currency is crypto, amount: "0.01" means 0.01 of the crypto being bought, not one cent.

Responding

To approve, respond HTTP 200 with a JSON body that includes the event_id of the request, and sign that body (see Signing your response):

HTTP/1.1 200 OK
Content-Type: application/json
X-Partner-Signature-Ed25519: ed25519=<hex-encoded Ed25519 signature of the body>

{"approved":true,"event_id":"0f1c9a3e-5b7d-4c21-9f0a-6d2e8b41c7a5"}

An operation is approved only when all of these hold:

The status is 200.
The body is a JSON object with "approved": true — the boolean. "true", 1 or "yes" are treated as a denial.
The body’s event_id equals the event_id of the request.
X-Partner-Signature-Ed25519 carries a valid signature of the body under the public key you registered with Ripio.

A status other than 200, or a validly signed response whose approved isn’t true, denies the operation, and the user is told it wasn’t approved.

A missing or invalid signature, or an event_id that doesn’t match the request, is not read as a denial: the operation doesn’t execute, and the widget gets error 50007 (“could not be validated right now”). That keeps “you said no” distinguishable from “someone answered who couldn’t prove to be you” — if you see 50007, check your signing key and that you echo the right event_id.

`transaction_result`

Tells you how an operation ended, so you can update your own record of the user’s balance and release anything you reserved when approving it. It is sent to every account with a webhook URL, whether or not transaction approval is enabled, for:

Buys and sells executed from the widget — described in this section.
Withdrawals the user sends from the widget, and deposits credited to your users’ deposit addresses — same envelope and statuses, with an on-chain payload. See Deposits and withdrawals.

Each operation gets at most one result, identified by message.id, with one of two statuses:

COMPLETED — the trade executed, or the transfer was confirmed.
CANCELLED — the operation did not execute and never will. It is final: once an operation is cancelled, Ripio refuses any further attempt on it, so a CANCELLED is never followed by a COMPLETED for the same id. If the user tries again, the widget asks for a new quote, which starts a new operation with a new id.

It is delivered at least once: anything other than a signed acknowledgement (see Acknowledging), or no response, is retried up to 3 times with exponential backoff (up to 60 seconds between attempts). A retry carries the same event_id — use it to discard duplicates, and acknowledge the duplicate too. Completed:

{
  "schema_version": "2026-09-01",
  "message_type": "transaction_result",
  "event_id": "57b526a5-092b-4d61-a394-b80e4bad5fcf",
  "timestamp": "2026-09-28T14:03:13.107455Z",
  "message": {
    "id": "df9d41d8-ac80-5125-9738-ce1fcb8dc523",
    "quote_id": "cf6c57ea-03a1-41dc-99e8-b91cc1b7333e",
    "external_ref": "00010203-0405-0607-0809-0a0b0c0d0e0f",
    "op_type": "BUY",
    "amount": "1500",
    "amount_currency": "fiat",
    "currency": "ARS",
    "fiat_amount": "1500.00",
    "asset": "BTC",
    "status": "COMPLETED",
    "txn_id": "8a3f2c1e-4b5d-4e6f-9a0b-1c2d3e4f5a6b",
    "operation_number": "RP-482913"
  }
}

Cancelled:

{
  "schema_version": "2026-09-01",
  "message_type": "transaction_result",
  "event_id": "b3e1f0a2-7c4d-4e8f-a1b2-c3d4e5f60718",
  "timestamp": "2026-09-28T14:03:12.640118Z",
  "message": {
    "id": "df9d41d8-ac80-5125-9738-ce1fcb8dc523",
    "quote_id": "cf6c57ea-03a1-41dc-99e8-b91cc1b7333e",
    "external_ref": "00010203-0405-0607-0809-0a0b0c0d0e0f",
    "op_type": "BUY",
    "amount": "1500",
    "amount_currency": "fiat",
    "currency": "ARS",
    "fiat_amount": null,
    "asset": null,
    "status": "CANCELLED",
    "txn_id": null,
    "operation_number": null,
    "cancel_reason": "insufficient_balance"
  }
}

Key	Type	Description
`id`	string	The same value sent in `transaction_approval_request` for a buy — use it to correlate the two.
`quote_id`, `external_ref`, `op_type`, `amount`, `amount_currency`, `currency`		Same meaning and values as in `transaction_approval_request`, so the two messages compare field by field. `op_type` is `BUY` or `SELL`.
`fiat_amount`	string \| null	The amount of `currency` the trade actually moved on the user’s balance: debited on a `BUY`, credited on a `SELL`, with the fee already applied. `null` when cancelled.
`asset`	string \| null	The crypto asset traded (e.g. `BTC`). `null` when cancelled.
`status`	string	`COMPLETED` or `CANCELLED`.
`txn_id`	string \| null	The resulting transaction’s identifier. `null` when cancelled.
`operation_number`	string \| null	The operation number shown to the user on the widget’s success screen (`RP-` followed by six digits). `null` when cancelled.
`cancel_reason`	string (cancelled only)	Why the operation was cancelled — see below.

To update your record of the user’s fiat balance, use fiat_amount, not amount. amount is what the user typed: when amount_currency is crypto, it is a quantity of asset, and it never reflects the fee.

Acknowledging

To confirm you received a result, respond with any 2xx status and a JSON body that includes the event_id of the request, signed like your approval responses (see Signing your response):

HTTP/1.1 200 OK
Content-Type: application/json
X-Partner-Signature-Ed25519: ed25519=<hex-encoded Ed25519 signature of the body>

{"received":true,"event_id":"57b526a5-092b-4d61-a394-b80e4bad5fcf"}

A result counts as delivered only when the status is 2xx, the body carries "received": true and the request’s event_id, and X-Partner-Signature-Ed25519 verifies under your public key. A bare 2xx — unsigned, wrongly signed, or for another event_id — is not an acknowledgement: Ripio retries it like a missing response, and records the delivery as failed once the retries run out. That’s what lets either side prove later that a result was or wasn’t received.

Cancel reasons

An operation is cancelled only when it is certain that it did not execute: either Ripio rejected it, or the core was never called because your approval couldn’t be used.

`cancel_reason`	Meaning
`transaction_approval_unavailable`	Your endpoint didn’t answer the approval request in time, or answered with something that isn’t a JSON object. You may have approved it — release whatever you reserved.
`transaction_approval_signature_invalid`	Your approval response had a missing or invalid signature, or an `event_id` that didn’t match. See Signing your response.
`quote_expired`	The quote expired before the operation executed.
`quote_not_found`	The quote doesn’t exist for your account.
`quote_price_unavailable`	There was no price available to execute the quote.
`insufficient_balance`	The user didn’t have enough balance.
`amount_below_minimum`	The amount is below the minimum per operation.
`amount_above_maximum`	The amount is above the maximum per operation.
`quote_amount_rejected`	The amount was rejected as invalid.
`periodic_amount_limit_reached`	The user reached the amount limit for the current period.
`periodic_frequency_limit_reached`	The user reached the number of operations allowed for the current period.
`end_user_not_operable`	The user is not allowed to operate.
`quote_execution_irrecoverable`	The operation could not be executed and can’t be retried on the same quote.

Treat any other value as a cancellation too: new reasons may be added.

When you don’t receive a result

You denied the approval. No result is sent — you already know the outcome, and you reserved nothing.
The outcome is uncertain. If the execution fails in a way that doesn’t say whether the trade happened (a timeout or an internal error), no result is sent for now. The user can retry the same operation from the widget, and if the trade did go through, you receive its COMPLETED then.
A deposit or withdrawal isn’t final yet, or never got created. See When it’s sent.

The same id can receive more than one transaction_approval_request: when the user retries after an uncertain failure, the retry asks for your approval again, with a new event_id. Answer each one on its own merits — only the transaction_result closes the operation.

For a buy, persisting id is generally enough to reference the operation later; operation_number is what the user sees, so it’s the easiest reference if they reach out to you about it.

Deposits and withdrawals

Deposits and withdrawals report their result through the same transaction_result: same envelope, same COMPLETED / CANCELLED statuses, same delivery and the same acknowledgement. What changes is the message — there’s no quote and no fiat side, but the on-chain details of the transfer, and the status Ripio’s core reports for it.

Deposit and withdrawal results are enabled per account. Ask your Ripio contact to turn them on.

When it’s sent

A result is sent once the transfer is final — never while it’s still in progress:

Deposit — when it’s credited: the network confirmed it and Ripio completed its checks. Sent for every deposit to any of your users’ deposit addresses, whether or not they had the widget open when the funds arrived. A deposit that was detected but isn’t confirmed yet doesn’t produce a result.
Withdrawal — when it’s confirmed on-chain (COMPLETED) or fails after being submitted (CANCELLED), only for withdrawals sent from the widget. The “Transfer started” screen the user sees is not the result: at that point the withdrawal is still pending, and it can take some time for the network to confirm it.

A withdrawal Ripio rejects before creating it — insufficient balance, an invalid address or memo, an expired network fee, an amount outside the limits — doesn’t produce a result either: the user is shown the error in the widget, and nothing was debited. Deposit completed:

{
  "schema_version": "2026-09-01",
  "message_type": "transaction_result",
  "event_id": "114cdf12-02dc-4983-aaff-5c1b4e7d9a20",
  "timestamp": "2026-10-30T19:40:02.231645Z",
  "message": {
    "id": "9875ac81-3649-43dd-93d7-7a49c7b16210",
    "external_ref": "00010203-0405-0607-0809-0a0b0c0d0e0f",
    "op_type": "DEPOSIT",
    "amount": "1.000000000000000000",
    "asset": "ETH",
    "network": "ethereum_sepolia",
    "address": "0xcF8c3807a2921E3b4b3D1e065b88EB79c87205d8",
    "memo": null,
    "hash": "0xba69a953fdcb3ec8ed40bb8d40a35bb2b66a637186c6326ddc91b83fda43a8a0",
    "status": "COMPLETED",
    "core_status": "COMPLETED",
    "is_blocked": false,
    "blocked_reason": null,
    "txn_id": "9875ac81-3649-43dd-93d7-7a49c7b16210",
    "operation_number": "RP-557392"
  }
}

Withdrawal cancelled after it was submitted:

{
  "schema_version": "2026-09-01",
  "message_type": "transaction_result",
  "event_id": "c2a7e4f1-8b3d-4f60-9e15-7d0c6b2a9f84",
  "timestamp": "2026-10-30T20:12:47.905311Z",
  "message": {
    "id": "cc7b2c54-7bad-5974-a95a-fcfa4e6be558",
    "external_ref": "00010203-0405-0607-0809-0a0b0c0d0e0f",
    "op_type": "WITHDRAWAL",
    "amount": "3.00000000",
    "asset": "ETH",
    "network": "ethereum_sepolia",
    "address": "0x201c6A26477F7a902e8C45C43c99ee2735C44982",
    "memo": null,
    "hash": null,
    "status": "CANCELLED",
    "core_status": "ERROR",
    "is_blocked": false,
    "blocked_reason": null,
    "txn_id": "4ec56891-8b6d-45ee-bb18-86eae8eae466",
    "operation_number": "RP-106854",
    "cancel_reason": "core_error"
  }
}

Key	Type	Description
`id`	string	Identifier of the operation. For a withdrawal, the identifier the widget created it with: stable across the user’s retries of the same transfer. For a deposit, the same value as `txn_id`.
`external_ref`	string	The user’s identifier, as you provided it on `POST /auth`. For a deposit, the user who owns the deposit address.
`op_type`	string	`DEPOSIT` or `WITHDRAWAL`.
`amount`	string	Quantity of `asset`. For a withdrawal, what the recipient gets — the network fee is debited on top and isn’t included. For a deposit, what was credited.
`asset`	string	The crypto asset transferred (e.g. `ETH`).
`network`	string	The network the transfer used. Compare it case-insensitively.
`address`	string	For a deposit, the user’s deposit address. For a withdrawal, the destination address.
`memo`	string \| null	The memo (or tag) of the transfer, on networks that use one. `null` otherwise.
`hash`	string \| null	The on-chain transaction hash. It can be `null` on a cancelled withdrawal that never reached the network.
`status`	string	`COMPLETED` or `CANCELLED`.
`core_status`	string	The status Ripio’s core reports for the transfer, unchanged: `COMPLETED`, `CANCELLED`, `ERROR`, `BLOCKED_LIMIT_EXCEEDED` or `BLOCKED_REGULATORY`. Treat any other value as a failure: new statuses may be added.
`is_blocked`	boolean	Whether Ripio is holding the funds. See the warning below.
`blocked_reason`	string \| null	Why the funds are held, when `is_blocked` is `true`. `null` otherwise.
`txn_id`	string	The transfer’s transaction identifier in Ripio — the same one the user sees in their Activity.
`operation_number`	string \| null	The operation number shown to the user in the transfer’s detail (`RP-` followed by six digits).
`cancel_reason`	string (cancelled only)	Why the transfer didn’t go through — see below.

A deposit blocked by compliance arrives as status: "COMPLETED" and core_status: "COMPLETED" with is_blocked: true: the funds reached Ripio, but they are held and aren’t available in the user’s balance. Don’t credit them on your side while is_blocked is true. If the funds are released later, no new result is sent.

amount is a quantity of asset, never fiat: a deposit or withdrawal doesn’t convert anything. Use it, together with asset, to update your record of the user’s crypto balance.

On-chain cancel reasons

A cancelled deposit or withdrawal carries a cancel_reason built from the core’s status: core_ followed by core_status in lowercase.

`cancel_reason`	Meaning
`core_cancelled`	Ripio cancelled the transfer.
`core_error`	The transfer failed after it was submitted.
`core_blocked_limit_exceeded`	The transfer was blocked because it exceeded one of the user’s limits.
`core_blocked_regulatory`	The transfer was blocked for regulatory reasons.

Treat any other core_ value as a cancellation too.

If the user retries a withdrawal that was cancelled after it was submitted, the widget doesn’t send it again — it shows the same transfer with its final status. To send the funds again, the user starts a new transfer, which gets a new id.

Configuring your endpoint

Webhooks are set up during onboarding, as an exchange of public keys in both directions — reach out to your Ripio contact to configure or change anything:

You give Ripio your webhook URL and your Ed25519 public key (see Signing your response).
Ripio gives you its Ed25519 public key for the environment, to verify X-Ripio-Signature-Ed25519 (see Verifying the signature).

Key considerations for your endpoint:

HTTPS. Your endpoint URL must use HTTPS and resolve to a public address. Redirects (3xx) are not followed — point the URL at the final endpoint.
Deposits and withdrawals. Their results are enabled per account — ask your Ripio contact to turn them on (see Deposits and withdrawals).
Respond quickly. For transaction_approval_request, respond within 5 seconds — the operation is fail-closed, so a slow response means the operation doesn’t go through.
Verify every request. Check X-Ripio-Signature-Ed25519 over the raw body and the timestamp before acting on a message.
Sign every response. Your answer to both transaction_approval_request and transaction_result must carry X-Partner-Signature-Ed25519 and echo the request’s event_id.
Key rotation. Only one key is active per side at a time, so a rotation — of your key or Ripio’s — is coordinated with your Ripio contact.
Idempotency. Design your handler around event_id: processing the same event twice must not double-count anything on your side.

Overview

Crypto Widget

API Integration

Envelope

Verifying the signature

Signing your response

`transaction_approval_request`

Responding

`transaction_result`

Acknowledging

Cancel reasons

When you don’t receive a result

Deposits and withdrawals

When it’s sent

On-chain cancel reasons

Configuring your endpoint

​Envelope

​Verifying the signature

​Signing your response

​transaction_approval_request

​Responding

​transaction_result

​Acknowledging

​Cancel reasons

​When you don’t receive a result

​Deposits and withdrawals

​When it’s sent

​On-chain cancel reasons

​Configuring your endpoint

Envelope

Verifying the signature

Signing your response

`transaction_approval_request`

Responding

`transaction_result`

Acknowledging

Cancel reasons

When you don’t receive a result

Deposits and withdrawals

When it’s sent

On-chain cancel reasons

Configuring your endpoint