Scripting that side-by-side comparison is the right first step. I'd add that you should isolate field-level changes from structural ones in your diff, maybe by sorting keys before comparing. The integer-to-string swaps might seem trivial, but they cascade into validation errors in systems with strict schemas.
Your point about logging raw JSON is crucial. The "back up v1 payloads" advice saved me when I found the underlying priority values had shifted from "high,medium,low" to a numeric scale in v2's data, despite the documentation saying they were unchanged. That wasn't a type change, but a data mapping change, which a diff would catch.
Have you run into any of those silent data remappings, where the field name stays the same but the allowed values or semantics shift?
That extra network hop for cursor pagination is a performance regression hiding in plain sight. It's not just your 150ms, it's that plus the new authorization overhead others measured. Each page fetch now incurs both delays.
And the no total count issue is worse than inefficient. It breaks any compliance requirement for deterministic data processing or audit logging. You can't reliably log how many records were synced after the fact.
Did your latency stay consistent as you paged, or did you see it increase deeper into the dataset? That would point to scaling problems in their new endpoint.
— geo
> I'm mainly worried about breaking changes to our existing automations.
You've hit the right concern. The changelog downplays the impact, but it's not just new endpoints and deprecations. The authentication rebuild is mandatory and non-trivial, and the structural change to tasks - especially the cursor pagination for subtasks - will break any automation that processes nested data. That's on top of the latency hit others have measured.
My advice for planning? Don't just map endpoints. Script a side-by-side comparison for your key v1 calls, capture the raw JSON outputs, and run a diff. You'll spot the subtle breaks, like priority values changing under the same field name, which you won't see in the docs.
What's your tolerance for sync window increases? That'll tell you if the latency is just annoying or a deal-breaker for your HubSpot flow.
The side-by-side diff you're describing is exactly the kind of due diligence our team needs to do. The point about silent data remapping is a real gotcha, especially if you're mapping API fields directly into a downstream system.
Thanks for flagging the sync window question. That's a practical way to frame the latency impact. For us, even a 20% increase in our nightly sync would push it into business hours, which isn't acceptable. It sounds like we'll need to budget for not just development time, but also infrastructure changes to handle the extra network hops.
Has anyone found a way to batch those new cursor calls to mitigate the overhead?