The New Eco API: A Production Integration Guide

The New Eco API brings quoting, funding, deposits, and status under one versioned interface at api.eco.com. This guide walks the path most integrations take, states what the API does and does not guarantee, and flags the places where assumptions tend to break in production.

Everything below requests a quote only. No funds move until you decide to fund.

What to evaluate

Suppose you are deciding whether to build on this rather than how; three questions settle it. Each maps to a step below, and one real flow answers all three.

1. Can the application inspect and reject the terms before funding?
2. Can it authorize the intended execution without ambiguity?
3. Can it follow the destination result and tell it apart from intermediate progress?

If you want the constraints before the walkthrough, skip to What the API does not promise. That section is the short version of what you are taking on.

The shape of an integration

Four steps, in order, every time:

1. Request a quote for the movement you want.
2. Review what you are authorizing before anything is signed or sent.
3. Fund the accepted route using the execution the quote returned.
4. Follow delivery at the destination, separately from the funding transaction.

1. Request a quote

Use real source and destination addresses from chain and token discovery. Set the funder to the wallet that will fund the intent. Amounts are strings in the token's smallest unit.

curl --request POST \
  --url https://api.eco.com/v1/quotes \
  --header 'Content-Type: application/json' \
  --header 'x-api-key: <api-key>' \
  --data '
{
  "type": "exact-in",
  "source": {
    "chainId": 8453,
    "token": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "amount": "1000000",
    "funder": "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266"
  },
  "destination": {
    "chainId": 10,
    "token": "0x0b2C639c533813f4Aa9D7837CAf62653d097Ff85",
    "recipient": "0x70997970C51812dc3A010C7d01b50e0d17dc79C8"
  },
  "slippage": 0.005,
  "dappId": "your-app"
}
'

Treat the quote request, not discovery, as the test of whether your specific route is available right now.

2. Review what you are authorizing

This step is where your price control lives. Two levers do the work: destination.minAmountOut bounds what you are willing to receive, and expiresAt bounds how long those terms hold. A quote should give you enough to decide what you accept: source asset and amount, destination, recipient, expiry, and the applicable output terms. Validate the response against the API schema, then check it against your own requirements rather than assuming.

• Compare source, destination, recipient, and amount with what you requested.
• Check destination.minAmountOut against the minimum your application will accept.
• Confirm expiresAt is still in the future. Expiry is in Unix seconds.
• Verify the quote signature using the documented signing scheme and signer address.

Signature verification authenticates the intent data the quote covers. It does not tell you the route satisfies your business policy, that every displayed field is signed, or that this is the best price available in the market. Those remain your checks. The verification pattern is the same whether a quote carries one intent or several, and regardless of the routing underneath, so you build it once rather than once per route design.

Keep the quote together. The quote ID, execution payload, expiry, and intent identifiers are a set. Do not assemble a transaction from fields belonging to different quotes. Reusing a price while replacing the execution does not preserve the original authorization.

3. Fund the accepted route

For an EVM wallet-funded route, follow the transfer guide's reward-token approvals and send the returned execution.transaction unchanged. If approvals eat into the quote's lifetime, request a fresh quote before funding rather than sending against an expired one.

For gasless funding, select a standard supported for your token and target. Gasless means a relayer submits the transaction. It does not mean free, and it does not mean approvals are never required. Do not use both funding methods for the same quote.

Retries need care here. A repeated read is not the same as a second instruction to move money. For a gasless submit, preserve the signed payload and inspect the existing job when a response is uncertain. Signing a new authorization is a new funding action, not a retry.

4. Follow delivery at the destination

Persist the funding transaction hash and the intent identifiers. Query GET /v1/intents/status with the appropriate filter. Strip the documented resource prefix from status-query values; submit bodies keep the full prefixed quote ID.

Model the milestones separately, because they answer different questions:

• The quote was submitted.
• A transaction was published.
• The destination action was fulfilled.
• Settlement completed.

An unknown status immediately after submission often reflects indexing rather than failure, and a polling timeout is a reason to resume tracking, not to fund again.

For a payments application, the real question is whether the recipient received the asset. For a vault integration, it may be whether a particular deposit call succeeded. Show the milestone your evidence actually supports, both to the user and to whoever is debugging an incomplete flow later.

Get started

Read the docs to pick your integration path, or talk to us if you are scoping a production flow or want Eco to help design one.

About Eco

Eco connects digital asset markets through stablecoins. Developers and enterprises use a single integration to program money movement across blockchains, tokenization platforms, and institutional liquidity venues, with real-time routing and pricing intelligence. Whether for trading, treasury, or payment flows, Eco delivers superior price control and all-or-nothing execution against live market conditions and customer-defined requirements.

Website | Eco Docs | Twitter | LinkedIn | YouTube