The Infinity hub is the orchestration service in front of the Open Intents Framework aggregator and the solver engines. A client asks it for a quote (the hub runs one round across the configured providers, vets the answers and discloses the winner), then submits an order against that quote, then follows the order through three status views. The hub is an exposure layer that lets a frontend or a backend start flows and see order state; it is not what makes the system safe — the contracts, the engines and the attestation committee are. c8ntinuum’s native cross-chain protocol is IBC (IBC Interoperability). The Infinity hub is the intent-based swap and bridge rail in front of the Open Intents Framework aggregator and the solver engines, for routes that leave the IBC trust model: a user’s funds move under an intent that a solver fills and the contracts settle, and the hub is the API through which an integrator quotes, submits and follows that intent.
Getting access. Integration access to the Infinity hub is by request: email [email protected]. Your organization, its project and its keys are then managed in the hub dashboard: a secret API key for your servers, and a public project id for your web pages (Authentication).
Base URL. https://proxy-api.infinimesh.net/v1: the public test hub, which runs on test networks only. Every example in these docs uses it; your production address comes with your integration access (above).
A secret key never goes in a web page. A page calls either your backend, which holds the key and forwards the page’s calls (a proxy server: Partner backend), or the hub’s gateway directly with your public project id (Authentication — project ids), which opens every route but the order history: a page can quote, submit, follow and refund its orders itself. The gateway never takes a secret key from a browser.

​
Start here

Quickstart

A gasless order in five calls and one signature: read the catalog, quote, sign, submit, then watch it fill.

API overview

Every route under /v1, grouped by family, with the credential each one takes.

SDK

@c8ntinuum/infinity-interop-sdk: a partner proxy for your backend, a project-id transport for web pages, and quote-to-settlement flows with checks before every signature.

Integration notes

Behaviour an integrator would not expect from the rest of this reference: what happens and what to do.

​
Core concepts

Conventions

Base URL, headers, the response envelope and its statuses, value formats, id namespaces and unknown fields.

Authentication

The two credentials: a secret API key for your servers, a public project id for your web pages; origin lists, and keeping your users apart.

API keys and rate limits

Keys from the hub dashboard, keeping them safe, and the gateway’s and the hub’s rate limits.

Step execution

What a winning quote hands you and what to do with it: sign a payload, send a transaction, or both.

Trade types

Exact input or exact output, firm or decaying terms, who carries the fill risk, and where slippage tolerance applies.

Order lifecycle

The three status views, which id opens which, how an order moves through them, and when to stop polling.

Handling errors

How to read an error body, what a retry means, and which failures need more than a retry loop.

Solana support

Everything Solana-specific in one place: a Solana source or destination, signing the escrow envelope, submitting, following and refunds.

​
Resources

Supported chains and assets

The chains and assets a deployment declares, by family, and how to read the catalog.

Flows

The sequences at a glance: gasless openFor, proxy lanes, open flow, preview then prepare, status polling and lost-ack recovery.

Error reference

The full EIN, EPX and EMC catalogue: every hub, gateway and framework error code, what it means and whether to retry.

Limits

Rate limits, timeouts, size caps and the other operational behaviour that applies across routes.

Troubleshooting

Symptom, cause and fix, grouped by phase: reaching the hub, credentials and origins, quoting, submitting and following an order.

​
API reference

Discovery

GET /catalog, the deployment’s declared chains and assets, and GET /openapi.yaml, the API’s machine contract.

Quotes

POST /quote, /quote/preview and /quote/prepare: one round, indicative offers, or one chosen provider under a stable id.

Orders

POST /order/openfor for a gasless or proxy-lane order and POST /order for the open flow.

Status

GET /order/{orderId}/status, GET /status/{orderId} and GET /orders: the three views of an order.

On-chain views

Observed fill facts, a transaction hash resolved to its order, and the escrow’s raw order tuple.
The hub’s behaviour in this reference was verified call by call against a live hub deployment; the gateway’s (credentials, origins, EPX codes and timeouts) is as the hub team specifies it. The hub has no push channel — no webhooks, no websockets — so follow an order by polling its status views.