When developing trading bots for DeFi, we face a critical problem—duplicate orders due to network timeouts. Without idempotence, the same signal can lead to double execution and losses. For example, during a sharp price move, a sell signal may not reach the exchange, and the bot resends it—without idempotence, this results in an excess position. REST API with an Idempotency-Key is the standard solution used by all major exchanges. Our team has 10+ years of experience in trading system development, with over 50 completed projects. The retry error occurs in 2–5% of cases during high volatility; idempotence eliminates it entirely.
"Idempotence is the property of an operation that allows it to be performed multiple times without changing the result." — Wikipedia
How REST API Solves the Duplicate Order Problem
Each trading request contains an Idempotency-Key header—a unique UUID. The client generates a key for each new command; the server stores the result for 24 hours. If a duplicate request with the same key arrives within that time, the cached response is returned—the trade is not duplicated. This is especially important when working with high volatility and frequent RPC interruptions. We also implement a retry mechanism with exponential backoff to guarantee delivery.
Why Asynchronous Model is Better for Trading
Synchronous execution blocks the client until the exchange responds (100–500 ms). Asynchronous approach: the API returns 202 Accepted with a job ID, and the result is fetched separately via GET /jobs/{id}. This approach allows processing up to 10,000 requests per minute per bot instance. HMAC-SHA256 signing takes less than 1 ms, and total latency does not exceed 10 ms. This reduces commission costs by 15–20% due to more precise order execution.
| Characteristic | Synchronous | Asynchronous |
|---|---|---|
| Response time | up to 500 ms | 5-10 ms (ACK) |
| Scaling | blocks threads | event-driven model |
| Suitable for | low-frequency strategies | HFT and high-frequency |
How We Build a Fault-Tolerant System
We implement a circuit breaker to protect against overloads. If the error rate exceeds a threshold, the API temporarily rejects requests, allowing the backend to recover. Monitoring via Prometheus and alerts for 429, latency, and drop rate. History of responses with idempotency key is stored in Redis with a 24-hour TTL.
Management Endpoints
Basic commands for bot control
-
GET /api/v1/bot/status— status, uptime, mode -
POST /api/v1/bot/start— start -
POST /api/v1/bot/stop— stop while preserving positions -
POST /api/v1/bot/pause— pause new trades -
POST /api/v1/bot/resume— resume
Portfolio management
-
GET /api/v1/portfolio— balance, P&L, metrics -
GET /api/v1/positions— open positions -
POST /api/v1/positions/{id}/close— close a position -
POST /api/v1/positions/close-all?confirm=true— emergency close
Full list of endpoints is in the OpenAPI 3.0 documentation.
Rate Limiting and Timeout Handling
Rate limiting protects against accidental spikes and abuse. Example response headers:
X-RateLimit-Limit: 100 X-RateLimit-Remaining: 87 X-RateLimit-Reset: 1704067260 Limits are differentiated: status reads — 300 req/min, trading operations — 30 req/min. On exceeding — 429 Too Many Requests with a Retry-After header. We configure these limits according to your strategy and volumes. Downtime reduction reaches 99.9%.
Authentication: API Keys + HMAC
The standard for trading APIs is request signing with HMAC-SHA256. The key is never transmitted in the request, only the signature. IP whitelisting and scoped keys:
| Scope | Allowed operations |
|---|---|
| read | GET endpoints |
| trading | read + position management |
| admin | trading + configuration, start/stop |
Webhooks for Events
We use a push model for event notifications. Register an endpoint with a URL and event types (trade.opened, position.closed, bot.error). When the event occurs, the bot makes a POST with the payload.
Reliable delivery: exponential backoff, signature verification, log of all attempts. Integration with external systems or orchestration of multiple bots is a standard scenario. Get a consultation on configuring webhook integration.
Work Process
- Analytics — studying strategies, volumes, infrastructure.
- Design — agreeing on endpoint schema and security model.
- Implementation — writing code in TypeScript/Go with viem and ethers.js.
- Testing — unit and integration tests with an exchange simulator, load testing up to 10,000 req/min.
- Deployment — CI/CD, monitoring (alerts for 429, latency).
Timelines: from 2 to 4 weeks depending on complexity. We will evaluate the project after a brief—contact us for a consultation.
What's Included
- REST API with OpenAPI 3.0 documentation
- Source code in a private repository
- Integration with exchanges of your choice
- Webhook endpoint for events
- Load testing (up to N requests/min)
- Deployment instructions
- 1 month of support after release
Order the development of a custom API—let's discuss the task.