CoinbaseCopy Anchor Link

Coinbase was founded in 2012 and is one of the largest US-regulated cryptocurrency exchanges. Its Advanced Trade API offers spot, perpetual swap, and dated futures trading. This adapter supports live market data ingest and order execution on both spot (Cash) and CFM derivatives (Margin) accounts through a shared execution client, with the account type selected by the factory (see Execution scope).

OverviewCopy Anchor Link

The Coinbase adapter is implemented in Rust and exposed to Python through configurations, factories, enums, and constants.

Components:

• CoinbaseRawHttpClient: Low-level REST client owning transport, JWT signing, and rate limits.
• CoinbaseHttpClient: Domain REST client parsing venue responses into Nautilus types.
• CoinbaseWebSocketClient: Low-level WebSocket connectivity with JWT subscribe auth.
• CoinbaseInstrumentProvider: Instrument parsing and loading.
• CoinbaseDataClient: Market data feed manager.
• CoinbaseDataClientFactory: Data client factory.
• CoinbaseExecutionClient: Execution client (spot or CFM derivatives; REST orders + WS streams).
• CoinbaseExecutionClientFactory: Execution client factory. Spot vs CFM derivatives is selected by account_type on the config.

Python surface available from nautilus_trader.adapters.coinbase:

• CoinbaseDataClientConfig, CoinbaseExecutionClientConfig
• CoinbaseDataClientFactory, CoinbaseExecutionClientFactory
• CoinbaseEnvironment, CoinbaseMarginType
• COINBASE, COINBASE_CLIENT_ID, and COINBASE_VENUE

ExamplesCopy Anchor Link

• Python examples
• Rust examples

Coinbase documentationCopy Anchor Link

Coinbase provides documentation for the Advanced Trade API:

• REST API reference
• Order management guide
• WebSocket channels
• API key authentication
• Rate limiting

Read the Coinbase documentation with this NautilusTrader integration guide.

ProductsCopy Anchor Link

A product is an umbrella term for a group of related instrument types.

The following product types are supported:

SymbologyCopy Anchor Link

Coinbase uses the venue's native product_id field directly as the Nautilus symbol. The instrument ID is {product_id}.COINBASE.

The -CDE suffix denotes the Coinbase Derivatives Exchange (FCM venue). Perpetuals carry an exchange-assigned far-future expiry (e.g. 20DEC30) but are classified as CryptoPerpetual based on the presence of an ongoing funding rate. Dated futures are classified as CryptoFuture.

The adapter resolves the product type structurally from API metadata (future_product_details.contract_expiry_type and, when that is EXPIRING, the presence of a non-empty future_product_details.funding_rate as a perpetual-only structural signal). The fallback heuristic checks display_name for PERP or Perpetual substrings.

Examples of full Nautilus instrument IDs:

• BTC-USD.COINBASE (spot Bitcoin/USD).
• ETH-USDC.COINBASE (spot Ether/USDC).
• BIP-20DEC30-CDE.COINBASE (BTC perpetual swap).
• BIT-24APR26-CDE.COINBASE (BTC dated future, Apr 2026).

Aliased products (USDC and USD)Copy Anchor Link

Coinbase consolidates USDC- and USD-quoted versions of the same pair into one matching-engine book. GET /products exposes this relationship through alias and alias_to:

BTC-USD :  alias=""        alias_to=["BTC-USDC"]   # canonical
BTC-USDC:  alias="BTC-USD" alias_to=[]             # alias of BTC-USD

When a caller subscribes or submits using the alias side, the venue rewrites the request to the canonical id on the wire. The adapter records the product_id -> alias map at instrument bootstrap and handles the rewrite transparently on both sides:

• Data subscriptions go out on the canonical id. The data WebSocket client holds the reverse mapping and re-keys inbound messages back to the caller-supplied id before parsing.
• Orders are submitted on the caller's product_id. Unfilled working updates restore that ID from submit-time metadata. Updates with fills and terminal reports use the product IDs from REST order details and fill history. Fill commissions use that instrument's quote currency. An alias-side order remains associated with its submitted instrument.

A strategy holding only USDC can therefore trade BTC-USDC.COINBASE end to end without referencing the canonical BTC-USD. Settlement currency is determined by the submitted product_id, so an order placed on BTC-USDC.COINBASE always debits or credits the USDC wallet.

EnvironmentsCopy Anchor Link

Coinbase provides two trading environments. Configure the appropriate environment using the environment field in your client configuration.

Live (production)Copy Anchor Link

The default environment for live trading with real funds.

config = CoinbaseExecutionClientConfig(
    api_key="YOUR_API_KEY",
    api_secret="YOUR_API_SECRET",
    # environment=CoinbaseEnvironment.LIVE (default)
)

Environment variables: COINBASE_API_KEY, COINBASE_API_SECRET.

SandboxCopy Anchor Link

A static-mock test environment for integration plumbing, per the Sandbox docs.

config = CoinbaseExecutionClientConfig(
    api_key="ANY_NON_EMPTY_STRING",  # required by the adapter constructor
    api_secret="ANY_NON_EMPTY_STRING",
    environment=CoinbaseEnvironment.SANDBOX,
)

The sandbox venue does not enforce authentication. But CoinbaseExecutionClient::new requires both fields (or the matching environment variables) for construction.

AuthenticationCopy Anchor Link

Coinbase Advanced Trade uses ES256 JWT authentication. Each REST request and each WebSocket subscription generates a short-lived JWT signed with your EC private key. The adapter resolves credentials from environment variables or from the config fields.

Creating an API keyCopy Anchor Link

Coinbase has several key types. The adapter requires a Coinbase App Secret API key with the ECDSA signature algorithm (not Ed25519).

For full details see the Coinbase API key authentication guide.

Environment variablesCopy Anchor Link

Example:

export COINBASE_API_KEY="organizations/abc-123/apiKeys/def-456"
export COINBASE_API_SECRET="$(cat ~/path/to/cdp_api_key.pem)"

JWT lifetimeCopy Anchor Link

Coinbase JWTs expire after 120 seconds. Per the WebSocket overview, a different JWT must be generated for each authenticated WebSocket message (i.e. for each subscribe). The adapter regenerates a fresh JWT for every signed REST request and for every authenticated subscribe message. No manual rotation is required.

PortfoliosCopy Anchor Link

A Coinbase account holds one or more portfolios. Each portfolio has its own wallets (USD, USDC, BTC, etc.), balances, and order scope. Every account has a DEFAULT portfolio. Users can create additional CONSUMER portfolios to segregate strategies, risk, or tax lots.

A CDP API key is bound to a single portfolio at creation time. Every authenticated request (account lookup, order submission, cancel) operates against that portfolio unless a different one is explicitly specified.

Finding your portfolio UUIDsCopy Anchor Link

Run the adapter's authenticated probe binary:

cargo run --bin coinbase-http-private --package nautilus-coinbase

It prints:

• The portfolios visible to your CDP key.
• The account balances in the bound portfolio.
• A few reference REST calls.

Sample output:

Found 1 portfolio(s)
  name=Default type=DEFAULT uuid=ca7244bc-21d1-5e4c-bfe5-80f208ac5723 deleted=false
Account has 3 balance(s)
  USDC total=100.00000000 USDC free=100.00000000 USDC locked=0.00000000 USDC
  AUD total=0.00 AUD free=0.00 AUD locked=0.00 AUD
  BTC total=0.00000000 BTC free=0.00000000 BTC locked=0.00000000 BTC

Equivalent curl (you have to sign your own ES256 JWT with your CDP PEM key first):

curl -H "Authorization: Bearer $JWT" \
  https://api.coinbase.com/api/v3/brokerage/portfolios

When retail_portfolio_id is requiredCopy Anchor Link

Coinbase's POST /orders endpoint routes to the key's bound portfolio by default, so a single-portfolio account does not need to set this field. Set it on CoinbaseExecutionClientConfig when either is true:

• The account holds multiple portfolios and you want to trade against one that is not the key's default.
• The venue rejects orders with account is not available and the wallet diagnosis below has been ruled out.

Creating a new portfolioCopy Anchor Link

Most users do not need to create a portfolio. The account's default works without additional setup. Create one on coinbase.com/portfolios only if you want to:

• Segregate API-driven trading from manual retail activity.
• Isolate risk or P&L between strategies.
• Work around a restricted default (e.g. a Vault).

After creating a portfolio, fund it (transfer from the default portfolio's wallet on coinbase.com) before sending any orders, otherwise the venue returns account is not available for the quote currency.

Troubleshooting account is not availableCopy Anchor Link

The venue returns this error for several distinct reasons. Diagnose by running the probe binary above and inspecting the portfolio wallet list.

Market dataCopy Anchor Link

The data client serves everything except derivatives index and funding data from WebSocket channels. Coinbase Advanced Trade does not publish index prices or funding rates on any WebSocket channel, so those two streams are sourced from REST polling instead.

A heartbeats subscription is always sent on connect and replayed on every reconnect. It satisfies the venue's five-second subscribe deadline and keeps the connection alive when the subscribed product topics are quiet.

BarsCopy Anchor Link

Historical bar requests accept EXTERNAL aggregation at the granularities the adapter maps: 1m, 5m, 15m, 30m, 1h, 2h, 6h, and 1d. Any other step or aggregation is rejected. Coinbase's /products/{id}/candles endpoint also accepts FOUR_HOUR, which the adapter does not currently map.

Live bar subscriptions are different: the WebSocket candles channel takes no granularity parameter and publishes five-minute buckets only. The adapter stamps each received candle with the BarType registered for that product. Thus, other subscription specifications yield five-minute bars labeled with the requested type. Request a 5-MINUTE-LAST-EXTERNAL bar type for live subscriptions, and use historical requests for the other granularities.

Funding ratesCopy Anchor Link

The adapter polls the REST /products/{id} endpoint at derivatives_poll_interval_secs (default 15 s) and emits a FundingRateUpdate from the FCM future_product_details payload when funding_rate is present. The funding interval is parsed from the funding_interval field (typically "3600s", hourly funding) and the next funding timestamp from funding_time. Coinbase Advanced Trade does not publish funding_rate on the WebSocket ticker channel, so REST polling is the only live source.

Historical funding rate requests are not implemented.

Instrument statusCopy Anchor Link

subscribe_instrument_status joins the Coinbase WebSocket status channel on first subscription (the venue publishes one status feed for all products). It filters incoming events to the subscribed instruments. It emits InstrumentStatus events with these actions:

• MarketStatusAction::Trading for online.
• Halt for offline.
• Close for delisted.

Products reporting an unset status (futures) or a status the adapter does not model carry no information for the data engine and are skipped. The channel subscription is dropped when the last instrument unsubscribes.

Orders capabilityCopy Anchor Link

The tables below describe the Coinbase venue order surface. The shipped CoinbaseExecutionClient handles spot or CFM derivatives based on the configured account_type. Coinbase order capabilities differ between Spot and Derivatives (perpetuals and dated futures share the same FCM order surface).

Execution scopeCopy Anchor Link

CoinbaseExecutionClientFactory produces a single CoinbaseExecutionClient type. The product family is selected by the account_type field on CoinbaseExecutionClientConfig:

Other account types are rejected at factory creation. OMS is always Netting because the venue does not expose hedge mode.

To prevent cross-account bleed-through:

1. Connect-time instrument bootstrap is limited to the configured product family. The other family's products never enter the in-process cache.
2. submit_order denies any order whose instrument is outside that cache.
3. generate_order_status_report(s) and generate_fill_reports post-filter their output through the same cache. Thus, a single client never exposes the other scope's reports, even for an account with both spot and derivative activity.

Run one execution client per scope. For both spot and CFM activity on the same trader, create two clients with distinct account_type values and account_ids. Configure an explicit COINBASE venue route or a default client (see Execution client routing). When submitting orders, pass the intended client_id.

Order typesCopy Anchor Link

The matrix lists order types as exposed through the Nautilus model. The right column shows the corresponding order_configuration keys the adapter emits. Coinbase order types not in this table (TWAP, Bracket, Scaled, SOR LIMIT IOC) are documented under Advanced order features and noted there as Not currently implemented by the adapter.

Execution instructionsCopy Anchor Link

Time in forceCopy Anchor Link

The adapter accepts the values in this matrix. Combinations not listed are rejected at submit time with "Unsupported TIF {tif} for {order_type}".

Advanced order featuresCopy Anchor Link

See the Create Order reference and Edit Order reference for the underlying venue specification.

Position controls (derivatives)Copy Anchor Link

Batch operationsCopy Anchor Link

Order queryingCopy Anchor Link

Spot trading limitationsCopy Anchor Link

• MARKET FOK is not accepted on spot. Coinbase documents market_market_fok as perpetuals-only and rejects it with UNSUPPORTED_ORDER_CONFIGURATION.
• Quote-denominated MARKET orders are supported. LIMIT orders are sized in base units.

Derivatives tradingCopy Anchor Link

Coinbase derivatives trade through the FCM (Futures Commission Merchant) venue. The exec client submits orders through the same POST /orders endpoint used for spot. Per-order leverage and margin_type (CROSS or ISOLATED) defaults come from CoinbaseExecutionClientConfig.default_leverage and default_margin_type. Margin balances update from both the REST cfm/balance_summary endpoint (connect-time snapshot, query_account, and on WebSocket reconnect) and the authenticated futures_balance_summary WebSocket channel. Position reports come from the REST cfm/positions endpoints.

Coinbase's Advanced Trade API does not document a reduce_only field on the create-order schema. The execution client rejects reduce-only orders before transport instead of submitting them without the instruction.

The adapter logs a warning for these conditions:

• A REST order status report describes a forced-close order.
• The CFM balance summary reports a liquidation buffer below 20% of the liquidation threshold.

Coinbase does not flag auto-deleveraging separately from liquidation, so both surface through the same warning. The user channel carries no equivalent warning, so forced closes are visible from reconciliation rather than from the live stream.

Execution client behaviorCopy Anchor Link

This section documents how CoinbaseExecutionClient translates Nautilus order commands and Coinbase venue events into Nautilus execution events.

Order submissionCopy Anchor Link

submit_order builds the Coinbase order_configuration shape directly from Nautilus order fields:

• MARKET IOC and GTC (the Nautilus default) -> market_market_ioc. FOK -> market_market_fok. Day and Gtd are rejected before the HTTP call so callers do not silently receive IOC semantics. A MARKET order built with Gtc executes as IOC at the venue. Strategies that require strict backtest/live parity should construct MarketOrder with Ioc explicitly.
• LIMIT GTC -> limit_limit_gtc, GTD -> limit_limit_gtd (requires expire_time), FOK -> limit_limit_fok.
• STOP_LIMIT GTC -> stop_limit_stop_limit_gtc, GTD -> stop_limit_stop_limit_gtd. Stop direction is derived from the order side (Buy -> STOP_DIRECTION_STOP_UP, Sell -> STOP_DIRECTION_STOP_DOWN).
• STOP_MARKET, MARKET_IF_TOUCHED, LIMIT_IF_TOUCHED, and trailing-stop variants are not supported by Coinbase. They surface as OrderRejected carrying the build_order_configuration error from the spawned submit task (the order is emitted as OrderSubmitted first).

On a successful HTTP create, an OrderAccepted is emitted carrying the venue order ID returned in success_response.order_id. On a success=false response, OrderRejected is emitted with the formatted venue failure reason. Because any submit attempt may have reached Coinbase, a transport error, timeout, rate-limit response, decode failure, or HTTP 5xx does not prove rejection. The adapter leaves the order in flight and retains its submit metadata until the user channel or reconciliation resolves it.

Order modificationCopy Anchor Link

modify_order posts to /orders/edit with the typed EditOrderRequest. Coinbase supports edits on open GTC variants only, and rejects edits on futures-venue orders with CANNOT_EDIT_FUTURES_ORDER, so modification is effectively spot-only. Other order types must use cancel-replace.

Coinbase's /orders/edit requires both price and size even when only one changes. It reads an omitted size as 0 and rejects it with INVALID_EDITED_SIZE or CANNOT_EDIT_TO_BELOW_FILLED_SIZE. The exec client auto-fills missing fields from the cached order, so strategies can call modify_order(price=X) without repeating the current quantity. Values from the ModifyOrder command win. Otherwise the cached order's current price and quantity are used.

Venue edit failures emit OrderModifyRejected with the typed EditOrderResponse reason (preferring edit_failure_reason, falling back to preview_failure_reason). HTTP failures with unknown venue outcome leave the order in PENDING_UPDATE until an update, query result, or reconciliation resolves it.

CancellationCopy Anchor Link

• cancel_order posts a single-id batch_cancel. An explicit per-order venue failure surfaces as OrderCancelRejected. A whole-request transport failure with unknown venue outcome leaves the order in PENDING_CANCEL for reconciliation.
• cancel_all_orders lists open orders via REST without the OPEN-only filter (because Coinbase's OPEN filter excludes PENDING and QUEUED orders that are still cancelable), filters locally to {Accepted, Triggered, PendingUpdate, PartiallyFilled} and the requested side, then chunks batch_cancel calls in groups of 100. Per-order venue failures emit OrderCancelRejected. Whole-request failures with unknown venue outcome leave affected orders pending reconciliation.
• batch_cancel_orders splits repeated venue order IDs into separate requests so each reply identifies one command UUID. Other chunks contain up to 100 orders. It surfaces explicit per-order venue failures as OrderCancelRejected. Transport failures with unknown venue outcome leave affected orders pending reconciliation.

User WebSocket channelCopy Anchor Link

CoinbaseExecutionClient subscribes to the user channel with no product_ids filter and a fresh JWT. For updates with nonzero cumulative filled quantity and for terminal updates, it fetches REST order details. For orders with reported or discovered fills, it also fetches the complete per-order fill history. Recovery retains discovered trade IDs across failed reads and empty scans. It waits until REST reaches every pending user-channel target, includes every discovered trade, and each order's unique fill quantities sum exactly to its REST filled quantity. For an order not yet tracked from the Nautilus cache, recovery publishes an accepted (or rejected) order status with zero filled quantity before the real fill reports, then its final REST status after those fills. The preceding status establishes order context without inferring fills. Recovery publishes individual fills across orders in trade-time order. Known orders use native cancellation, expiry, and rejection events once the cache contains the recovered filled quantity. Known submitted orders receive native acceptance from user-channel or REST order evidence without waiting for fill history.

Fills retain Coinbase's trade_id, per-trade price, commission, liquidity side, and trade timestamp. Quote-sized fills are converted to base quantity using the fill price. Terminal reports use the original REST order quantity even when the user channel zeroes leaves_quantity.

Live fill delivery waits for REST visibility. Incomplete or failed reads hold the whole recovery batch pending for retry while connected. Polling continues even after an empty scan, so delayed fills from closed orders and pending queries do not require another WebSocket update. Polls have no attempt limit and run at intervals of retry_delay_max_ms (at least 1 ms); each HTTP request uses the existing retry policy. Recovery publication is serialized across queries and user updates. A changed target or a REST state older than a previously published recovery leaves the batch pending. A slow, failing, or incomplete read delays all processing on the user channel, including acceptances, amendments, reconnect account refreshes, and futures balance updates. Those messages queue until the read completes.

The user channel omits price, stop_price, trigger_type, and post_only. The client fills these fields from submit-time metadata for its own orders and from REST enrichment for external orders. For orders submitted by this client, non-snapshot user updates emit native amendments using the reported quantity and captured submission or modification metadata. User-channel snapshots and fill recovery preserve cached limit and trigger prices. Recovery updates cached base quantity before fills when complete fill coverage exceeds it or a terminal Filled report establishes the final total. Quote-sized market orders wait for terminal REST totals, then normalize their quantity to base units before publishing fills. Order statuses PENDING, QUEUED, and OPEN map to OrderStatus::Accepted.

A submit_order rejection carrying INVALID_LIMIT_PRICE_POST_ONLY (or the preview/new-order equivalent) is emitted with due_post_only = true so strategies can react to post-only crossings (typically by re-quoting against the new TOB).

On reconnect, the client refreshes account state. Fill discovery runs throughout the connection from the venue timestamp recorded before its first connection, with no fixed lookback window. Each scan also pages through the account's full REST order history, then filters for filled orders whose last fill is at or after that timestamp. A closed order can therefore hold recovery pending before its fills appear in the trade history. Each poll reprocesses matching orders, including already reconciled orders and orders that fill and close while disconnected. Each target requires a REST order read and its complete fill history. REST usage depends on the account's full order history and grows with activity during the client instance; see Rate limiting. Pending targets and published recovery state survive disconnects of the same client instance.

Fill deduplicationCopy Anchor Link

Live updates, startup reconciliation, and reconnect recovery use the same venue trade IDs. The execution engine uses those identities for fill deduplication. Recovery deduplicates each order's response and sorts fills across the complete batch by trade timestamp before publication. This preserves individual partial fills when a user-channel update combines executions or several orders fill during a disconnect. Live recovery publishes each fill separately after order context is established. Known-order recovery uses fill reports and native lifecycle events without replaying REST price or trigger terms or treating a lower cumulative fill total as a fill correction.

Position reconciliationCopy Anchor Link

For Cash (spot) accounts the client returns no position reports. Periodic position checks retain cached spot positions when reports omit them. For Margin accounts position reports come from the REST cfm/positions (list) and cfm/positions/{product_id} (single) endpoints. Periodic position checks treat an absent report as flat only for instruments in the Margin client's bootstrapped futures scope.

Open orders and historical fills are reconciled from REST via generate_order_status_report(s) and generate_fill_reports on connect and on the standard reconciliation interval set by LiveExecutionEngineConfig.

Rate limitingCopy Anchor Link

Coinbase publishes the following limits for the Advanced Trade APIs:

When the REST limit is exceeded, Coinbase returns HTTP 429 with this body:

{
  "errors": [
    {
      "id": "rate_limit_exceeded",
      "message": "Too many requests"
    }
  ]
}

Each recovery poll pages through fills since the first connection and the account's full order history. It also reads each matching filled order and its complete fill history. This costs at least two discovery requests plus two requests per filled order, before pagination and HTTP retries. The default five-second interval corresponds to 720 polls per hour before delays. Raise retry_delay_max_ms to reduce this REST usage; targeted order queries and user updates can trigger additional scans.

Against the general Coinbase App quota above, six filled orders yield at least 10,080 requests per hour at the default interval, before delays or other traffic. The set of scanned orders grows for the lifetime of the client instance. A longer interval reduces the rate but does not bound that history, and it also increases the maximum HTTP retry delay.

The adapter also throttles all REST traffic client-side at 30 requests per second. It limits subscribe and unsubscribe messages to 8 per second. Thus, it shapes bursts before they reach the venue.

Reconnect and resubscribeCopy Anchor Link

The WebSocket client uses exponential backoff with a base of 250ms and a cap of 30s on reconnect. Retained subscriptions are replayed automatically after the handshake completes. Coinbase disconnects a client that sends no subscribe message within 5 seconds of connecting. Thus, replay always includes heartbeats. The client marks this topic before the first replay and keeps it for its lifetime.

For authenticated channels (user, and futures_balance_summary on Margin clients), the adapter generates a fresh JWT for every subscribe message, as Coinbase requires a different JWT for each authenticated WebSocket message. If credentials are absent or JWT construction fails, the adapter skips topics that require authentication instead of sending them unsigned. The failure appears as an error on the client's message stream. Once a subscription is accepted the data flow continues for the lifetime of the WebSocket connection without further authentication.

If a prior user WebSocket is still active or reconnecting when the execution client connects again, it closes that connection. It rebuilds the inner client instead of reusing the existing state machine. This guarantees a fresh command channel, output channel, and shutdown signal even when the previous session's Disconnect command lost a race with the shutdown signal.

ConfigurationCopy Anchor Link

Data client configuration optionsCopy Anchor Link

Execution client configuration optionsCopy Anchor Link

Configurations are constructed from the adapter's public Python module:

from nautilus_trader.adapters.coinbase import CoinbaseDataClientConfig
from nautilus_trader.adapters.coinbase import CoinbaseEnvironment
from nautilus_trader.adapters.coinbase import CoinbaseExecutionClientConfig
from nautilus_trader.model import AccountId

data_config = CoinbaseDataClientConfig(
    api_key="YOUR_COINBASE_API_KEY",
    api_secret="YOUR_COINBASE_API_SECRET",
    environment=CoinbaseEnvironment.LIVE,
)

exec_config = CoinbaseExecutionClientConfig(
    account_id=AccountId("COINBASE-001"),
    api_key="YOUR_COINBASE_API_KEY",
    api_secret="YOUR_COINBASE_API_SECRET",
    environment=CoinbaseEnvironment.LIVE,
)

The current Python examples show how to pair these configs with CoinbaseDataClientFactory and CoinbaseExecutionClientFactory in LiveNode.builder(...).

Known limitationsCopy Anchor Link

Venue-sideCopy Anchor Link

• Order modification is restricted to open GTC orders and is rejected on futures-venue orders with CANNOT_EDIT_FUTURES_ORDER. Everything else must use cancel-replace.
• OCO orders are not exposed as a distinct order type.
• Trailing stop, MARKET_IF_TOUCHED, LIMIT_IF_TOUCHED, and iceberg orders are not supported by Coinbase.
• Mark prices are not published on REST or WebSocket, so mark price subscriptions are rejected.
• Batch submit and batch modify are not available. Only batch cancel is.
• Sandbox is a static-mock environment (Accounts and Orders endpoints only, pre-defined responses, no real market data).
• The user-channel WebSocket reports cumulative per-order state without per-trade IDs. Live fill delivery therefore requires REST order and fill reads.

Adapter-sideCopy Anchor Link

• One product family per client. Submission, modification, cancellation, and report generation are filtered to the configured product family (spot under AccountType::Cash; perp + dated futures under AccountType::Margin). Orders whose instrument falls outside the bootstrapped cache are denied. See Execution scope.
• Position reports are always empty for Cash accounts. Coinbase spot has no positions. Derivatives (CFM) position reports come from cfm/positions and appear only on Margin clients.
• User-channel updates omit price, stop_price, trigger_type, and post_only. The client retains submission and modification metadata for its own orders. It enriches external orders with /orders/historical/{venue_order_id} when an unfilled, non-terminal update needs a missing price. It retains that enrichment until a closed REST status is published. The lookup adds latency. The metadata supplies external order status reports; known orders use native lifecycle events. See User WebSocket channel for amendments and fill recovery.
• Cancel-all and batch-cancel REST list failures are logged only. If the list-open-orders REST call fails, no per-order OrderCancelRejected is emitted. Orders remain in PendingCancel until the next reconciliation recovers them. Mirrors the Bybit adapter pattern.
• Newly listed products require a reconnect to be tradeable. The instrument cache is populated on connect. Products listed after that are not in the cache and submit_order will deny them.
• MARKET orders default to IOC. A MarketOrder constructed with the Nautilus default TimeInForce::Gtc is mapped to market_market_ioc at the venue. Explicit TimeInForce::Ioc is honored. TimeInForce::Fok routes to market_market_fok, which Coinbase documents as perpetuals-only and rejects at runtime on spot with UNSUPPORTED_ORDER_CONFIGURATION. Day and Gtd are rejected at submit time.
• Historical funding rate requests are not implemented. Funding rates are available only as live updates from the derivatives REST poll.
• Live bar subscriptions ignore the requested granularity. The venue's candles channel publishes five-minute buckets and accepts no granularity parameter, and subscribe_bars does not reject other bar specifications. A subscription at any other step receives five-minute bars stamped with the requested BarType. See Bars.

Diagnostic binariesCopy Anchor Link

Three binaries assist with connectivity checks, live verification, and account hygiene:

• coinbase-http-public requests spot instruments, a product book, and recent trades without credentials. Use it to confirm connectivity before configuring an API key.
• coinbase-http-private lists portfolios, prints wallet balances, runs /orders/preview for BTC-USD and BTC-USDC, and surfaces per-product gating flags. Recommended first stop when bringing a new account online.
• coinbase-cancel-all-open cancels every open order on the authenticated CDP key. Useful between test runs to clear resting orders.

The two authenticated binaries read COINBASE_API_KEY and COINBASE_API_SECRET from the environment.

ContributingCopy Anchor Link