Authentication

​

The two credentials

​

Secret API keys

curl -sS https://proxy-api.infinimesh.net/v1/catalog \
  -H "x-api-key: $HUB_API_KEY"

• It stays on your servers. Whoever holds it acts as your organization: they can quote and submit orders in its name and read its whole order history. Keep it in a secret store or a git-ignored .env file, never in a page, an app bundle or a repository.
• Its format is c8n_sk_ followed by exactly 43 base64url characters (letters, digits, - and _).
• A refused key is answered 401: EPX0001 when the header is missing or its value is not in that format (a stray space, a truncated copy, a project id), EPX0002 when the key is unknown, revoked or expired (Errors — gateway codes). The SDK reads both as HubError.isCredentialRefused: an operator matter, which no retry fixes.
• Stop on a refused key. 20 refused credentials within a minute from one IP make the gateway answer EPX0081 (429) to every call from that IP for the rest of that minute, valid keys included: a server that keeps retrying a wrong key locks itself out (API keys and rate limits).
• Never from a web page. The gateway does not take a key from a browser (No keys in web pages).
• Rotating is done in the hub dashboard: make the new key, move your servers to it, then revoke the old one. More on keys and their rate limits: API keys and rate limits.

​

Project ids for web pages

const answer = await fetch("https://proxy-api.infinimesh.net/v1/catalog", {
  headers: { "x-project-id": "c8n_pk_…" }, // your project id
});

• Every route but the order history is open. The catalog, the quotes, order submission, both status views, the on-chain views and the Solana refund route answer a project id as they answer a key, so a page can follow the orders it submits to the end, and refund them itself. The order history, GET /orders, answers EPX0003 (404): it would show every visitor all of your orders. Keep the ids of the orders a page submits; the history needs your server and its secret key.
• Set only the headers the pre-flight allows. The gateway’s CORS pre-flight allows exactly three request headers: x-project-id, Content-Type and X-Infinity-Subject. A page sends x-project-id, Content-Type: application/json on a POST, and X-Infinity-Subject where the hub requires it; a browser refuses a call that sets any other non-standard header (standard ones such as Accept need no pre-flight).
• Name the visitor. The seven routes that read X-Infinity-Subject require it from a page too. Send a random id per visitor, kept in the browser, so each visitor’s quotes and statuses stay apart: the SDK’s projectTransport sends visitor- and a UUID, kept in localStorage. It labels a visitor and proves nothing (Your users).
• Order reads are not private. Anyone holding your project id and one of your order ids can read that order’s status and its chain facts. Nothing lists the ids, so a page learns only the ones it submitted or was given. (The on-chain views and the refund route are not scoped to your organization in the first place: chain data is public, and a refund pays only the order’s own user.)
• Rate limits apply per visitor IP, plus a pool shared by every visitor of your project (API keys and rate limits).
• A malformed project id is EPX0008 (401), an unknown one EPX0009 (401). Both count toward the lockout of the caller’s IP (EPX0081).

​

Origin lists

​

No keys in web pages

• your backend, which holds the secret key and forwards the page’s calls (a proxy server: the SDK’s createInteropProxy with proxyTransport in the page, Partner backend);
• the gateway, with your public project id.

​

Headers

​

Your users

​

The subject: the hub keeps them apart

curl -sS "https://proxy-api.infinimesh.net/v1/orders?limit=100" \
  -H "x-api-key: $HUB_API_KEY" \
  -H "X-Infinity-Subject: user-42"

• Seven routes require it: POST /quote, /quote/preview, /quote/prepare, POST /order, /order/openfor, GET /order/{orderId}/status and GET /orders. Without it they answer EIN0001 (400), reference x-infinity-subject. The hub keeps each subject’s quotes, orders and history apart, so send the same subject for a quote, its order and its status reads.
• GET /orders lists the orders of the subject you send. Each page echoes that subject in data.subject: refuse a page whose subject is not the one you sent.
• The other routes do not read it. The catalog and the on-chain views are scoped to no one, and the hub does not scope GET /status/{orderId} by subject: a backend that serves several users answers that route for the user’s own orders only.
• The gateway forwards it unchanged, every value you send, and never adds one. It sets your organization itself, from the credential, so a subject can never reach another organization’s orders.
• Choose it as your stable id for the person: the same across sign-ins and wallets, never reused for someone else, one value per call, of 1 to 128 letters, digits and . _ @ + ~ - (^[A-Za-z0-9._@+~-]{1,128}$). The hub refuses any other value with EIN0001, reference x-infinity-subject.
• Check that it works before you serve history: list orders for a subject none of your users has, such as canary- followed by a fresh UUID. The answer must hold no orders and echo that subject; if it does not, serve no history and tell the hub team. The SDK’s verifySubjectScoping runs this check.

​

Your own records

​

See also

• API keys and rate limits — keeping keys safe, and the limits
• Conventions — the base URL, the headers and the envelope
• Errors — gateway codes — every EPX code
• SDK: Partner backend — the secret key on your server; Browser apps — a page with your project id
• Quickstart