Automatitzacions

El motor de regles converteix un esdeveniment en feina, i ja viu sobre el contracte v1. Una regla escolta un tipus d'esdeveniment, una condició decideix si aquell esdeveniment concret és el seu cas, i s'executa una llista ordenada d'accions — divuit operacions sobre quinze rutes sota /v1/automations, totes darrere del mòdul nou automations. Comença per la guia d'automatitzacions.

• Pregunta al catàleg, no ho endevinis — GET /v1/automations/catalog retorna els activadors als quals la teva empresa es pot subscriure (ja filtrats pels mòduls que inclou el teu pla), el conjunt tancat d'operadors i combinadors de condició, i les accions amb adaptador registrat. Els camps avaluables d'un activador són una segona crida deliberada, GET /v1/automations/catalog/triggers/{trigger}/fields, perquè el catàleg continuï sent prou petit per cachejar-lo i comparar-lo.
• Cada edició segella una versió — editar una regla mai reescriu la seva definició anterior: segella una versió nova i puja current_version, i cada execució guarda un punter a la versió exacta que va executar. Una regla neix en draft i no escolta res fins que l'actives.
• Un assaig que no materialitza res — POST /v1/automations/rules/{rule}/dry_run respon què faria una regla davant d'un esdeveniment d'exemple: no surt cap correu, no s'entrega cap webhook, no es muta cap entitat, no s'escriu cap fila d'execució, i no consumeix ni el pressupost mensual ni el límit de freqüència del motor. Una condició que no es pot avaluar torna com a condition_error amb un 200, perquè veure per què una regla no es pot avaluar és justament la gràcia.
• Historial d'execucions, passos i rellançament — cada esdeveniment admès produeix una execució i cada acció un pas, tots dos amb la definició congelada i el payload de l'activador. discard_reason és un valor tipat d'un catàleg tancat, així que hi pots ramificar en comptes de parsejar text. La feina aparcada es rearma amb POST /v1/automations/runs/{run}/replay o amb el seu germà per pas; el rellançament executa de debò i està marcat com a x-irreversible a l'spec.
• Quatre baranes, i bloquejada no és fallida — profunditat de cadena (tres salts «acció → esdeveniment → regla» per defecte), un límit de freqüència per minut, el pressupost mensual del pla (GET /v1/automations/usage) i una pausa automàtica després d'una ratxa d'execucions fallides. Una execució aturada per qualsevol d'ells es registra com a blocked amb la seva raó tipada. Consulta Codis d'error d'Automatitzacions — 47 codis nous sota el grup Automations, cadascun amb la seva causa i què fer.
• Quatre scopes fins — automations:read, automations:write, automations:delete i automation_runs:read. Llegir i escriure regles i llegir l'historial d'execucions es concedeixen a la pantalla de consentiment OAuth; esborrar una regla no, i es queda només per a API key. Llegir el reglament i llegir què van fer realment les regles van per separat expressament. Consulta Scopes i permisos.
• Set esdeveniments de cicle de vida, i són activadors ells mateixos — automation_rule.activated, .paused, .auto_paused, automation_run.started, .completed, .failed i .step_dead_lettered. Viuen al mateix catàleg tancat que la resta d'esdeveniments, així que una automatització pot reaccionar a automation_run.failed igual que reacciona a invoice.paid; encadenar-los està acotat pel límit de profunditat, no prohibit. Consulta Esdeveniments.
• Regles de cartera per a gestories — una regla declara quines empreses vigila al seu camp scope: empresa (el valor per defecte) vigila la seva pròpia empresa, i cartera vigila totes les empreses gestionades per una gestoria i li entrega l'avís a ella. L'abast és immutable, i en cartera només s'admeten els quatre tipus d'acció que avisen — els altres quatre tindrien per subjecte un document de l'empresa gestionada.
• Paritat amb MCP i CLI — la mateixa superfície com a 18 tools MCP (catàleg) i com el grup de comandes factuarea automations (CLI).