Integrations rarely fail loudly. They fail quietly: a token expires on a Friday, a sync falls behind, and for three weeks your dashboards report numbers that are confidently wrong. By the time someone notices, the clean-up costs more than the integration did. This guide covers why integrations break, what reliable ones do differently, and the question every buyer should ask: when this fails at 2am, whose problem is it?
Why working integrations stop working
Authentication expiry. Tokens and credentials expire, get rotated by an IT policy, or are revoked when the employee who connected them leaves. This is the most common silent killer, because everything simply stops with no error a business user ever sees.
API changes and deprecations. Both HubSpot and the system on the other side evolve their APIs. Versions get sunset, endpoints change behaviour, and an integration nobody maintains keeps calling an API that no longer answers the same way.
Schema drift. Someone renames a property, deletes a pipeline stage, or adds a mandatory field. The integration was built against the old shape. Nothing announces this; records just start failing to write.
Rate limits and volume spikes. The integration that handled your January volume meets your Black Friday volume, hits the API's limits and starts dropping or delaying records. Without queuing and retry logic, spikes become data loss.
Third-party downtime. The other system goes down for an hour. A naive integration loses that hour forever; an engineered one replays it.
What a reliable integration does differently
It is monitored, and it alerts a human. Every sync run, failure and anomaly is logged, and failures page an engineer rather than waiting to be discovered in a board pack. Monitoring is the difference between a five-minute fix and a three-week data corruption.
It retries safely. Transient failures are retried with backoff, and operations are idempotent, meaning a retried write cannot create a duplicate or double-post an invoice. Records that repeatedly fail go to a holding queue for review and replay, so nothing silently disappears.
It fails loudly at the edges. When the other system rejects a record, the integration surfaces it (who, what, why) instead of swallowing the error. A visible failure queue is a feature, not an embarrassment.
It is documented. Field mappings, ownership rules, credentials inventory, runbooks. If the original developer disappearing would strand you, you do not own an integration; you rent a dependency on one person.
It has an owner. Somebody, in-house or contracted, is named as responsible for it, with an agreed response arrangement. Integrations without owners rot on a schedule of roughly one API deprecation cycle.
The questions to ask before you buy
Whether you are commissioning a new build or auditing what you already run: How will we know within an hour that the sync has failed? What happens to records that fail: are they lost, or queued and replayed? Is every write idempotent? What documentation exists, and could another developer take it over? Who owns it in year two, and what does that cost? A provider with real engineering discipline answers these immediately. Our checklist for evaluating providers is in how to choose a HubSpot integration partner.
Build for the run, not the demo
Most integration budgets obsess over the build and ignore the years the thing has to run. Our position is the opposite: the build is a few weeks; the run is the product. Every custom HubSpot integration we ship includes monitoring, safe retries, documentation and a delivery guarantee, and our in-house team maintains what it builds under an integration care plan. If you inherited an integration nobody owns, that is a conversation we have most weeks; a short review usually establishes whether it needs adopting, hardening or replacing.
Frequently asked questions
Why did my HubSpot integration stop syncing?
The most common causes are expired or revoked credentials, an API version change on either side, a renamed or deleted property the integration depended on, or rate limits during a volume spike. Without monitoring, all of these fail silently.
How should a HubSpot integration be monitored?
Every run and failure should be logged, failures should alert an engineer rather than wait to be noticed, records that fail should queue for replay rather than vanish, and key fields should be compared between systems regularly to catch drift.
Who should maintain a custom integration?
A named owner with engineering capability: either your in-house team with full documentation, or the firm that built it under a support arrangement. An integration with no owner will break at the next API deprecation and stay broken.
Running an integration nobody owns? Read the complete guide to connecting anything to HubSpot, or ask us to review it: custom HubSpot integration services with monitoring and support built in.
Stay Updated with Our Latest Insights
Get expert HubSpot tips and integration strategies delivered to your inbox.