Isolated deployment · Binance adapter 5.33.2
Binance market-order integration
Live trading. Order creation is enabled with dedicated Minatech Binance credentials. Authenticated submissions place real orders and spend funds.
Base URL: https://minatech.cross-otc.com. This service places real Binance Spot MARKET orders. There is no sandbox flag. A market order executes at available liquidity, not a guaranteed quote.
Submit each order only once. POST is not idempotent. Reusing a reference after an order fills can create another trade. A timeout, 202, 404, 429, 500, 502 or 503 must never automatically cause another POST or a replacement reference.
Authentication
Send Authorization: Bearer <token> on both API requests. Obtain a short-lived service JWT from the operator. JWTs use HS256 and must include role: "system" and a future Unix-seconds exp. Keep tokens on your server, not in browser code. Binance keys and the JWT signing secret are never public and must not be embedded in an integration.
1. Create a market order
POST /api/v1/binance-adapter/market-order, with Content-Type: application/json.
{"referenceId":"mtech-20261009-0001","symbol":"btc-brl","side":"bid","amount":{"value":0.001,"unit":"base"}}
| Field | Contract |
|---|
| referenceId | A unique identifier you persist before submitting: 1–34 ASCII letters, digits, underscores or hyphens. A standard 36-character UUID is too long; use a 32-character hex ID. |
| symbol | One of btc-brl, eth-brl, usdc-brl, usdt-brl. Persist the symbol together with the reference. |
| side | bid means BUY; ask means SELL. |
| amount.value | Positive decimal amount. Base precision: BTC 5, ETH 4, USDC/USDT 1; quote precision: 4. Values are truncated, never rounded up. Binance also enforces lot size, minimum notional and available balance. |
| amount.unit | base: quantity of the asset, e.g. 0.001 BTC. quote: quote-currency amount, e.g. BRL to spend on a BUY. No price field is accepted or required. |
curl --request POST 'https://minatech.cross-otc.com/api/v1/binance-adapter/market-order' \
--header "Authorization: Bearer ${TOKEN}" --header 'Content-Type: application/json' \
--data '{"referenceId":"mtech-20261009-0001","symbol":"btc-brl","side":"bid","amount":{"value":0.001,"unit":"base"}}'
This example places a real order with a valid token.
2. Poll its status
GET /api/v1/binance-adapter/market-order/{referenceId}?symbol={originalSymbol}. Both identifiers are required. Each GET queries Binance; it works after an adapter restart. Begin at a 2-second interval, then back off with jitter on errors and rate limits. There is no callback, WebSocket or RabbitMQ integration required from you.
curl 'https://minatech.cross-otc.com/api/v1/binance-adapter/market-order/mtech-20261009-0001?symbol=btc-brl' \
--header "Authorization: Bearer ${TOKEN}"
A typical successful response:
{"success":true,"message":"Success","data":{"orderId":"28457","referenceId":"mtech-20261009-0001","symbol":"btc-brl","side":"bid","status":"filled","executedQty":0.001,"cumulativeQuoteQty":450,"avgPrice":450000,"commissions":[{"asset":"BTC","amount":0.000001}],"fills":[{"tradeId":1,"price":450000,"qty":0.001,"commission":0.000001,"commissionAsset":"BTC"}]}}
Amounts are JSON numbers; use a decimal-aware parser/library for financial calculations. avgPrice is rounded down to the market's configured price precision; fills contain individual execution prices. Fees can be charged in different assets and are grouped in commissions.
Completion and failures
| Response / status | Your action |
|---|
| 200 / success=true | The API lookup or submission succeeded. This alone does not mean the order filled; inspect data.status. |
| filled | Full execution confirmed. Persist the result and stop normal polling. |
| new, pendingNew, partiallyFilled, unknown | Continue status checks. Never re-submit to resolve uncertainty. |
| canceled, expired, expiredInMatch, rejected | Final, but not fully successful. Check executedQty and fills: canceled/expired orders can have partial execution. |
| 202 from POST | {"success":true,"message":"Outcome unknown","data":{"referenceId":"mtech-20261009-0001","status":"unknown"}}. Poll GET; do not POST again. |
| 400 | Invalid input, missing symbol, or amount below precision. Fix validation before a new submission. |
| 401 / 403 | Missing/expired token or wrong role. Obtain a valid service token. |
| 404 | Unknown/configuration-missing symbol or no market order found for that reference and symbol. Rejected submissions may have no Binance record. History retention also limits old queries. Do not treat 404 after uncertainty as permission to submit again. |
| 422 from POST | Binance rejected the order. data.code and data.message describe the rejection, e.g. insufficient balance. |
| 429 / 500 / 502 / 503 | Back off. After a POST failure, reconcile with GET; never automatically repeat POST. GET uses Binance's original single-page trade lookup (default 500 fills); orders beyond this limit can keep returning 503 rather than incomplete fees. |
Integration checklist
- Store referenceId, symbol and request details atomically before sending POST; prevent duplicate submissions in your own system.
- Store the returned orderId and result. Only mark a trade successful when status is filled.
- Poll GET until a final result, keeping unresolved outcomes for reconciliation or operator review.
- Handle fees in their reported assets and use executedQty, not the requested amount, for settlement.
- Use HTTPS and protect your bearer token. Neither the docs nor the ingress provides a token-minting endpoint.
Only the two API operations above are exposed. Health, readiness, Swagger, order books, quotes, open-order listing and order cancellation are private. This static page is the public integration documentation.