We’ve just recently discovered that you can use field selectors in most endpoints which is wonderful as we were able to get certain payloads’ size from a few megabytes to a few kilobytes this way. Fetching a ton of deal data just to get two fields is just ridiculously inefficient, especially when doing so with 500+ deals in one paginated workflow.
Then it says this in the V2 migration guide:
** Support for [field selectors] has been removed.**
What? What is the rationale behind this? What’s the roadmap for V1 support in the future?
Indeed, our APIv2 don’t have possibility to request list of certain fields for our GET endpoints. API will return all built-in fields for entity.
We have dropped support of it for several reasons:
This feature had quite low adoption (<1%) while we had to maintain compatibility with changing list of entity’s properties
APIv2 payloads are now a lot leaner (50% to 75% smaller) so payload size is more manageable
Payloads are gzipped in transit so you are not actually using 1 MB of traffic to receive a 1 MB payload. Average compression rates are 60%-80%
We don’t have any plans to drop support of APIv1 endpoints at the moment. We offer APIv2 as more performant and structured alternative for v1, but it’s not in-place replacement. We will be posting our roadmap and plans for APIv2 soon, so you could plan migration ahead.
Thank you for the detailed explanation. The improvements in payload efficiency and compression are very welcome. A couple points of feedback:
Regardless of bandwidth, we would still take a payload of 1000 deals filtered for two necessary fields over a leaner/compressed payload that contains 99% unused data, for sanity’s sake alone
Retiring low-adoption features is perfectly understandable, but in this case I bet the super low usage of field selectors might be due to how the feature wasn’t visible enough! We’ve been extensively using the API for the last few years but only recently stumbled on it in a docs file on Requests. Had it been mentioned next to the GET requests in the API reference, we would have surely used it since day one.
