Dashboard and account

The dashboard is a first-class way to operate your TensorRail account without writing code. Key management, team and roles, webhook configuration and delivery inspection, and reconciliation exports are all self-serve. This page is the operator's guide to those tasks; anything you can do here you can also do programmatically through the account and reporting API (the /v1 surface, documented in Reporting API), but the dashboard is the fastest path for most account operations.

Security-sensitive operations require an extra verification step (step-up); see Step-up verification below.

What you can do here

Task	Where	Step-up?
Create, rotate and revoke API keys	Developers → API Keys	Yes
Assign team roles	Settings → Team	Yes
Set the webhook endpoint, rotate its secret	Developers → Webhooks	Yes
Inspect webhook deliveries and their attempts	Developers → Webhooks	No
Re-drive a webhook delivery	Developers → Webhooks (test mode only — in live mode this is API-only, POST /v1/webhooks/deliveries/{event_id}/retry)	No
Browse and filter payments, export CSV	Activity → Payments	No
Read volume and success-rate reporting	Activity → Analytics	No
Read balances	Balances	No

Everything here is also available programmatically — see the Reporting API. The dashboard is simply the fastest path for most of it.

API keys

Manage keys under Developers → API Keys.

• Create. Generate a new key. The plaintext value is shown once, at creation and never again, so copy it into your secret store immediately. Keys come in two forms: secret (rail_full_…, full server-to-server access) and publishable (rail_open_…, browser-safe, paired with a payment's client_secret). The mode is in the key: …_test_… for sandbox, …_live_… for production. See Authentication.
• Rotate. Rotation issues a replacement key and retires the old one, so you can cut over with no downtime: deploy the new key, verify traffic, then retire the old.
• Emergency revoke. If a key is exposed, revoke it immediately and reissue. Then review your recent payment list and webhook deliveries for anything unexpected.
• Delete. Remove a key you no longer use.

Scopes

A key carries scopes that bound what it can do. Scopes are named family:level across twelve families — the 19 scopes a new key is issued with are listed in Authentication. A new key gets that default set rather than everything the platform defines; a scoped key carries only what you grant it, and a call outside its scopes is rejected with ERR_1004 (insufficient_scope). Publishable keys carry no server scopes at all.

Grant the least scope a job needs. A reporting integration that only reads transactions needs payments:read, not a full secret key; a refund worker needs refunds:write and nothing more.

Team and roles

Invite teammates and assign roles so people have the access their job needs and no more. Roles map to the same scope vocabulary as API keys (see Authentication), so a support agent can be read-only while a finance operator can act on money-adjacent surfaces. Remove access promptly when someone leaves.

Webhooks

Configure and inspect webhooks under Developers → Webhooks.

• Endpoint URL. Set the HTTPS endpoint on your server that receives events. Changing it is a protected action.
• Signing secret. Get, and rotate, the secret you use to verify incoming webhooks. Treat rotation like key rotation: deploy the new secret to your handler before rotating, so no in-flight delivery fails verification. See Handle webhooks.
• Delivery inspection. The delivery log shows each event, each delivery attempt, and the response your server returned, which is the first place to look when webhooks are not landing.
• Re-drive. Re-deliver an event that failed (for example while your endpoint was down) once your endpoint is healthy again.

For the programmatic equivalents (config, deliveries, attempts, retry), see Webhook endpoint and deliveries.

Reports and exports

Reconcile from the dashboard without building anything.

• Transaction history. Browse and filter payments and refunds.
• CSV exports. Export your transaction history to CSV for your finance team, with the fee and settlement_status columns on every row. Larger exports can be run as an asynchronous job and downloaded when ready.
• Analytics. Daily volume and success-rate reporting.

Every export ties back to the double-entry ledger under your balance, so each row reconciles line by line against the postings that produced it, with no translation layer. See Money integrity and Fees and currency.

Balances

The balance view shows the available / pending / settled split for every currency you collect in, rather than a single number: pending is still inside a corridor's clearing window, available has cleared and had its fees booked, and settled is no longer counted as available. The same three numbers are on the API, one entry per currency — see Balances. Where the fees behind those numbers come from is explained in Fees and currency.

Step-up verification on sensitive actions

Security-sensitive operations require an additional two-factor step-up when performed from a dashboard session. This applies to:

• API key creation, rotation, revocation, and deletion.
• Webhook endpoint and signing-secret changes.
• Team role assignment.

Step-up is deliberate friction on the operations an attacker would target. Programmatic calls made with a properly scoped API key are not interrupted by step-up, which is exactly why those keys must be protected: rotate on any suspicion, scope them tightly, and never commit them.

Related

• Authentication: key types, modes, and how to send them.
• Handle webhooks: verifying and processing events.
• Fees and currency: where fees and conversion appear.
• Reporting API: the programmatic equivalents on the /v1 surface.

TensorRail, Limassol, Cyprus.