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

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...

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

#

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

Try to turn your opinion around and realize that the API they offer must be good enough for them to survive 17 years and have a 30 billion market cap.

I appreciate your sharing of yoir experience with the Hubspot API. I wasn't aware of how bad it is, and I'll keep it in mind.

Responding to the way that Hubspot handled your concerns: competitors Pardot and Marketo are not any better. I don't remember them ever correcting bugs that I reported. And simply getting through the gauntlet of "this isn't a bug, its a feature" Level 1 support is exhausting. Eloqua was much better - but only because I was working at a "partner consultant" org at the time and concerns/bug reports were fast-tracked to senior support techs.

Generally, Salesforce is what I consider "perfect software" (Joel's "good software takes 10 years" concept). It beats all the startups on so many fronts...

hey @thexumaker, I'm a new PM at HubSpot working on our APIs and some of the issues you've brought up are just what I'm looking to improve. Sorry to hear you haven't had a great experience with the APIs or getting contact with HubSpot PMs. I have my email on my profile, would love to get some more detail on your feedback --please feel free to reach out!

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.

I disagree with this especially when they launched their "new" platform in 2020: https://developers.hubspot.com/docs/api/overview

> HubSpot’s developer platform is a core part of our mission to empower organizations to grow better. Our APIs are designed to enable teams of any shape or size to build robust integrations that help them customize and get the most value out of HubSpot. All HubSpot APIs are built using REST conventions and designed to have a predictable URL structure. They use many standard HTTP features, including methods (POST, GET, PUT, DELETE) and error response codes. All HubSpot API calls are made under https://api.hubapi.com and all responses return standard JSON.

I'm getting a bit more estate transfer implications in their old docs but barely

> The API is built to allow you to create a functional application or integration quickly and easily. We know from experience - these are the APIs that power the HubSpot application. The ecosystem of developers creating integrations on top of the APIs is strong and diverse, ranging from webinar providers to CRMs to social media.

Not really sure where they mention it as a state transfer service. Not to mention even if it was, their lack of support for over 50% of their workflow/sequence/queue automations products make state transfer impossible anyways even for internal teams.

> I disagree

Glad to hear it. That means you don't have a problem (at least for some of the points raised).

Not sure how me pointing out none of their docs mention state transfer anywhere invalidates my issues with their API.

L take buddy

It's right there in what you copied, or you could also look at the design. That will always tell you more than the words around it.

But, regardless, I am happy that you were able to solve your problem.

Man you’d fit right in at hubspot. Starts talking gibberish when a customer points out flaws.

But seriously, I was hoping I could come work with you. I'm impressed by your developer prowess. I give you a short, somewhat vague explanation of how to deal with some of the issues you faced and within minutes you have it addressed and returned to joke around with me.

Most developers I know would spin their wheels for weeks with such little information, and once they finally get the job done they wouldn't have time to joke around because they'd be so far behind in everything else they need to get done.

I've never used their API but the first google result for Hubspot API is their API reference documentation which starts with:

"HubSpot’s developer platform is a core part of our mission to empower organizations to grow better. Our APIs are designed to enable teams of any shape or size to build robust integrations that help them customize and get the most value out of HubSpot.

All HubSpot APIs are built using REST conventions and designed to have a predictable URL structure. They use many standard HTTP features, including methods (POST, GET, PUT, DELETE) and error response codes. All HubSpot API calls are made under https://api.hubapi.com and all responses return standard JSON."

If it's not actually an API in the traditional sense then that's absolutely awful documentation.

Based on the way you have described their API, I can make 2 assumptions

1. The might have had well supported API until the point at which they realized they wanted to have more people to use the webapp, rather than having the data sent through an API. More time spent on the Hubspot webapp means, more chances the customer notices the other services Hubspot provides and pays for them.

2. The versioning APIs that you see are most likely due to an enterprise deal Hubspot made with a large company who asked for variations in the API, and Hubspot introduced a v2/v3/v4 instead of modifying v1 (to not cause disruptions for their customers using v1).

I marvel that anyone would use a CRM system or any important HTTP API that doesn’t support conditional operations. I mean, this is mission critical data, right?

Support for If-Match seems like a low bar and yet few clear it.

When asked about data quality issues (“data in a weird state” or “shouldn’t be possible”) and the API has zero protection for lost updates… I sigh. Nothing to do.

A lot of companies historically wouldn't have an API at all, but MBAs started learning about it as a way to differentiate yourself, probably around the time the Jeff Bezos "API mandate" started to make the rounds on news sites. So now we get "APIs" outsourced to bottom-dollar firms.

Yes, we built an integration to ingest data from Hubspot at $DAYJOB and it was one of the worst we’ve had to deal with. They’re horribly inconsistent with what is documented and what isn’t. Even Meta’s has been better.

SaaS idea-- wrap Hubspot's API with a clean API and sell it marked up.

If you can still change the title, Ask HN: might be a good fit?

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?

We tried a mix of caching as well as hubspot webhooks, but we were still having issues with data not updating fast enough and most of the data we load has to be somewhat on demand regarding tasks/sequences and outbounding features. ie you call or email someone, a task gets moved to the next task and the user wants to see that change somewhat quickly.

I thought that website is a user-generated?