Most “the website is connected to the CRM” projects are a webhook and a bit of hope. The form submits. Something POSTs. Someone once saw a 200. We call it an integration. But should we?
Then a lead does not appear, sales blames marketing, marketing blames the agency, and the agency points at a vendor status page that is green.
Hello Zoho!
Zoho’s own webhook documentation is unusually honest. If delivery fails, Zoho retries once after 15 minutes. After that, no further webhook is sent for that workflow trigger. Zoho also warns that it does not email you when a webhook stops because of a third-party API problem. (Zoho CRM webhooks)
So if missing an event matters a Zoho webhook is a FAST path, not a guarantee. You need a second path for comparison or ideally an API poll that can find the records that never arrived.
Zoho’s newer Notification API is better for some event-driven work, but the channels expire after a day or a week depending on configuration and must be renewed. Miss the renewal and events stop. That is not a mystery outage. It is a lifecycle you failed to own.
HubSpot did not need an outage to break shit
HubSpot changed Conversations API behaviour last week for Help Desk. Creating a COMMENT on a Help Desk thread via POST /conversations/v3/conversations/threads/{threadId}/messages now returns a VALIDATION_ERROR. Comments are being replaced with CRM notes. See this on the HubSpot changelog.
So basically the API can be “up” and still refuse the thing your code has done for two years and monitoring 500 errors will miss this so a it looks like a new 400 is just as good at losing work.
Salesforce is making the same point with dates
Winter ’27 has given us API updates for /services/data/latest/ which reckons it can always hit the newest REST version. So good for for experiments in theory but a poor idea in the middleware space where the schema moves without you choosing a maintenance window. Nice work. I think.
Authentication technical debt is worse and gets worse every year and Salesforce is retiring SOAP login() for API versions in 12 months so username/password OAuth will be the only working pathway.
This will be fun for when inherited WordPress–Salesforce connectors “still work” until a working account can be shared to fill the gap. I absolutely hate OAuth because it relies on a working account, say your Marketing VPs email and password, being active and working when in reality they’re on the fast track to retirement and the day their credentials are deleted us the day 100s of leads drop (true story)
That is exactly what an adoption audit should find however so you know your auth flow and any connected apps when it will expire when APIs and secrets might need to be rotated etc. Surprising how many Enterprise teams do not know this?
Fact is that vendors don’t (or rarely) document things like this or if they have valid retry limits, validation errors or deprecation dates of key features or timeouts.
Leave a Reply