GuidesAPI Reference
DocumentationLog In


FIX (Financial Information eXchange) is a standard protocol which can be used to enter orders, submit cancel requests, and receive fills. Users of the FIX API typically have existing software using FIX for order management. Users who are not familiar with FIX should first consider using the REST API.


FIX API Endpoint URL


Presently, every connection establishes a new session and a new set of session sequence numbers.


Before logging onto a FIX session, clients must establish a secure connection to the FIX gateway ( If your FIX implementation does not support establishing a TCP SSL connection natively, you must setup a local proxy such as stunnel to establish a secure connection to the FIX gateway. See the SSL Tunnels section for more details and examples.


Sessions are forcibly logged out every day between 5pm ET and 5:05pm ET for a maintenance window. All users are required to restart their sessions during this time and reset sequence numbers to 0.

Rate Limiting

Requests are limited to 50 calls per second/FIX session. We allow up to 7 sessions/portfolio.


The baseline specification for this API is FIX 4.2. Below, we've noted the places in which the FIX API for Coinbase Prime extends (or clarifies) the FIX spec. For example, there are custom tags with a four-digit number range, as allowed by the standard, which are unique to Prime.

A standard header must be present at the start of every message in both directions. You should configure your sessions to use the service account ID associated with the API key as your SenderCompID and the string "COIN" as the TargetCompID. This is typically accomplished via your FIX client's configuration file.

8BeginStringMust be FIX.4.2
49SenderCompIDService Account ID (on messages from the client)
56TargetCompIDMust be COIN (on messages from the client)

Logon (A)

// create a new Logon message
var logon = new Msgs.Logon();
logon.SendingTime = new Date();
logon.passphrase = '...';

var presign = [

// add the presign string to the RawData field of the Logon message
logon.RawData = sign(presign, secret);

// send the logon message to the server

function sign(what, secret) {
 var key = Buffer(secret, 'base64');
 var hmac = crypto.createHmac('sha256', key);
 return hmac.update(what).digest('base64');

Sent by the client to initiate a session, and by the server as an acknowledgement. Only one session may exist per API key; sending a Logon message within an established session, or while the first session is still running, results in an error.

1AccountPortfolio ID associated with this API key
96RawDataClient message signature (see below)
554PasswordClient API passphrase
9407Access KeyClient API key

The Logon message sent by the client must be signed for security. The prehash string is the following fields joined by the empty string:

{timestamp}, "A", seqNum, apiKey, targetComp, passphrase.

There is no trailing separator. The RawData field should be a base64 encoding of the HMAC signature.

A single API key must not be used in multiple connections at the same time. To establish multiple FIX connections, generate a new API key for each one. All messages must have a SendingTime value within 5 seconds of server time in UTC or they are rejected.

New Order Single (D)

Sent by the client to enter an order. Each profile can place a maximum of 500 open orders on a product. Once reached, the profile cannot place any new orders until the total number of open orders is below 500.

Note that not every tag is required for every order -- it depends on the target strategy used. See the table below for more information.

1AccountThe portfolio ID
11ClOrdIDA string selected by client to identify the order
38OrderQtyOrder size in base units (e.g., BTC). Either this or CashOrderQty must be supplied.
40OrderTypeThe order type; see the table below for a list.
44PxIndicates the price of the orderRequired for Limit, TWAP, and SOR orders
54SideMust be 1 to buy or 2 to sell
55SymbolThe product to be traded (e.g., BTC-USD)
59TimeInForceA valid TimeInForce value; see the table below for a list.
126ExpireTimeIndicates the time and date of order expirationRequired for TWAP orders and Limit GTD orders
152CashOrderQtyOrder size in quote units (e.g., USD)Either this or OrderQty must be supplied.
168EffectiveTimeIndicates the start timeRequired for TWAP orders
847TargetStrategyThe target strategy of the order to place; see the table below for a list.

TargetStrategy Values

LLimit orderMust be 2 (Limit)Must be 1 (GTC) or 6 (GTD); 44 (price) must also be provided
MMarket orderMust be 1 (Market)Must be 3 (IOC)
TTWAP orderMust be 2 (Limit)Must be 6 (GTD); 44 (price) must also be provided

OrderType Values


TimeInForce Values

1Good Till Cancel (GTC)
3Immediate or Cancel (IOC)
6Good Till Date (GTD)

Order Cancel Request (F)

Sent by the client to cancel an order.

1AccountThe portfolio ID
11ClOrdIdClOrdId identifying this cancel request
37OrderIDOrderID assigned by Coinbase (available in any of the Execution Report messages)
38OrderQtyAccepted order quantity.You must supply this tag or CashOrderQty (depending on whichever you originally submitted)
41OrigClOrdIDClOrdID from the New Order Single.You must also supply an OrderID.
54SideMust be 1 to buy or 2 to sell (depending on whichever you originally submitted)
55SymbolThe product from the original order (e.g., BTC-USD)
152CashOrderQtyOrder size in quote units (e.g., USD).You must supply this tag or OrderQty (depending on which you submitted)

Order Status Request (H)



   Note: the Tags in this example have been replaced with Name for readability

Sent by the client to obtain information about pending and completed orders.

11ClOrdIDClOrdID of the order to be sent back
37OrderIDOrderID of the order to be sent backRequired
54SideMust be 1 to buy or 2 to sell
55SymbolThe product to be traded (e.g., BTC-USD)


The response to an Order Status Request is an ExecutionReport with ExecType=I. The ExecutionReport contains the ClOrdID if the value is supplied. If the order cannot be found, the ExecutionReport has OrderID=0.

Execution Report (8)

Sent by the server when an order is accepted, rejected, filled, or canceled. Also sent when the user sends an OrderStatusRequest.

6AvgPxThe average price of the order
11ClOrdIDClOrdID of order to be sent back
12CommissionThe Commission incurred for this fill
14CumQtyTotal amount filled on this order
17ExecIDFree format text string
31LastPxPrice of the fill if ExecType indicates a fill, otherwise the order price
32LastQtyAmount currently filled
37OrderIDOrderID from the ExecutionReport
38OrderQtyOrderQty as accepted.You must supply this tag or CashOrderQty (depending on whichever you originally submitted)
39OrdStatusOrder status as of the current message
54SideMust be 1 to buy or 2 to sell
55SymbolSymbol of the original order
103OrdRejReasonInsufficient funds=3, Post-only=8, Unknown error=0
150ExecTypeMust be 1 (Partial fill) for fills, 4 for cancelled, etc.
151LeavesQtyAmount of order to be filled
152CashOrderQtyOrder size in quote units (e.g., USD).You must supply this tag or OrderQty (depending on whichever you originally submitted).

ExecType Values

0New Order
1Partial Fill
6Pending Cancel
APending New
IOrder Status

Order Cancel Reject (9)

Sent by the server when an Order Cancel Request cannot be satisfied, e.g., because the order is already canceled or completely filled.

11ClOrdIDThe same value provided by the original cancel request
37OrderIDThe same value provided by the original cancel request
39OrdStatusThe order status; see the table below for a list.
41OrigClOrdIDThe same value provided by the original cancel request
102CxlRejReasonThe reason the order was rejected
434CxlRejResponseToThe rejection response; see the table below for a list.

OrdStatus Values

1Partially filled
3Done for day
6Pending Cancel (e.g., result of Order Cancel Request <F>)
APending New
DAccepted for bidding
EPending Replace (e.g., result of Order Cancel/Replace Request <G>)

CxlRejResponseTo Values

1Order Cancel Request <F>
2Order Cancel/Replace Request <G>

Reject (3)

Sent by either side upon receipt of a message which cannot be processed, e.g., due to missing fields or an unsupported message type.

45RefSeqNumMsgSeqNum of the rejected incoming message
58TextHuman-readable description of the error (optional)
371RefTagIDTag number of the field which caused the reject (optional)
372RefMsgTypeMsgType of the rejected incoming message
373SessionRejectReasonCode to identify reason for the reject (for session-level rejections only)

SSL Tunnels only accepts TCP connections secured by SSL. If your FIX client library cannot establish an SSL connection natively, you must run a local proxy that establishes a secure connection and allow unencrypted local connections.

Certificate pinning is no longer supported.