Advanced Trade Feedback

Hello @jmicko! Thank you for taking an interest in trying out Coinbase APIs. For the details regarding your concern, we will check on this for you with our team. We will get back to you once we have more information. Keep in touch!

2 Likes

Hello @jmicko! Upon further reviewing with the team, unfortunately we currently don’t have a Sandbox (Testing Environment) that will be launched. However, for the upcoming year 2023, we can expect to have a testing environment like Sandbox for our Advance Trade API product.

While we can’t offer any specific timeline for the addition of new features. We would like to recommend that you post this in the Feedback Section of the Forum as most new features and improvements to Coinbase come directly from feedback like yours, so it’s very valuable to us. Thank you!

2 Likes

Why is authorisation required for endpoints that would normally be considered public, such as https://coinbase.com/api/v3/brokerage/products?

It would also be great to have a migration page to show a mapping of the Coinbase Pro API endpoints to the new Advanced Trade API endpoints. And in general, making it clearer in the documentation about what API is being referred to would also be great.

Edit: regarding the authorisation issues, it looks as though the domain requires a www. prefix.

Edit2: Nope, I stand corrected. I could only access the above public endpoint without the security headers because of the cookie header. Using curl or a private browsing window also gave me an unauthorised error. Which brings me back to my first question of: why are public endpoints being guarded like this?

2 Likes

Is there an api to grab the full order book? Also it appears there’s no level3 support in the web socket feed yet?

2 Likes

So far I’m liking the new API, especially the way websockets work. They have been easy to work with while developing a client in rust (will share soon)

In the API docs I see references to protobuf (in the errors). Are there proto files that could be shared to aid in development of clients? Would be great to have request and response structs automatically generated and type safe!

Also are there any plans to support gRPC? Would make integration and client development a lot simpler!

My guess is that it’ll help them to prevent API abuse. This way only coinbase customers can consume server resources. Implementing a client is a little simpler too as there is no need for logic to decide whether a request needs to be signed or not. Sign everything, always, easy

1 Like

Maybe on the API abuse point, though no other exchanges have found the need to do this. Regarding the client simplification, it actually complicates my client because Coinbase now differs from all other exchanges (in that instrument/price data is now private). So now its workflow is different to the other 6 exchanges I’ve currently implemented.

Can the websocket ticker channel include the same datapoints as the REST API? It appears to be missing the best bid, best ask, and the last trade volume.

4 Likes

Hello @channa48! Welcome to the Coinbase Cloud Developer’s Forum!

We understand your scenario of wanting the similar response data with the ticker channel in Coinbase Exchange/Pro Websocket. However, we can see that such is not the case for the ticker channel in Advanced Trade Websocket. Related to this, we recommend you to keep utilizing the Get Market Trades endpoint for now. This endpoint will primarily enable you to get snapshot information, by product ID, about the last trades (ticks), best bid/ask, and 24h volume.

Additionally, we recommend that you post this in the Feedback Section of the Forum as most new features and improvements to Coinbase come directly from feedback like yours, so it’s very valuable to us. Thank you and have a great day!

3 Likes

Another piece of feedback is that the order listing REST API is not so good. We can list every order via /api/v3/brokerage/orders/historical/batch, but we cannot filter by only the open orders (which has got to be the most common case). Instead, we can only filter the order_status by closed statuses.

A better way IMO would be to have an endpoint at /api/v3/brokerage/orders which does a similar thing to the above. Instead though, it could have a main order status field of order_status with values [OPEN, CLOSED, PENDING, UNKNOWN], where there could also then be a order_sub_status field that have values {OPEN => [UNFILLED, PARTIALLY_FILLED], CLOSED => [FILLED, CANCELLED]}

This would allow us to easily see every open order (or a subset on those partially filled, unfilled), along with every closed order (likely filtering by the ones that have been filled).

Of course, we could avoid two levels of statuses as well, though it would just mean having to add the appropriate filters (similar to what there is on the orders/historical/batch endpoint, but actually allowing filtering by currently open orders).

Hello @0C3D! We’re happy that you like the Advance Trade API. Just to make sure, we will check with our engineering team if there are any proto files that can be shared and if there is any plan to support gRPC. We will get back to you as soon as we can. Your patience is appreciated. Thanks!

2 Likes

Hi @tpunt! Thank you for your feedback :smiley:

Yes, this is not something we currently have. Please know that we continue building and improving features that you, our customers will love. Please post this in our Feedback Section too. While we can’t offer any specific timeline we are doing the best we can.

Have a nice day and thank you for your support! :sun_behind_small_cloud: :blue_heart:

2 Likes

Hello @fivetentaylor! Welcome to the Coinbase Cloud Developer’s Forum!

We understand that you’re looking for an Advanced Trade API that will provide you with a full order book and also for a Level 3 Websocket channel similar to what we have on Coinbase Exchange/Pro. Unfortunately, this feature is not yet available in the Advanced Trade. Related to this, we wish to inform you that the team is still hard at work building all the remaining APIs that would best suit our customer’s use cases together with its corresponding documentation.

Additionally, please note that the launched Advanced Trade API is in Beta which means that it is still in the stage of development. With such, we recommend that you post this in the Feedback Section of the Forum as most new features and improvements to Coinbase come directly from feedback like yours. Thank you!

Hello @tpunt! Although we normally consider this endpoint as public endpoints, commending what @0C3D said, authorization is required or enabled for each endpoint in Advance Trade API to control usage and security of the respective endpoint.

Regarding the migration page to show a mapping of the Coinbase Pro API endpoints, we can consider this as a feedback request for Advance Trade API so we recommend you to share this on the Feedback Section of the forum as most new features and improvements to Coinbase come directly from feedback like yours. Thank you and have a great day!

2 Likes

Is there a way to know the currency the fee is charged in using the List Orders endpoint?

Hello @cc_1 ! Thank you for taking an interest in trying out Coinbase APIs. For the details regarding your concern, we will check on this for you with our team. We will get back to you once we have more information. Keep in touch!

2 Likes

Hello @cc_1! As per checking, all fees to be incurred as a result of an order placement are charged onto the quote currency.

For example, if you were to place an order for the BTC-USDC cryptocurrency pair, the fees will be charged onto your USDC wallet/balance.

We hope this helps. If you have further questions, feel free to reply onto this thread.

1 Like

Can we also have a “side” field in the user channel’s response as level2 channel?

After integrating against WebSockets I have some suggestions that would have made my life easier.

The documentation doesn’t actually show the schema format of the messages coming from CoinBase. In my opinion, the schema doesn’t make a whole lot of sense and is a bit painful to work with.

As an example for tickers
The docs say to expect a message that looks like

{
   "type":"ticker",
   "sequence":29912240,
   "product_id":"BTC-USD",
   "price":"40552.26",
   "volume_24h":"0.43526841",
   "low_24h":"40552.26",
   "high_24h":"40662.06"
}

This is fine. But this isn’t really what comes over the wire.
Instead you get

{
	"channel": "ticker",
	"client_id": "",
	"timestamp": "2022-11-22T04:23:54.618364894Z",
	"sequence_num": 0,
	"events": [{
		"type": "snapshot",
		"tickers": [{
			"type": "ticker",
			"product_id": "BTC-USD",
			"price": "15801.22",
			"volume_24_h": "39927.87557223",
			"low_24_h": "15460",
			"high_24_h": "16257",
			"low_52_w": "15460",
			"high_52_w": "59526.51",
			"price_percent_chg_24_h": "-2.32280685270057"
		}]
	}]
}

What’s weird for me is an event contains a type (snapshot or update) and then a list of the actual events within the event. It would make a lot more sense (and be easier to work with) if it were flatter like this

{
	"channel": "ticker",
	"client_id": "",
	"timestamp": "2022-11-22T04:23:54.618364894Z",
	"sequence_num": 0,
	"events": [
		{
			"event_type": "snapshot",
			"type": "ticker",
			"product_id": "BTC-USD",
			"price": "15801.22",
			"volume_24_h": "39927.87557223",
			"low_24_h": "15460",
			"high_24_h": "16257",
			"low_52_w": "15460",
			"high_52_w": "59526.51",
			"price_percent_chg_24_h": "-2.32280685270057"
		},
		{
			"event_type": "update",
			"type": "ticker",
			"product_id": "BTC-USD",
			"price": "15801.11",
			"volume_24_h": "39927.87557223",
			"low_24_h": "15460",
			"high_24_h": "16257",
			"low_52_w": "15460",
			"high_52_w": "59526.51",
			"price_percent_chg_24_h": "-2.32348683128742"
		}
	]
}

In this format, it allows the client to iterate over each one without so many nested loops and temporary states to keep track of the “event type”

On a side note, I don’t know why exchanges are using JSON over WebSockets anymore. I’ve not found one that’s easy to work with. When open-source technologies like gRPC exist, designing these WebSocket API’s doesn’t make sense. With a gRPC endpoint, developers can have a fully working and very high-performance client up and running in minutes without reading any documentation. gRPC supports request and response style (REST) or bidirectional style communication (WebSocket). It would most likely reduce the overhead for the exchange, too, as encoding and decoding can often be less compute and memory intense than JSON and will consume a fraction of the bandwidth to send the messages.

gRPC doesn’t really work in web browsers which doesn’t make it a great option for Coinbases own website. Still, Protobuf also defines a JSON representation and often without too much extra effort, a server can offer a standard HTTP API, JSON over WebSocket AND a gRPC endpoint sharing the same implementation, all documented by the proto files.

This seems like a no-brainer for a new high-performance API in 2022.

All things being said, even though I think the WebSocket schemas could be better. Advanced trade WebSockets have been relatively easy to work with. Especially compared to the competition. Great work to the team at Coinbase!

3 Likes

Are there any updates on this?