Skip to main content
POST
Test your webhook
Sends a sample payload to a webhook configured on your API key and tells you what came back. Nothing is created and no real order or payment is touched — this is a delivery check, not a dry run.

Choosing which webhook

An API key carries two, and type picks between them:
  • RAMP (the default) — posts a sample order to rampWebhookURL, the endpoint that receives onramp and offramp status updates.
  • PAYMENT — posts a sample settled payment to paymentWebhookURL, the endpoint that receives payment settlements.
They are separate because the payloads differ, and a key may have one, both, or neither. Test each one you rely on; passing on RAMP says nothing about whether your payment handler works. There is no request body. The URL is read from the key you authenticate with, so whichever key you send in x-api-key is the one whose webhook gets called. That is deliberate: it verifies the configuration Paj will actually use, not a URL you retyped into a test form.

Configuring the URL

Both webhooks live on the API key, alongside its name, and are set from the dashboard when you create or edit a key. A key without one gets no pushes of that kind at all; asking to test a webhook the key has not configured is a 400.

Reading the result

A rejected delivery is still a successful test, so a webhook that answers 404 or times out comes back as a 200 with the detail in the body — you do not have to unpack an error to find out what happened.
  • delivered — true only if your endpoint answered with a 2xx. Anything else, including a network failure, is false.
  • error — present only when delivered is false. Either the rejecting status code or the transport error if the endpoint could not be reached.
  • durationMs — how long the round trip took. Worth watching: a webhook that is slow here is slow in production, where a timeout is treated as a failed delivery.

What your endpoint receives

For RAMP, a POST with an order payload in the same shape as the responses from Create an onramp order and Create an offramp order. The sample describes a PROCESSING Solana offramp. For PAYMENT, a POST with the payload from Create a payment, with status at SUCCESSFUL — the same thing a real settlement delivers. The sample describes a 25 USDC payment on Solana. Answer with any 2xx. The body is ignored — Paj reads it if there is one, but nothing depends on its contents. Either way the delivery is signed exactly as a real one is, with the same secret and the same X-PAJ-Timestamp and X-PAJ-Signature headers. A verifier that accepts this call accepts production traffic, which makes this the cheapest way to confirm your signature checking works before a real settlement depends on it. See Webhook signatures.
Both test payloads are fabricated and their id does not refer to anything real. Make sure a handler that looks records up by id fails softly on an unknown one, or your test will report a failure that says more about the test than about your webhook.

Authorizations

x-api-key
string
header
required

Query Parameters

type
enum<string>
default:RAMP

Which webhook to exercise. RAMP posts a sample order to rampWebhookURL; PAYMENT posts a sample settled payment to paymentWebhookURL.

Available options:
RAMP,
PAYMENT

Response

The outcome of the delivery attempt

url
string
required

The webhook URL configured on the API key that was called

Example:

"https://example.com/webhook"

delivered
boolean
required

True if the endpoint answered with a 2xx

Example:

true

durationMs
number
required

Round trip time of the delivery attempt, in milliseconds

Example:

214

error
string

Why the delivery failed — the rejecting status code, or the transport error if the endpoint could not be reached at all. Absent when delivered.

Example:

"Webhook call failed with status: 404"