API overview
The UPI Setu API exposes payment collection, mandates, refunds, and QR generation behind a single REST surface. This page is the 30-second tour: how to authenticate, which environment to call, how we handle failures, and where every endpoint lives.
https://uat.setu.co01Authentication
Every request carries three identifiers issued in The Bridge. Sandbox keys are pre-seeded the moment you create an app.
| Header | Purpose |
|---|---|
X-Client-ID | Identifies your app. Safe to include in any environment. |
X-Client-Secret | Secret shared with your app. Never expose in the browser. |
X-Setu-Product-Instance-ID | Routes the request to a specific product instance. |
02Environments
| Environment | Base URL | Behavior |
|---|---|---|
| Sandbox | https://uat.setu.co | Simulated bank rails. No money moves. |
| Production | https://prod.setu.co | Live rails. Activated after KYC. |
03Idempotency
Send an Idempotency-Key header on every POST. Retrying the same key returns the original response without creating a duplicate.
- Keys are scoped per credential.
- Keys expire after 24 hours.
- Editing the body with the same key returns
409 Conflict.
04Errors
Errors follow a consistent shape: code, message, optional details. Status codes map to operational categories so retries can be automated cleanly.
05Pagination
List endpoints return cursors, not page numbers:
{
"data": [/* … */],
"page": { "next": "eyJpZCI6ICJwY18xMjMifQ==", "hasMore": true }
}Pass ?after=<cursor> to get the next page. Cursors are stable for 7 days.
06Webhooks
Subscribe to events in The Bridge. Setu retries failed deliveries with exponential backoff for 24 hours, then quarantines them for manual replay.
X-Setu-Signature header on every webhook — it's an HMAC-SHA256 of the raw request body with your webhook secret.07Endpoints
Payments
4Initiate, query, and finalize UPI collects.
QR codes
2Static and dynamic QR generation for offline collection points.
Mandates
3Recurring debit authorization on UPI.