Skip to main content
The collection is generated from the same OpenAPI document that powers these docs, so it never drifts from the API.

hypermid.postman_collection.json

Download, then Import it in Postman.

​
Set the variables

The collection ships four variables. Set them once on the collection and every request picks them up.
There is one baseUrl because there is one host. Switching between sandbox and production means changing secretKey, not the URL. See Environments.

​
What is in it

Requests are foldered by tag — payments, quote, status, catalog, balances, onramp — plus a Webhooks (example deliveries) folder. Each request carries the right auth already: the ones that move money send {{secretKey}} as a bearer token, read-only ones send {{publishableKey}}, and the public payer routes send nothing, because attaching a secret to a route that never needed one is how a key ends up somewhere it should not be. Optional query parameters arrive disabled, so Send works immediately instead of submitting a wall of empty values. Enable the ones you want.

​
Replaying a webhook

The webhook folder posts a realistic body at {{webhookUrl}}. Point that at your own receiver — or an ngrok tunnel — to exercise your handler without waiting for a real payment.
The signature headers in those examples are illustrative. They are not recomputed when you edit the body, so a correct verifier will reject them. To test verification end to end, use POST /v1/payments/webhooks/{webhookId}/test, which sends a genuinely signed delivery.

​
Re-importing an updated collection

Request ids are stable: each one is derived from its operation, not generated fresh. So re-importing a newer collection updates the requests in place — your saved examples and per-request tweaks survive, and the diff shows only what actually changed rather than every request as deleted and re-added. Ids only move if an endpoint’s underlying operation id is renamed, which we treat as a breaking change for exactly this reason.