Choose the Target API
Replacing a Coinbase Pro base URL with an Advanced Trade URL leaves the old authentication and request model in place. The next private request still carries fields intended for another API.
The coinbase-api package exposes several Coinbase API families. CBAdvancedTradeClient is the client used here. CBExchangeClient addresses Coinbase Exchange; it is not an alias that converts a Pro integration into Advanced Trade.
Confirm the account and product against the current Advanced Trade documentation before changing code. Account eligibility and available products must match the application rather than a generic migration checklist.
| Old integration assumption | Advanced Trade migration work |
|---|---|
| Exchange-style secret and passphrase | Configure credentials accepted by the Advanced Trade client. |
| Old REST method and response | Use the matching Advanced Trade method and inspect its result. |
| A generic order body | Build the documented order_configuration for the intended order type. |
| Existing private-feed parser | Implement the target API's user-event envelope and lifecycle. |
| Existing account identifiers | Confirm the account and portfolio scope visible to the new key. |
The Coinbase SDK tutorial documents the constructor and supported credential formats. Configure the client with that signing material instead of copying the old HMAC signer into the application.
Establish a Read Path
First check a public method through the new client:
advanced-trade-public.mjs
import { CBAdvancedTradeClient } from 'coinbase-api';
const client = new CBAdvancedTradeClient();
console.log(await client.getPublicProduct({ product_id: 'BTC-USD' }));
Then check a private account read with the intended credentials. Compare the returned identifiers and fields with the values consumed by the application. A successful public call does not establish private permissions.
Keep the old and new responses as separate fixtures. Reusing the old response type can conceal a missing field until an accounting or sizing operation reads it.
Rebuild Order and Event Handling
Map client order IDs, native order IDs, quantities, and order configuration explicitly. Submit only through the target API's supported order method; a user-stream subscription is an event source, not an order-placement call.
The Advanced Trade WebSocket overview separates market data from user order data. The focused consumer article covers that distinction without importing unrelated exchange examples.
Before switching a live workflow, establish which process owns existing open orders and unresolved submissions. Restarting on a new client must not resend an old intent whose outcome is unknown. Retain historical identifiers for reconciliation even if new requests use a different shape.
Related articles
Continue from here