Skip to main content
Request a demo
Platform

Developer API

Infrastructure that cannot be driven programmatically is a product, not infrastructure.

One transaction boundaryThree stacked elements — a record, a rule and a ledger posting — enclosed by a single boundary, indicating that all three commit together or not at all.ONE TRANSACTION BOUNDARYRecordwhat is trueRulewhat is permittedPostingwhat it did to the bookscommit together

What it changes

  1. Tenant-scoped by constructionEvery credential belongs to a tenant, and the same three isolation layers apply to an API request as to a session.
  2. Idempotency is required, not optionalEvery state-changing call takes an idempotency key, because a retried request that creates a second payment is the failure mode that matters.
  3. Events, not pollingDomain events are written in the same transaction as the change that produced them and relayed afterwards, so a consumer learns about a settlement because it happened.
Ask, agree, then actThree steps. One person requests, a different person approves, and only then does the state change. The approval binds to what was requested, so editing it afterwards invalidates the sign-off.Requestone personApprovea different oneActnow it movesThe approval binds to what was asked.Edit it afterwards and the sign-off is void.
Every irreversible act on this platform takes this shape, whatever the subject of the page: one person asks, a different one agrees, and only then does anything move.
The developer surface, built and unbuiltIdempotency keys, tenant-scoped clients and the outbox relay exist. The HTTP routes, the API client credentials and outbound webhooks do not, and are drawn as absent components.Your serviceHTTP routesAuth, versioning, rate limitsNot builtThe servicesIdempotency, tenant scoping,authorization, auditBuilt and testedOutboxEvents, in the sametransactionWebhooksNot built — needs SSRF egress controlThe dashed boxes are the honest half of this drawing.Everything a route would need is in place. What is missing is the route — and outboundwebhooks mean HTTP requests to tenant-supplied URLs from inside the network.
The dashed boxes are the honest half. Everything a route would need is in place; the route itself is not built, and neither are outbound webhooks.

What it includes

REST resourcesAssets, offerings, subscriptions, payments, holdings and transfers.
WebhooksSigned, retried with backoff, and dead-lettered rather than dropped.
SandboxA separate tier where nothing touches real money and mock providers are permitted.

See it against something real.

Bring an instrument you are actually considering. Structuring it is the only way to judge whether the model fits.

Request Enterprise DemoBack to platform
Your instrument, against this modelAn unspecified asset on the left feeds four stages: structure, compliance policy, the offering book and the register. The asset is drawn as an outline because it is the reader's, not the platform's.Your assetwhatever it isStructurePolicyBookRegister