Setup
Configure your webhook URL through the dashboard or programmatically via the Update Webhook URL endpoint. Your endpoint must be a publicly accessiblePOST URL that returns a 200 status code immediately. Process events asynchronously after acknowledging receipt.
Receiving events
Every webhook payload includes three fields:| Field | Type | Description |
|---|---|---|
event | string | The event type (e.g., Deposit, Convert, Transfer) |
data | object | Event-specific payload |
signature | string | RSA signature for verification |
Supported events
| Event | Description |
|---|---|
Deposit | A fiat or crypto deposit was received |
Convert | A currency conversion completed |
Transfer | A transfer (payout/withdrawal) status changed |
Onramp | An onramp (fiat-to-crypto) request status changed |
Withdrawal | A withdrawal was processed |
Offramp | An offramp (crypto-to-fiat) request status changed |
Example: Deposit event
Verifying signatures
Every webhook includes an RSA signature. Always verify the signature before processing an event to confirm it came from Partna. The signature is generated by signing the JSON-encodeddata field with Partna’s RSA private key using SHA-256 with PSS padding. Verify it against the corresponding public key for your environment.
Public keys
Use the correct public key for your environment.Staging
Production
Best practices
Always verify signatures. Never process a webhook event without verifying the signature first. This prevents spoofed events from affecting your system. Return 200 immediately. Acknowledge receipt before processing. If your endpoint takes too long to respond, the delivery may be retried. Handle duplicates. Use thesessionId or rampReference in the event data as an idempotency key. The same event may be delivered more than once.
Log raw payloads. Store the raw webhook body for debugging. If something goes wrong, the raw payload is essential for troubleshooting.