Predictable Resources
Resources are designed to be consistent, well-typed, and stable in shape, so integrators can model them confidently and evolve alongside the platform.
An API-first platform designed to let developers and enterprises build on programmable payment rails — where the product surface is the API itself, not an afterthought bolted onto a dashboard.
Many platforms build a product and then expose a partial API over it. We are designing the API as the product surface from the outset, so the primitives developers touch are the same primitives the system runs on.
Resources are designed to be consistent, well-typed, and stable in shape, so integrators can model them confidently and evolve alongside the platform.
Write operations are designed to accept idempotency keys, so retries under network uncertainty cannot create duplicate movements.
Errors are designed to be structured and machine-readable, carrying a category and reason rather than opaque failure codes.
The following resources describe the planned API surface. Names and shapes are illustrative and subject to change; nothing here represents a live or callable endpoint.
# Illustrative design sketch — not a live endpoint.
# Base URL is a placeholder; the API is not publicly available.
POST https://api.example-railix.invalid/v1/payment_instructions
Authorization: Bearer <sandbox_key>
Content-Type: application/json
{
"amount": "1500.00",
"currency": "USD",
"source_account": "acct_29fk...",
"counterparty": "cpty_7bd2...",
"idempotency_key": "pi_2f0a1c9e"
}
# Illustrative response
{
"id": "pmt_8Kd0aX2mQ",
"object": "payment_instruction",
"state": "screening",
"amount": "1500.00",
"currency": "USD",
"created_at": "2026-01-01T00:00:00Z"
}State changes are designed to be delivered as signed, replayable events, so integrators can react to the platform rather than poll it. The flow below describes the intended delivery model.
An integrator registers an endpoint and selects the event types it wishes to receive.
A state change produces an event recorded to an append-only log with a stable identifier.
The event is delivered with a signature so the receiver can verify authenticity and integrity.
Failed deliveries are retried on an increasing backoff schedule to absorb transient outages.
Integrators can replay events from the log to recover from downtime without data loss.
Planned event names (illustrative): payment.created, payment.screened, payment.settled, payment.failed, ledger.entry.posted.
Developer experience is treated as a core deliverable. The following are planned commitments, not currently available offerings.
Planned onboarding that starts in a sandbox, so integrators can build and test before anything touches production value.
A planned, published versioning and deprecation policy so integrations are never broken without notice and migration paths.
Planned first-class SDKs in common languages, generated from the same specifications that define the API.
Documentation treated as a maintained product surface, versioned and tested alongside the API itself.
The API is not yet publicly available. Request early access to receive sandbox onboarding and updates as the developer platform takes shape.