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
Enrol two-factor, review sessions and recent logins	Security	Depends; see Account security
Restrict secret-key API calls to known IP ranges	Security → IP allowlist	Yes
Read the account audit trail	Audit	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. Rotate on a key's row issues a replacement with the same name, after a confirmation and a two-factor code, and shows the new key once. The old key keeps working for 24 hours, and the list shows when it stops, so you can deploy the new key with no downtime. The new key can be rotated one hour after it was issued (ERR_3008 before then), and a key that is already being replaced has no Rotate action: rotate its replacement. See API key management.
• Emergency revoke. If a key is exposed, revoke it immediately and reissue. Then review your recent payment list and webhook deliveries for anything unexpected. A key already being replaced by a rotation offers Revoke instead, because its replacement already exists.
• Revoke. Stop a key you no longer use. It stops working at once, with no grace window.

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. Scopes are enforced on the account API (/v1/...), where a call outside a key's scopes is rejected with ERR_1004 (insufficient_scope). Publishable keys carry no server scopes at all.

Team and roles

Invite teammates and assign roles so people have the access their job needs and no more. A support agent can be read-only while a finance operator acts on money-adjacent surfaces; who may do what is set out role by role in Team and roles, along with the endpoints that invite, re-role and remove people. Remove access promptly when someone leaves.

Security

Two-factor enrolment, the sessions currently open, when recent sign-ins happened, the password, and where security alerts are sent all live under Security; see Account security.

The same page holds the IP allowlist, which restricts the API calls made with your secret keys (payments and the account API alike) to addresses you nominate. Read IP allowlist before adding the first entry: enforcement starts the moment it commits, and an entry that covers only your laptop blocks your production servers' API calls, payments included.

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.
• Test delivery. In test mode, Send test payment creates a small test payment that succeeds straight away. Its real payment_succeeded event is delivered to your saved endpoint, signed with your current secret, and shows in the delivery log. Save an endpoint URL first.
• 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 fee_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.

These three are dashboard-only. An API key cannot perform them at all: a request carrying one is rejected with 401 and ERR_1019 before the handler runs, whatever scopes the key holds. There is no key-based route to creating another key, changing where your webhooks are delivered, or granting a teammate a role, which is the point, because each of those is how a stolen key would become permanent access.

Everything else an API key can do (taking payments, issuing refunds, reading your transactions and reports) is uninterrupted. Keys still need protecting for the ordinary reasons: use Emergency revoke on any suspicion and never commit them.

Related

• Authentication: key types, modes, and how to send them.
• Account security: two-factor, sessions, recent logins, security email.
• Team and roles: the six roles and what each may do.
• IP allowlist: restricting secret-key API calls to known networks.
• Handle webhooks: verifying and processing events.
• Fees and currency: where fees appear.
• Reporting API: the programmatic equivalents on the /v1 surface.

TensorRail, Limassol, Cyprus.