Why Olympex

The new economy doesn’t wait. Olympex started as the trader’s terminal on Mount Olympus, and the REST API brings its routing to your product: one signed request returns the best route Olympex finds across its liquidity sources, and a second returns the unsigned transaction that executes it. The same API runs limit orders and DCA strategies that Olympex executes for your users.

​

The case for Olympex

​

Aggregated liquidity

You don’t pick a venue: you ask for a quote. POST /quotes requests routes from the liquidity sources Olympex integrates, ranks them by orderBy (highest output by default), and returns the winner’s outAmount, the DEXes its route uses (routes) and the source that produced it (aggregatorId). The response also lists every source that quoted, best first, in aggregatorOrder. If building the swap with the winning source fails, or its calldata reverts when you estimate gas, build it with the next one. To leave a source out, pass its ID in excludeMetaAggregatorId. Aggregation and routing explains the ranking in detail.

​

One request shape on every chain

A quote on Arbitrum has the same shape as a quote on Polygon: you change chainId and the token addresses. GET /chains returns the chains Olympex has enabled, and GET /tokens returns the tokens it lists on each one, with address, symbol, name, decimals and, when one exists, a logo URL, so you can build chain and token pickers from the API. A cross-chain transfer starts on a chain marked Yes in the cross-chain source column and ends on another chain in the table. Whether a specific pair has a route depends on the providers when you ask, so request a quote to confirm it. Limit orders and DCA execute only on the chains marked Yes in the last column, through the Olympex order contract on each one. Order signatures and allowances lists the contract address on each chain. GET /chains returns chain IDs only, without names, logos or capabilities. If your product needs them, keep this table’s names and columns in your code, and use GET /chains to decide which of these chains to offer: offer a chain only while its ID is in the response. POST /support-chain checks one chain ID against the same list.

​

Cross-chain in one quote

Set mode to cross-chain and POST /quotes returns a route between two chains. It can include a swap on the source chain, the bridge and a swap on the destination chain (middlewareRoute), and it reports the expected amount you receive (toTokenAmount), the minimum after slippage (minimumReceived), the bridge used (bridgeInfo) and the provider’s estimate of the transfer’s cost in USD (estimateCostInUSD). Cross-chain routes come from cross-chain providers; signed API accounts receive routes from OKX (okx) and Rango (rango). After you broadcast, POST /tx-status reports the provider’s status for the transfer until it settles. Cross-chain mechanics covers the full lifecycle.

​

Limit orders and DCA

Olympex also executes orders on your users’ behalf:

• A limit order sells amount of inTokenAddress for outTokenAddress. The order executes when the market price of inTokenAddress, in outTokenAddress, reaches priceTrigger or better. You create it with POST /limit-order, follow it with GET /limit-order/{id}, and can cancel it while it is pending.
• A DCA strategy spends totalAmount of one token in iterations equal orders, one every frequency seconds, to buy another: for example 100 USDC into WETH in 10 daily orders. You create it with POST /dca-order/strategies, and Olympex places the orders one frequency apart.

Both products work the same way on-chain. The maker wallet signs the token pair once and approves the Olympex order contract. Nothing moves when you create an order: when it executes, Olympex pulls the tokens from the maker’s wallet through that contract, swaps them and sends the output back to the same wallet. Limit orders, DCA and Order signatures and allowances cover the details.

​

Non-custodial by design

The API never asks for a private key.

• Swaps. POST /swap returns the transaction fields (to, data or calldata, value) and the ERC-20 spender to approve (contractToApprove). Your wallet signs and sends the transaction, so funds move only when you broadcast.
• Limit orders and DCA. Olympex sends the execution transactions. Your token allowance to the Olympex order contract is the on-chain limit on what it can move, so approve only what your open orders need.

Each swap transaction also carries safeguards:

• It is bound to the account you pass to /swap, which sends the transaction and receives the output.
• It carries an on-chain expiry, 5 minutes on most routes.
• A single-chain swap reverts if the output would fall below minOutAmount.

Security model describes what Olympex can and can’t do with your transactions.

​

Integrator fees

Add the same fees object to your signed quote and swap: feeBps from 0 to 100 (100 is 1%) and the feeRecipient address that receives it. The quote’s integratorFeeBreakdown reports your margin and the Olympex protocol fee separately, so you can show both to your users. Fees apply to signed requests from API accounts. Gas and fees explains the units.

​

Built to integrate

• One surface. 19 endpoints under one base URL, using GET, POST, PATCH and DELETE. Olympex answers success and failure with one JSON envelope; responses from the API gateway, such as a rejected signature, carry only {"message": …}.
• Traceable. Every response envelope carries meta.requestId, and gateway responses carry an apigw-requestid header, so support can find your exact request.
• Verifiable signing. Reference signers in TypeScript, Python and bash are checked against published known-answer vectors.
• Machine-readable. The OpenAPI 3.0 spec is public at https://docs.olympex.io/api-reference/openapi.json. Generate a typed client from it and wrap it with the signer.
• Hands-on. The API console signs requests in your browser, and a test API key takes one click. If your browser blocks a call, use the console’s Copy as cURL or create the key from a terminal.

​

Start building

Create a key, then follow the quickstart to send your first signed request.