Passthrough
How the gateway forwards a call to one product byte-faithfully — money as opaque strings, native errors preserved, the product's credential threaded.
Passthrough is the single, product-agnostic mechanism for reaching a product. You name the product and a sub-path; the gateway forwards your call to exactly that product in its own native vocabulary and returns the product's own response, unchanged.
POST /products/{product}/passthrough/{productPath}The product is a routing parameter, not a branch — the same code path serves every
product. The productPath is the product's own sub-path, carried verbatim.
What the gateway adds — and only this
- Consumer authentication (your One-API leg)
- Fail-closed entitlement enforcement
- Context resolution
- Routing and threading the product's own credential
It transforms no payload semantics.
Money is never parsed
Monetary amounts pass through as opaque strings — never parsed into numbers. Amounts are exact and may exceed 2^53, so a JSON number would lose precision.
Byte-faithful responses
The product's own response is returned unchanged — its exact status code and its own
structured error classes. The gateway never collapses a product's precise rejection
(for example, a Ledger available_liquidity_rejection at 422) into a generic gateway
error. You branch on the product's own error classes as if you called it directly.
Two kinds of failure
A product that answers with an error has that 4xx/5xx forwarded byte-faithfully.
A product the gateway cannot reach surfaces as the gateway's own
product_unavailable (503) — distinct, because no product response was received.
Idempotency and references
Idempotency keys, metadata, and references thread through verbatim and opaque. The
gateway's own Idempotency-Key header is its retry safety for the gateway leg,
distinct from any idempotency the product enforces on its own contract.
Next
- Provisioning — getting a tenant in the product first.
- Errors — the gateway's own error model.