SDKs

The CoRelayer API is plain HTTPS and JSON, so you can call it with curl or any HTTP client. A client library takes care of the parts that are easy to get wrong: failover between hosts, error handling and relaying a transaction with a single signature.

Pick a package

Language	Package	What it needs
TypeScript and JavaScript	@corelayer/sdk	TypeScript 5.9 or later, and a global fetch (browsers, Node). No runtime dependencies.
Go	github.com/Co-relayer/corelayer/packages/sdk-go	Go 1.24 or later. Standard library only.
Rust	corelayer-sdk	Rust 1.87 or later, on tokio.
Python	corelayer-sdk	Python 3.11 or later, and httpx. Synchronous and asyncio clients.

Each package stands on its own. You install the one for your language and nothing else.

Not published yet

None of the four has a release yet: they are not on npm, crates.io or PyPI, and the Go module has no tagged version. Each page gives the install command for when it is. Until then, the API is plain HTTPS: Pay for your users shows a whole relay with no SDK, and /openapi.yaml describes every route.

The whole API is described in /openapi.yaml. For another language, you can generate a client from it.

What every SDK does for you

• Fails over to the regional direct hosts when you give it their list. If the main host does not answer in time (1,500 ms by default), cannot be reached, answers with a 5xx, sends a 2xx that is not JSON, or sends an answer larger than the size limit, the same request bytes go to the next host. A 4xx is an answer, so it is never retried on another host.
• Raises a typed error for every error answer, with the whole problem document. An error code the SDK does not know yet still arrives with its status and its retryable flag.
• Relays a transaction with one signature. It gets a relayer assigned, runs your relayer check, builds the transaction, asks your wallet to sign it once and submits it. It never asks for a second transaction signature on its own. When the client has no native-auth token for the sender, you give it a proof signer, and it asks that signer to sign a short presence-proof message for each assign call, including the renewal of an expired lease.
• Pays for your users from your server: a client created with a sponsor key relays each transaction a user signed, and your plan pays. (Pay for your users)
• Checks the relayer before you sign: it reads the relayer's state from the CoRelayer contract through a MultiversX gateway you choose, and checks that the relayer is in the sender's shard.
• Gives you a method for every operation of the API, with types for every request and response.
• Walks paged lists page by page, reads the event streams, and streams CSV exports without holding them in memory.
• Checks the signature and the timestamp of a webhook delivery, and reads and writes the x402 payment headers.

That relayer check is the only call an SDK makes to anything other than the CoRelayer API. No SDK computes Relay Units for you: ask POST /v1/quote, or use the formula.

To tell us which app is calling, add a CoRelayer-Client: <name>/<version> header through the client's headers option. The API logs it and never refuses a request because of it.

Runnable examples

The TypeScript programs in the recipes and guides come from the examples/ folder of the docs site. A build step copies each file into the pages that show it, so every page shows the tested code. The test suite type-checks every file against the API types and runs it against an in-memory stand-in for the API and for a MultiversX gateway, which checks the Ed25519 signatures the examples produce. It uses no network and no real key.

File	What it does
wallet.ts	A signer for a program that holds its own key, built on @multiversx/sdk-core: the presence-proof message, and one signature per transaction.
gateway.ts	Two reads from a MultiversX gateway that CoRelayer does not run: an account nonce and a contract view.
verify-relayer.ts	The relayer check: same shard, then getRelayerState on the contract you pinned, cached per chain ID, registry version and relayer.
send-token.ts	Sends a token without holding EGLD: build, prove presence, get a relayer, check it, sign once, relay. It also shows how to sign again when the API asks.
sponsor-relay.ts	Pays for your users: your server relays a transaction a user signed, with a sponsor key read from the environment.
sponsor-call.ts	One sponsored action end to end: the user's presence proof, the relayer check, one signature and the relay, for a call to an allow-listed contract.
sponsor-http.ts	The same sponsored action with no SDK: three HTTPS calls, the relayer check and one signature.
preflight.ts	Quota and quote before you sign: will the transaction be served, who pays, and how many units it costs.
pick-tier.ts	Picks a tier from the live pricing document.
buy-plan.ts	Buys a plan on chain without holding EGLD, after checking the contract, the price ceiling and the relayer.
x402-purchase.ts	Buys a plan over HTTP 402.
watch-intent.ts	Follows an intent to its outcome, by polling or over the event stream.
retry.ts	Retries what the server marked retryable, after the delay the server asked for.
relay-units.ts	The Relay Unit formula.
agent-quickstart.ts	All of the above as one program: discover → check → buy → relay → follow.

Each page shows the whole file it uses, so you can copy it next to your own code. The files need @corelayer/sdk and @multiversx/sdk-core, and run on Node 24.

The Go, Rust and Python code on Pay for your users and in the language guides comes from each SDK's own example file (example_site_test.go, examples/site_snippets.rs, examples/site_snippets.py), which that SDK's test suite compiles or runs.