Reporting API

The Reporting API exposes account-level data and operations: transaction history, balances, ledger-backed refunds, CSV exports, your API key list and webhook delivery logs, the account audit trail, analytics, and supported currencies. Creating and managing the keys and webhook endpoint themselves is a dashboard action; see Everything else on this surface.

Most merchants don't need this

Everything here is also available in your dashboard, which is how most teams read it. Reach for the Reporting API only when you need to pull this data programmatically (e.g. into your own ledger or BI tooling).

Base URL and auth

The Reporting API is served on the same host as the main API, under the /v1 prefix. What differs is the auth scheme: it uses bearer-token auth with the same rail_* key the main API takes in an api-key header.

	Sandbox	Production
Base URL	`https://api.tensorrail.com`	`https://api.tensorrail.com`
Auth	`Authorization: Bearer rail_…`	`Authorization: Bearer rail_…`
Route prefix	`/v1`	`/v1`

Both environments share the same host; a rail_<type>_test_… key reads sandbox data and a rail_<type>_live_… key reads production data. There is no separate sandbox hostname; the key selects the environment.

Transactions

GET /v1/transactions: a composed, filterable transaction history (filter by date, status, currency, or a free-text search):

curl -X GET "https://api.tensorrail.com/v1/transactions?limit=20&offset=0" \
  -H "Authorization: Bearer rail_full_live_xxx"

Filter with from / to (or start_date / end_date), payment_status, currency and a free-text q, and page with limit and offset. (settlement_status was withdrawn on 2026-09-09, since it never reported anything but pending, and is now rejected with 400 rather than silently ignored.) For a single payment's live state, use GET /payments/{payment_id} on the main API instead. (The API reference has an entry for every /v1 operation too, each one linked from these guide pages, but /v1 is gateway-built rather than generated from the engine's schema, so its fields are documented here, on the guide, not there.)

Currencies

GET /v1/currencies: the currencies the API will validate, unauthenticated and platform-wide rather than account-specific. GET /v1/capabilities is the same kind of endpoint: unauthenticated and platform-wide, listing the markets, methods and currencies TensorRail covers. The corridors enabled on your own account are in your dashboard, and your account manager can confirm what else can be opened for you:

curl -X GET "https://api.tensorrail.com/v1/currencies"

See Fees and currency for how amounts and currencies are expressed.

Webhook deliveries

GET /v1/account/webhook-deliveries: inspect recent webhook delivery attempts (useful when debugging your endpoint):

curl -X GET "https://api.tensorrail.com/v1/account/webhook-deliveries?limit=20" \
  -H "Authorization: Bearer rail_full_live_xxx"

The same delivery log is available in the dashboard under Developers → Webhooks. See Webhooks for signature verification and retry behavior, and Webhook Endpoint & Deliveries for the richer /v1/webhooks/* surface (config, per-event attempt chains, manual retry).

Audit log

GET /v1/audit: every account-level action worth recalling later (key rotations and emergency revokes, two-factor enrolment, IP allowlist changes) is recorded and readable:

curl -X GET "https://api.tensorrail.com/v1/audit?limit=50&offset=0" \
  -H "Authorization: Bearer rail_full_live_xxx"

Requires the payments:read scope. Page with limit (default 50, capped at 100) and offset; entries come newest first.

{
  "audit_logs": [
    {
      "id": "…",
      "created_at": "2026-09-08T17:42:55Z",
      "action": "ip_allowlist:add",
      "event_type": "ip_allowlist:add",
      "actor_type": "merchant",
      "actor_id": "…",
      "path": "/v1/account/ip-allowlist",
      "method": "POST",
      "status_code": 200,
      "ip_address": "203.0.113.9",
      "user_agent": "…",
      "request_id": "…"
    }
  ],
  "pagination": { "total": 214, "limit": 50, "offset": 0 }
}

action names the event (api_key:rotate, api_key:emergency_revoke, ip_allowlist:add, ip_allowlist:remove, totp:enable, …); event_type repeats it under the name older clients read. The same trail is in the dashboard.

Analytics

POST /v1/analytics/report: daily volume and success rate for your own account, over a date range:

curl -X POST "https://api.tensorrail.com/v1/analytics/report" \
  -H "Authorization: Bearer rail_full_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{"start_date":"2026-08-01","end_date":"2026-08-31"}'

Requires the analytics:read scope. The body is optional; with none, the range is the last 30 days.

Field	Description
`start_date` / `end_date`	`YYYY-MM-DD`, both inclusive.
`mode`	`live`, `test`, or omitted / `all` for both. `live_mode` is accepted as an alias, and `?mode=` on the query string wins over the body.

{
  "daily_volume": [
    { "date": "2026-08-01", "currency": "INR", "amount": 4500.0, "count": 12 }
  ],
  "success_rate": [
    { "date": "2026-08-01", "success_count": 11, "failure_count": 1 }
  ]
}

daily_volume carries one row per day and currency, so a multi-currency day appears more than once and amounts are never summed across currencies. amount is in major units here (4500.0 INR), unlike the payment API's minor units. success_rate is one row per day, across all currencies.

A mode that contradicts the key you are calling with (asking for live figures with a test key) is refused with 422 ERR_3051 rather than quietly answered from the other environment.

Everything else on this surface

The /v1 surface goes beyond read-only history. Each area has its own guide:

Area	Endpoints	Guide
Balances	`GET /v1/balances`	Balances
Ledger-backed refunds	`POST`\|`GET /v1/refunds`, `GET /v1/refunds/{id}`	Refunds via the Reporting API
CSV exports	`GET /v1/exports/transactions.csv`, `POST /v1/exports`, `GET /v1/exports/{id}[/download]`	CSV Exports
API keys (list only)	`GET /v1/api-keys`, `GET /v1/scopes`	API Key Management
Webhooks (reads and retry)	`GET /v1/webhooks/config`, deliveries, attempts, `POST .../retry`	Webhook Endpoint & Deliveries

Requests on this surface are scope-gated; see the scope table. A key lacking the required scope receives 403 (ERR_1004).

Dashboard-only, not on this API. Creating, rotating and revoking a key; changing the webhook endpoint or rotating its secret; the IP allowlist; account security (two-factor, sessions, recent logins, security notifications, password); and team and roles. Each is a signed-in, two-factor dashboard action with no API call at all, under any credential. See API Key Management, Emergency key revoke, Webhook Endpoint & Deliveries, IP allowlist, Account security and Team and roles.

Base URL and auth​

Transactions​

Currencies​

Webhook deliveries​

Audit log​

Analytics​

Everything else on this surface​