HubSpot API development.
Past the connector. When the marketplace app does not cover it, somebody has to write the integration. Private apps, OAuth, webhooks, custom-coded workflow actions and the bulk operations that have to survive a rate limit.
It worked in testing.
The integration was built against a hundred records and deployed against four hundred thousand. Now it hits rate limits, times out halfway, and nobody can tell which records were processed because there was no idempotency and no log worth reading.
Failed at record eleven thousand.
API — the volume wallIntegration code that survives production.
Private apps, and the key migration
API keys are gone. Private apps with scoped tokens replace them, and anything still built on a key needs migrating before it stops working rather than after.
Rate limits designed for
Batch endpoints, exponential backoff and a queue, so a bulk operation degrades gracefully instead of failing at record eleven thousand with no way to resume.
Idempotency
Retries must not create duplicates. This is the single most common defect in integration code we are called in to fix, and it is invisible until it is expensive.
Webhooks handled properly
Signature validation, fast acknowledgement, asynchronous processing and a dead letter queue. A webhook handler that does work inline will drop events under load.
Custom-coded workflow actions
Operations Hub actions in JavaScript or Python, running inside a HubSpot workflow with no external infrastructure and no per-task bill.
Observability
Structured logging, alerting on failure rate and a way to answer what happened to one specific record at 3pm last Thursday.
Engineers, working the way engineers work.
Scope in writing
What is being built, what it will not do, and how we will both know it is finished. Fixed scope where the work is knowable, a sprint rate where it is not.
Build in the open
Version control, a preview environment and a running demo, so you are not waiting until the end to find out what you are getting.
Review against the portal
Tested inside your actual portal with your actual content, at phone, tablet and desktop widths, before anybody calls it done.
Ship and document
Deployed, with the source handed over and a page explaining how to change it. You own what we build.
The happy path was the only path tested.
Integrations are judged on their failure modes. What happens when the other system is down, when a record was deleted mid-sync, when a required property no longer exists, when the token expires at 2am. We design for those first, because they are what you will actually live with.
What people ask before they commit.
Private app or public app?
Private for an integration only your portal uses — simpler, scoped, no OAuth flow. Public when you are distributing to other portals or listing on the marketplace.
Our integration was built on an API key. What now?
It needs migrating to a private app token. HubSpot has retired API keys, so anything still using one is either broken or about to be. It is usually a short, well-defined piece of work.
Can you work with our existing integration code?
Yes. We review, fix and extend other people's code regularly. If the honest answer is that a rewrite is cheaper than the fix, we will show you why rather than just assert it.
Which languages do you work in?
TypeScript and Node primarily, Python often, PHP and others when that is what your team runs. We write in whatever your engineers will maintain, not whatever we prefer.
How do you handle the data volume limits?
Batch endpoints, queueing, incremental sync with watermarks and resumable jobs. The design starts from the volume you will have in two years rather than the volume in the test portal.
Where people go from here.
Integration code that survives.
Tell us what you are running
What the system does today, where it breaks, and when it has to work. An engineer reads it — you get an answer inside one business day, not a sequence.