Rail Proof ← Back to home Customer sign in

Developer API

Issue your first proof in minutes.

API version v1 · JSON over HTTPS

01

Get sandbox credentials

Sign in to an approved customer account, open Developer access and create a key with environment “Sandbox”. The secret begins with rp_sandbox_ and is shown once. Sandbox records are excluded from billing and the public directory.

02

Create a record

POST /api/v1/records with Authorization: Bearer rp_sandbox_…, Content-Type: application/json and a unique Idempotency-Key.

{"subject":"Example Ltd","claim_type":"company_status","claim":"The company attests that it is operational.","evidence_level":"participant_attested","visibility":"public"}

03

Issue a validated batch

POST /api/v1/records/batch accepts {"records":[{...},{...}]} with the same authorization headers and one batch-level Idempotency-Key. Up to 250 records are accepted per request.

Every record is validated before issuance begins. Invalid batches return row-level errors and issue nothing. Successful responses report issued, existing, pending-review and failed totals with a result for every row. Replaying the same batch key does not create duplicates. The customer dashboard also provides a CSV template, validation preview and explicit confirmation step.

04

Bybit Verified Trade test pilot

Use a sandbox Rail Proof key and POST /api/v1/records with claim type bybit_verified_trade_test. The customer dashboard provides an internal synthetic simulator. Direct API evidence can use environment: testnet with a permitted read-only Bybit Testnet key and secret, derivatives category, closed order ID, and a lookup window no longer than seven days.

Rail Proof checks the key through Bybit, rejects write-enabled or withdrawal-capable credentials, retrieves the closed-P&L record and executions, removes the credentials before persistence, and forces the resulting certificate into the sandbox. This pilot verifies one trade only—not complete performance. Never send production exchange credentials to the test pilot.

05

Response and verification

A successful request returns the verification ID, public certificate URL, QR URL, signature-verification URL, lifecycle and integrity object. Basic creation returns HTTP 201; an idempotent replay returns HTTP 200.

GET /api/v1/records/:id retrieves a record. GET /api/v1/records/:id/signature verifies its Ed25519 signature. POST /api/v1/records/:id/lifecycle suspends, revokes, expires or supersedes a record with a reason.

06

Webhooks, errors and limits

POST /api/v1/webhooks registers an HTTPS destination. Events are signed, retried with backoff and disabled after repeated failures. API requests are rate limited; clients should retry HTTP 429 and transient 5xx responses with exponential backoff.

Common responses: 401 invalid key, 402 plan inactive or limit reached, 422 invalid claim or missing evidence, 429 rate limit exceeded. Never place API keys in browser code, URLs or public repositories.

Evidence methodologyOpen customer dashboard ↗