Kimb Jones

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.

Sometimes the title of this post is true. Often it is a stack of thrown together parts with nobody responsible for the complete full working service.

An AI-discovered security release is not a suggestion

WordPress 7.1.1 landed with 17 core bug fixes, editor fixes, and 11 security fixes. WordPress told people to update ASAP. (WordPress 7.1.1 announcement)

There are people in our industry who still treat “update immediately” as “optional”, because the last time someone updated something, a lead gen form broke on a Friday afternoon.

Leaving a security release just sitting there because you have no staging, no recovery point and no idea who owns the plugins is how things get broken quickly.

Also, blindly and automatically applying every update with no checks or tests on the journeys that actually make money is how you create a different kind of problem.

Hosts like Pantheon treated 7.1.1 as a major security event, because this is a new breed of AI-discovered issues that can’t be ignored, they need action immediately (Pantheon release note) and although managed WordPress hosts generally have these things handled there are going to be millions of sites out there left with these gaping holes in them.

How about some physical AWS damage?

Regardless of your stack when AWS messes up, you’ll probably notice. This happened back in mid-September when AWS messed up and was unable to restore access to cloud infrastructure! This wasn’t some intern fudging a command though, this was real physical damage in Bahrain and UAE directly related to the ongoing regional conflict. Pretty serious stuff.

Multiple AWS zones were affected and data that customers had not moved was in some cases way beyond recovery options. (Reuters)

This is obviously an extreme case. Most clients are not planning for armed conflict to mess up their recovery plans.

The recent Automattic drama is not a platform crisis

Remember when Automattic’s board put Matt Mullenweg on leave, appointed an interim CEO, then reinstated him a few days later. That followed the existing row with WP Engine. It is a real governance story. It is not, by itself, a reason to rip out an independently hosted WordPress site. (TechCrunch on the leave, TechCrunch on his return)

Clients mix up WordPress the software, WordPress.org, WordPress.com, and Automattic the company so open source and data ownership still matter but only if the project was built so you actually control the code. WordPress still wins in this situation, in fact, it proves it’s worth every time Matt and the Automattic board try to make it look bad!

That is the work I am interested in at Make Do. Not a rebuild for the sake of it. Ownership of the full platform and security for the service we provide.