Live data from Hacker News

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

news.ycombinator.com

11–20 of 27 posts

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

#11

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…

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.

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

#12
post #9

Earlier quoted context omitted.

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.

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

#13

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…

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 RES…

> I disagree

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

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

#15

Earlier quoted context omitted.

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 RES…

> 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

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

#16

Earlier quoted context omitted.

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

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

#17

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…

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.

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

#18

Earlier quoted context omitted.

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.

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

#19

Earlier quoted context omitted.

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.

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

#20

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…

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.
Post reply on HN