We’re using Ruby’s Faraday as our HTTP client. When this error occurs, immediately retrying the request (with the exact same body and headers) resolves the issue.
This suggests the request itself is properly formatted, but is occasionally discarded or misinterpreted on the server side.
Has anyone else encountered this behavior? Are there any known issues with the legacy API under specific conditions?
Hi @s10akir and welcome, it’s a pleasure to have you here!
Thanks for reaching out to the HubSpot Community!
For information, the legacy endpoints you’re using have newer v3 equivalents that may be more stable. Here they are:
- CRM API | Associations
- CRM API | Companies
- CRM API | Contacts
Also, I’d love to put you in touch with our Top expert: Hi @d-lupo, @Anton and @MichaelMa do you have suggestions to help @s10akir, please?
Have a lovely weekend and thanks so much!
Bérangère
Just to clarify—according to the documentation [here](Developer platform - HubSpot docs), it seems that legacy apps and their associated APIs are still actively maintained and fully supported.
Given that, should we understand that while legacy APIs are still supported, using the newer v3 endpoints is recommended from a stability/reliability perspective?
We’re happy to consider migration, but just want to confirm the long-term support expectations for legacy endpoints.
Many thanks in advance for any additional insights you can provide.
I appreciate your time and assistance.
Hi @s10akir and thanks for your reply!
Yes, legacy APIs are still fully supported and actively maintained by HubSpot. However, there are important nuances to understand:
Legacy private and public apps remain “fully supported and actively maintained.”
All REST APIs are available via legacy app authentication methods.
While legacy endpoints are supported, HubSpot strongly recommends migrating to v3 endpoints for better stability and access to newer features.
Many v1/v2 APIs have scheduled sunset dates (e.g., v1 Lists API sunsets April 30, 2026).
A few things to keep in mind:
- Legacy endpoints won’t receive new functionality
- Older versions are being phased out over time
- v3 endpoints align with modern API design standards
You’re safe continuing with legacy endpoints short-term, but plan migration to v3 for long-term stability and feature access.
Here is a documentation that might be of interest: “Developer platform”.
I hope this helps!
Bérangère This post was created with the assistance of AI tools.
We’re not completely blocked at the moment since retrying resolves the issue for now, but we’ll make sure to plan a migration to the v3 APIs while the legacy ones are still supported.
Thank you for the update @s10akir!
It’s great to hear that retrying is working for now and that you’re planning ahead for the migration to v3 APIs.
If you have any more questions or run into anything else along the way, feel free to reach out, we’re here to help.
Appreciate your proactive approach!
Bérangère
It looks like you’re using the older version of HubSpot’s APIs. While some of the legacy endpoints still work for now, they are being phased out. To ensure stability and avoid intermittent issues like the one you’re seeing, it’s best to switch to the newer API versions. You can find the documentation for the latest APIs here:
I hope this will help you out. Please mark it as Solution Accepted and upvote to help another Community member.
that pattern you’re seeing a few calls returning “Invalid input JSON: No content (empty input stream)” and then succeeding immediately on retry usually points to how the request reaches HubSpot rather than to the JSON itself.
Legacy endpoints tend to surface this more because they sit behind older handlers, so anything that interrupts or truncates the request body in transit will show up as an “empty stream” even when your app logs show a full payload (Search the CRM - HubSpot docs )
Faraday can occasionally reuse connections in a way that drops the body on the first write when the server or proxy signals a keep-alive boundary. That’s why the second attempt succeeds. A simple test is to enable request-level logging or temporarily send the same payload to a capture endpoint to confirm whether those failing requests actually contain the body on the wire. If the body is missing only sometimes, it’s almost always the HTTP layer rather than the API logic.
Migrating to the v3 equivalents does help here, not because legacy is unsupported, but because the v3 routes use the newer request processors that are less sensitive to small transport quirks. Do you route these calls through a proxy or load balancer that could also be shaping the request? Where two HubSpot portals need to stay aligned reliably, Stacksync smooths out those intermittent request drops by handling retries and body validation before the write reaches HubSpot.
