1

HubSpot is introducing a new limit on the number of IDs that can be supplied to the Batch Read endpoint for (/{fromObjectType}/{toObjectType}/batch/read) both the v3 and v4 public Associations API.

Effective February 10th, 2025, any batch read requests submitted to the Associations API may not exceed 1000 IDs per request body. This change applies to all subscription tiers and impacts processes or integrations using the Batch Read functionality.

What’s changing?

  • New Limit: The Batch Read Associations API request body now supports a maximum of 1000 entries in the inputs field.

Please see below an example of the request body inputs field that will only allow 1000 entries:

//Example: POST /crm/v4/associations/contacts/companies/batch/read?portalId=123456

{
 "inputs": [
 {
 "id": "1001",
 "after": "MC0yLTE1OTc0MDA2NTg%3D"
 },
 {
 "id": "1002",
 "after": "MTAtNi0xODQ3MjAxMzg5%3D"
 }
 ]
}

In the example above, contacts are the fromObjectType, and companies are the toObjectType. The ID of the contact whose associated companies we want to retrieve and after can be used for pagination by specifying the pagination token returned in the paging section of the previous response.

  • Larger requests that exceed this limit will be rejected with an error response. Previously, larger batches were accepted, but this change is necessary to maintain API performance and efficiency.

What does this mean for developers?

This update affects any integrations or processes that submit batch reads to the Associations API with more than 1000 IDs at a time. Developers must update their code to ensure the batch size remains within the new limit. Requests exceeding 1000 IDs will result in a failed API call, which could disrupt existing workflows and integrations if not addressed.

Instructions to avoid breakage:

  • Update existing processes to split batch read requests into smaller batches, ensuring that no more than 1000 IDs are submitted per request.
  • Review your API integrations to confirm compliance with the new limit.
  • If necessary, implement a loop to process multiple batches sequentially. This will ensure efficient handling of larger datasets while adhering to the 1000 ID limit.

When is it happening?

A new limit for the Associations API’s Batch Read feature will be enforced on February 10th, 2025. The limit will gradually decrease to 1000 over 30 days after February 10th, aiming to minimize inconvenience for users with more than 1000 IDs per request.

Important Note:

The maximum number of IDs allowed in a single Batch Read request body will be increased from 100 to 1,000. Initially, we intended to apply a limit of 100, but to better accommodate our customers, we are increasing this limit to 1000.

Questions or comments? Join the developer forums below for a peer-to-peer discussion.

Good to know :white_check_mark: Thanks @hseligson! — Jaycee

3

Why is this tagged as a bug fix? Lowering the amount of associations we can do from 500 to 100 in a single api request is just a cost cutting measure and making it even more difficult to work with the already limited rate limits provided

4

Hi @DXu, Thank you for your comment! We apologize for the frustration and understand the inconvenience this might cause users by needing to make many more API requests.
This is labeled a bug fix because it is a bug fix; we should have clarified that better. Previously, there was no limit for the Batch Read endpoint, which impacted the reliability of the API for end users. We can ensure the API works properly and doesn’t impact end users by lowering the limit. Please let me know if you have any other concerns.

5

Hi! I understand where your team is coming from but I feel like a bug fix would be to improve the performance of the system to match the previous limitations, not by lowering the existing limits.
Appreciate the openness on this but just dissapppointing to see more features ripped out of the api.

Hi @hseligson

I hear the frustration in this thread. API changes like this always land as extra work for dev teams.The new 1,000 ID cap on Batch Read requests in the Associations API means any integration that used to send more in one call will now need to chunk requests and handle pagination in a loop.

HubSpot’s reasoning is performance stability, but I get why it feels like a step back in flexibility.

2025 Official docs on this endpoint are here if you want to double-check details:

(https://developers.hubspot.com/docs/guides/api/crm/associations/associations-v4)

(https://developers.hubspot.com/docs/guides/apps/api-usage/usage-details)

Most teams will solve this with batching logic split your IDs into groups of ≤1,000 and iterate until you’ve processed the full set. It’s safe and works fine, just adds more moving pieces to maintain. If your current integration doesn’t have retry logic, now’s also a good time to add it since rejected calls will break workflows otherwise.

One thought from my side: this is exactly the type of plumbing that ends up eating time. Instead of rewriting your sync jobs every time HubSpot updates an API cap, tools like Stacksync abstract it away

The platform automatically chunks, paginates, and retries behind the scenes, so your integrations keep running without extra scripts or cron jobs. For teams syncing things like contacts > companies or deals > line items at scale, that layer can save a lot of maintenance overhead

Hope this perspective helps. Curious are you already running batch associations in production today, or still in the build phase?