Quickstart
Three steps from zero to a matched, escrowed cash request — all in sandbox, no real money, no approval needed.
1 · Create a test API key
Sign in to the dashboard as a requester and create a wsk_test_ key. Test keys operate against sandbox liquidity and never move real value.
2 · Call the API
POST /v1/cash_requests Authorization: Bearer wsk_test_... { "amount_cents": 50000000, // $500,000.00 "city": "Aleppo", "deadline": "2026-06-20T00:00:00Z" }
3 · Receive the match
The response contains the agents matched, the escrow locked, and one-time pickup codes to relay to your recipients. Webhooks fire in parallel.
Authentication
Authenticate every request with an API key in the Authorization header. Keys come in two modes: wsk_test_ hits the sandbox; wsk_live_ moves real value and requires an approved, sanctions-cleared organisation.
Authorization: Bearer wsk_live_AbC1...
Live playground
This calls the real sandbox API on this server. Create a test key in the dashboard, paste it below, and fire a request against live sandbox liquidity.
/v1/cash_requests sandbox// Response appears here. // Tip: create a requester account and a test key // in the dashboard at / first.
Create a cash request
POST/v1/cash_requests
The core endpoint. Creates a request and, by default, immediately matches it against the best-priced available agents and locks escrow. Set auto_match: false to create the request and collect quotes over time instead.
| Field | Type | Notes |
|---|---|---|
amount_cents | integer | Cash to deliver, in cents. Required. |
city | string | Delivery city. Required. |
deadline | ISO 8601 | Deliver-by time. Required. |
fulfillment_method | enum | cash_pickup (default), bank_deposit, mobile_wallet. |
max_fee_bps | integer | Optional fee ceiling in basis points. |
auto_match | boolean | Default true. Match & escrow in the same call. |
// 200 OK { "id": 42, "object": "cash_request", "amount_cents": 50000000, "status": "filled", "allocations": [ { "allocation_id": 88, "agent_id": 3, "amount_cents": 40000000, "fee_cents": 600000, "pickup_code": "A1B2C3D4" }, { "allocation_id": 89, "agent_id": 5, "amount_cents": 10000000, "fee_cents": 150000, "pickup_code": "E5F6G7H8" } ] }
Retrieve & list
GET/v1/cash_requests/:id
GET/v1/cash_requests — your 50 most recent.
GET/v1/account — balances, mode, and live-eligibility.
Allocations
An allocation is one agent fulfilling part of a request — the unit of escrow. A $500K request might split into three allocations across three agents.
GET/v1/cash_requests/:id/allocations
Confirm & dispute
POST/v1/allocations/:id/confirm
Release escrow to the agent after your recipient confirms receipt. If you do nothing, escrow auto-releases after the silence window — so confirm only matters when you want to release early.
POST/v1/allocations/:id/dispute
Freeze an allocation and escalate. Funds stay locked until resolved; a lost dispute can slash the agent's collateral to make you whole.
Webhooks
Register an endpoint and we POST signed JSON on every state change, so you never poll. Each delivery carries X-Wasala-Signature = HMAC-SHA256 of the raw body using your webhook secret.
| Event | Fires when |
|---|---|
cash_request.created | A request is accepted. |
cash_request.matched | Agents are matched and escrow locked. |
allocation.created | An agent is assigned a fill. |
allocation.released | Escrow released to an agent on confirmed delivery. |
allocation.disputed | An allocation enters dispute. |
// Verify in your handler (Node) const sig = crypto.createHmac('sha256', secret) .update(rawBody).digest('hex'); if (sig === req.headers['x-wasla-signature']) { /* trusted */ }
How it works
You are the requester. Behind the API sits a marketplace of in-country cash agents who post collateral and compete on rate. When you create a request, the matching engine fills it cheapest-first across verified agents, locks your funds in escrow per allocation, and releases to each agent only on confirmed delivery. Disputes freeze funds and can slash agent collateral. You see one clean API; the messy last mile is ours.
test mode against sandbox liquidity. Going live requires an approved organisation — typically via a licensed sponsor — which is a commercial step, not a code change.