Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Can someone at HubSpot explain some of their API design choices?

news.ycombinator.com

Post reply on HN
Print view View original

1–10 of 27 posts

Ask HN: Can someone at HubSpot explain some of their API design choices?

#1

Post by thexumaker »

Has anyone else built integrations for hubspot and just been completely fed up with their terrible developer experience compared to other sales tools? Outreach, Salesloft, Apollo, and Salesforce have just blown them out of water in that aspect.

Some of my complaints:

1. Hubspot released Sequences 10 years ago, and somehow they still don't have API suppport.

2. Meanwhile if I need to fetch associations between objects I have to use their V4 associations API but if I want to fetch contact lists I need to use their V1 API, and to fetch contacts themselves I sometimes have to use a V1 API and sometimes a V3 API. Who is versioning all of this

3. It's 2024 and somehow none of their APIs support sorting, ordering or filtering and to do so you need to use their /search endpoint. The problem is there's a 4 requests per second rate limit on the endpoint. That leads to my next complaint

4. A 4 rps limit is fine, if HubSpot allowed you to have an individual user go through oauth, but for some reason they suggest and push you to authenticate only 1 super admin, which means if you have 10+ users the search endpoint is pretty much useless and needs to be throttled significantly

There's so many other issues with fields that should be deprecated but aren't, fields getting deprecated and the only answers being some community message 5 years ago, lack of API support for workflows and other new features, and there's even issues where I noticed we'd get small bursts of 401's for no reason and Hubspot's response was that when they rotate the credentials used to verify tokens it can cause temporary downtime daily.

Re: Ask HN: Can someone at HubSpot explain some of their API design choices?

#4

Post by thexumaker »

whalesalad wrote: post #3

As someone who has had a lot of experience with their platform and API - I do not think it was actually designed. It's duct taped and glued together.

It's not just their API that sucks, even simple stuff like their marketplace is horribly managed.

For shits and giggles I created an app for the marketplace and copied similar screenshots to what a competitor offered but then my application was rejected for not having proper screenshots. The app manager just responded that they had special privilege to not abide by any of the marketplace rules. Turns out they signed a pretty large deal with the competitor...

Re: Ask HN: Can someone at HubSpot explain some of their API design choices?

#5

Post by __experiment__ »

You have to understand that most APIs, most codebases, most designs, most documents, most ... everything

was done by people who did not receive the appropriated training in design patterns and has to glue something that worked in order to be proved by someone else

outside of a few orgs who chase excellency in every regard this is the reality for most companies, organizations and people. it makes sense given the circumstances they found themselves in.

it's actually quite impressive that anything works when you REALLY think about it

#

Re: Ask HN: Can someone at HubSpot explain some of their API design choices?

#6

Post by thexumaker »

__experiment__ wrote: post #5

You have to understand that most APIs, most codebases, most designs, most documents, most ... everything was done by people who did not receive the appropriated training in design patterns and has to glue something that worked in order to be proved by someone else outside of a few orgs who chase excellency in every regard this is the reality for most companies, organizations and people. it makes sense given the circu…

Fair enough and I get it, I've been there. But for a 17 year old company worth ~30 billion to have this many issues compared to both newer startups(Salesloft/Outreach) and large incumbents(Salesforce) is just unacceptable.

I'm not here saying every company is perfect, I have quite a few gripes with other services but they either:

A. Actually respond to issues and work with developers and actively help maintain their app integrations despite significantly smaller support teams(I've worked with at most 1-2 csms and an engineer or pm with most integrations but with hubspot I get routed from our app manager, to a csm to an entire engineering team and even the head of support all to just get an email that their oauth issues won't be fixed until q3 202x since developer experience isn't a priority)

or

B. Blatantly don't care but don't sell themselves to sales team that they have a great integration and great support for people building integrations. I'm at a point where I'm trying to actively push our mutual customers to anything but hubspot

Re: Ask HN: Can someone at HubSpot explain some of their API design choices?

#8

Post by thexumaker »

leros wrote: post #7

For #4, maybe you can build a single instance API proxy that handles the rate limiting better.

definitely. There's still just such a huge bottleneck when we have 20+ users having to queue up, and they end up complaining that they don't want to wait so long for data to come back from hubspot

Re: Ask HN: Can someone at HubSpot explain some of their API design choices?

#9

Post by leros »

thexumaker wrote: post #8
leros wrote: post #7

For #4, maybe you can build a single instance API proxy that handles the rate limiting better.

definitely. There's still just such a huge bottleneck when we have 20+ users having to queue up, and they end up complaining that they don't want to wait so long for data to come back from hubspot

Can you cache data internally?

Re: Ask HN: Can someone at HubSpot explain some of their API design choices?

#10

Post by randomdata »

API gets thrown around pretty loosely, but what Hubspot has isn't really an application programming interface. It is a state transfer service, as echoed in the documentation.

While am I sure their service is not free of flaws (the versioning as described comes off especially strange), the biggest issue here may be taking "API" too literally. What you are looking for is, indeed, an API, but that is not what they have on offer. Presumably their expectation is that you will build your API on top of the transferred state.

Post reply on HN