I don’t think that’s true – previously, when you got a webhook with a product and up to 100 variants, all the variant data was included right there with the webhook payload, you didn’t need to make any extra calls to get a full picture of the state of the product. For syncing off to external systems all the data is right there already, no API calls necessary. With the bump up to 2000, this has changed, and now you only have a partial picture.
And, I’d be fine making API calls to fetch the data if the rate limits weren’t so low! The combination of forced API calls to fetch up-to-date data whenever a webhook comes in with the low rate limit creates this issue. If we need to make API calls to fetch data after every webhook, there will always be a threshold where products are changing fast enough that you need to use your entire rate limit just to fetch the changed details about the omitted data, with no rate limit left over for actually doing anything useful.
That’s the worst case scenario indeed, but I suspect that would be rare. Without the updated_at information in the webhook payload though, we’re forced to assume the worst every time and re-fetch up to 1900 every time.