Make en Zapier audit: secrets, retries, stille fouten

De klant mailde vorige week met de zin die we elk kwartaal horen: 'Kunnen jullie ons Zapier-account overnemen? Onze automation-persoon is in maart vertrokken, sindsdien is er niets aangeraakt.' We logden in. Zevenenveertig scenario's. De helft stond in error, sommige al negen weken. Eén had stilletjes dezelfde aanmaningsmail 412 keer naar dezelfde klant gestuurd voor iemand op finance het doorhad.

We zeggen niet zomaar ja om een Zapier- of Make-account te onderhouden. We auditen het eerst. De audit kost ongeveer drie uur per honderd scenario's, en het antwoord is soms 'dit kunnen we niet onderhouden, het moet opnieuw gebouwd worden'. Drie soorten schade komen steeds terug: verouderde secrets, retry-stormen, en stille fouten die niemand ziet tot ze opduiken in een support-ticket.

Hier is de checklist die we doorlopen.

Secrets en connecties

Open eerst het connecties-paneel. Make en Zapier laten allebei elke OAuth-grant en API-key zien die het account in bezit heeft. De meeste accounts die we overnemen hebben er tussen de vijftien en veertig. Drie dingen waar we naar kijken.

Verouderde OAuth-grants. Connecties die hangen aan Google- of Microsoft-accounts van oud-medewerkers. Het scenario draait prima tot die medewerker wordt deprovisioned, dan faalt het stil (daar zo meer over). Alles wat aan een persoonlijke Gmail of voormalige medewerker hangt, vlaggen we direct.

API-keys zonder rotatiegeschiedenis. Een statische Stripe-key, een Salesforce-token, een SMTP-wachtwoord. Als het sinds 2023 nul keer is geroteerd, is het een risico. Check of het bronsysteem rotatie zonder downtime ondersteunt. Stripe en Slack doen dat. Sommige oudere SaaS-tools vereisen dat je verwijdert en opnieuw autoriseert, wat ingeplande downtime betekent.

Te ruime permissies. Een scenario dat alleen klantrijen leest, hoort geen full-admin Salesforce-token vast te houden. Dit fixen we niet altijd op dag één, maar we noteren het en trekken het aan bij een rebuild.

Retry-gedrag en de prijs van een vastgelopen queue

Make en Zapier retryen allebei gefaalde stappen. De defaults zijn voor de meeste stappen prima. Ze zijn gevaarlijk bij twee specifieke vormen van scenario.

Uitgaande email en SMS. Als een scenario een notificatie verstuurt en het downstream-systeem (Postmark, Twilio, je eigen SMTP) een 500 teruggeeft, retryt het platform. Als je scenario niet dedupliceert bij de retry, verstuur je het bericht twee keer. Als de upstream-trigger snel genoeg afgaat en de downstream-API echt een uur down is, kun je hetzelfde bericht honderden keren versturen voor de queue het inhaalt.

We hebben dit precies één keer zien gebeuren bij een Make-scenario dat een Google Sheet watchde voor nieuwe factuurrijen en die in een aanmaningsmail duwde. Sheet voegde een rij toe, SMTP timede uit, Make retryde. Ondertussen kwam er nog een rij binnen. Elke retry verwerkte nu beide rijen. De volgende retry verwerkte er drie. Tegen de tijd dat het team het doorhad, had één klant tweeënveertig identieke aanmaningsmails ontvangen en geantwoord op één daarvan met een screenshot van zijn inbox.

Webhook fan-outs. Een scenario getriggerd door een webhook die vijf downstream-API's aanroept. Als stap drie faalt, draait Zapier het hele scenario opnieuw, wat betekent dat stap één en twee twee keer worden uitgevoerd. Als stap één of twee niet idempotent zijn (een record aanmaken, naar Slack posten, een kaart belasten), heb je nu duplicaten gecreëerd.

De audit-fix is elk scenario inventariseren dat naar een extern systeem schrijft en de vraag stellen: als deze stap twee keer draait, geeft dat schade? Zo ja, dan heeft het scenario een idempotency key nodig, een dedup-lookup, of een queue met een guard. Vaak is de goedkoopste fix de daadwerkelijke write door een kleine webhook-endpoint te laten lopen die wij beheren, waar we idempotentie in code kunnen afdwingen.

// Tiny idempotency guard in a Vercel/Cloudflare function
// that Make or Zapier calls instead of writing directly.
import { kv } from '@vercel/kv'

export default async function handler(req, res) {
  const key = req.headers['x-scenario-key']
  if (!key) return res.status(400).json({ error: 'missing key' })

  // First writer wins; everyone else gets a 200 with no side effect.
  const ok = await kv.set(`run:${key}`, 1, { nx: true, ex: 86400 })
  if (!ok) return res.status(200).json({ deduped: true })

  await doTheActualWork(req.body)
  return res.status(200).json({ ok: true })
}

Het platform stuurt een stabiele key per logische run mee, wij weigeren duplicaten 24 uur lang, en een Make retry-storm wordt één write plus een stapel onschuldige 200's.

De stille-fout-val

Dit is degene die de meeste schade aanricht en het lastigst te spotten is.

Make en Zapier bieden allebei 'stop on error'- en 'continue on error'-takken. De makkelijke keuze, die de meeste no-code-bouwers maken, is het scenario zo instellen dat het de bouwer mailt als er iets faalt. Dat werkt prima tot:

1. De bouwer vertrekt bij het bedrijf.
2. De notificatie gaat naar een gedeelde inbox die niemand leest.
3. De error-notificatie zelf hangt af van de kapotte connectie (een Slack-channel dat is verwijderd, een Gmail-account dat is deprovisioned).
4. Het scenario staat op 'continue on error' en de gefaalde stap was juist de stap die ertoe deed (de factuur is gepost, maar de bijbehorende boekingsregel niet).

De helft van de scenario's die we overnemen, faalt stil op één van deze vormen. De klant weet het niet, want het dashboard toont 'Success' voor het parent-scenario en de begraven error zit in de run-historie. Make's run-historie gaat op de meeste plannen dertig dagen terug. Zapier's task-historie hangt af van het tier. Daarna is het bewijs weg.

Onze audit-stap hier is simpel: trek de laatste dertig dagen run-historie op voor elk scenario en tel de echte success rate door downstream side effects te tellen, niet door de success-flag van het platform. Als een scenario bij elke run een Salesforce-record hoort aan te maken, tellen we in Salesforce, niet in Zapier. De twee getallen matchen bijna nooit.

Wat we met de audit doen

We leveren de klant een rapport van één pagina per categorie, met een aanbevolen actie per scenario: behouden, roteren, rebuilden, of uitzetten. De 'uitzetten'-kolom is meestal de meest verrassende. Ongeveer een derde van de scenario's in elk account dat we auditen, draait voor geen enkele levende reden. Het bronsysteem is twee jaar geleden vervangen. Het Slack-channel is gearchiveerd. De ontvanger is vertrokken. Niemand heeft het scenario uitgezet, want niemand wist dat het bestond.

Het andere wat de audit de klant geeft, is een verdedigbare nulmeting. Als je niet weet wat er vandaag draait, kun je morgen niet zien of een regressie van jouw wijziging komt of van het scenario dat zichzelf langzaam sloopt.

Voor de scenario's die de audit overleven, zetten we een echte error-pipeline op. Elk scenario rapporteert fouten naar één channel dat wij beheren. Elke connectie heeft een gedocumenteerde rotatiecadans. Elke write-stap is idempotent of guarded. De Slack-alerts bevatten een run-link en de laatste 200 tekens van de error, zodat de on-call-persoon kan triagen zonder de platform-UI te openen.

Toen we deze audit deden voor een Nederlandse B2B-distributeur met zesenveertig live Make-scenario's, was het resultaat: dertien behouden, elf herbouwd op een strenger patroon, en tweeëntwintig uitgezet. Het aanmaningsloop-scenario dat al weken dubbel verstuurde, is nu een kleine Node-service die wij beheren met een echte idempotentie-tabel, en dat soort process automation-rebuild is ongeveer de helft van ons integratiewerk.

Als je één ding meeneemt uit deze post: open vanmiddag je Make- of Zapier-account, sorteer scenario's op laatste error-datum, en tel hoeveel er langer dan dertig dagen op rood staan. Dat getal is de omvang van het probleem dat je nog niet kent.