How to use Coinbase Advanced Trade API? (Bot development)

Authentication and API Key Setup

1. Navigate to the Coinbase Advanced Trade dashboard and select API Settings under the user menu.

2. Click Create API Key, choose permissions carefully—trade, view, and transfer scopes are essential for bot functionality.

3. Assign a descriptive name, restrict IP addresses if running from a fixed server, and confirm creation.

4. Store the API key, secret, and passphrase in an encrypted environment variable system—never hardcode them into source files.

5. Verify signature generation by constructing a timestamped message with the HTTP method, request path, and body, then signing it with HMAC-SHA256 using the secret.

Order Lifecycle Management

1. Submit limit orders via POST /api/v3/brokerage/orders, specifying product_id (e.g., BTC-USD), side (buy/sell), client_order_id, and size.

2. Use time_in_force values like GTC or GTT to control order duration; bots often rely on GTT with 60-second expiry to avoid stale placements.

3. Cancel pending orders with DELETE /api/v3/brokerage/orders/{order_id} or batch-cancel using DELETE /api/v3/brokerage/orders with filters.

4. Poll GET /api/v3/brokerage/orders/historical with pagination to reconcile executed fills against local state.

5. Parse status fields rigorously: open, done, rejected, and pending require distinct handling paths in execution logic.

Real-Time Market Data Integration

1. Connect to the WebSocket feed at wss://ws-feed.exchange.coinbase.com to subscribe to level2 or ticker channels for real-time bid/ask updates.

2. Send a JSON subscription message containing product_ids, channels, and signature derived from the same credentials used for REST calls.

3. Maintain sequence numbers per channel to detect missed messages—drop and resubscribe if gaps exceed tolerance thresholds.

4. Normalize incoming price and size fields into decimal types before computing spread, depth, or volatility metrics.

5. Use heartbeat messages to validate connection liveness and trigger reconnection logic when intervals exceed 30 seconds.

Error Handling and Rate Limiting

1. Inspect HTTP status codes: 429 signals rate limit exhaustion—respect Retry-After headers and implement exponential backoff.

2. Treat 401 as credential invalidation; rotate keys if repeated without local changes.

3. Map 400 responses to specific validation failures—missing fields, invalid product_id, or malformed timestamps—and log exact error codes like invalid_client_order_id.

4. Capture 500-series errors as transient infrastructure issues; queue failed requests for later replay with idempotency keys.

5. Log all request IDs returned in X-Request-ID headers to correlate logs with Coinbase support tickets during incident resolution.

Frequently Asked Questions

Q: Can I use the same API key for both sandbox and production environments?No. Sandbox and production require separate API key creation—each with its own base URL, credentials, and permission scope.

Q: Does Coinbase Advanced Trade support stop-limit orders via API?Yes. Use the stop and stop_price parameters in the order payload along with order_type set to stop_limit.

Q: How do I verify my bot’s signature matches Coinbase’s expectations?Reproduce the signature step-by-step: concatenate timestamp + method + request_path + body, then compute HMAC-SHA256 with your base64-decoded secret. Compare output to the CB-ACCESS-SIGN header value.

Q: Are there restrictions on how frequently I can poll historical order endpoints?Yes. The /historical endpoint enforces stricter rate limits than standard order endpoints—typically 30 requests per minute per API key.