Skip to main content
There is no separate sandbox. A pilot runs against the production engine with its own partner and merchant records, and test transactions are real sealed records under those merchants. Name test merchants so they are easy to exclude from reporting.

Collection variables

Send the key as a header named x-api-key. Placing it under Params puts it in the query string and the request is rejected.

Folders and requests

1

System

GET {{base_url}}/api/v1/health, GET {{base_url}}/api/v1/version, GET {{base_url}}/api/v1/jurisdictions/countdown. No key needed. Confirm enacted_states and dataset_version.
2

Jurisdiction

GET {{base_url}}/api/v1/jurisdiction/zip/27601?transaction_type=retail, then the same with transaction_type=tax_payment, then GET {{base_url}}/api/v1/jurisdiction/OK?transaction_type=state_agency&transaction_timestamp=2026-11-01T09:00:00-05:00. Compare activation.state, tier, and pending_rules.
3

Register

POST {{base_url}}/api/v1/partner/merchants/register with the partner key and two locations in different states. Save merchant.api_key and merchant.merchant_id into the variables.
4

Transactions

With the merchant key: a cash sale by location_id; the same with a wrong zip_code to see the cross-check; a card sale (no rounding); an EBT split tender; a tax_payment in North Carolina (round down); an Indiana retail sale dated 2026-12-01 with and without early_adoption: true.
5

Reversals

Refund the first sale in full, then void the card sale. Fetch the audit receipt for each.
6

Evidence

GET {{base_url}}/api/v1/admin/verify-hash-chain with an auditor or admin key. POST {{base_url}}/api/v1/export with export_mode: full.

Postman tests worth keeping