n8n és molt útil per connectar sistemes B2B, però també pot convertir-se en una font de deute si cada integració neix com una cadena de nodes sense contracte. Integrar APIs REST no consisteix a “cridar un endpoint”: consisteix a governar dades, errors, credencials, reintents i manteniment.
La diferència entre un flux que aguanta producció i una demo fràgil sol estar en decisions poc vistoses: idempotència, logs, validació de payloads, versionat i qui respon quan una API canvia.
Punts clau
- Comença pel cas d’ús i el contracte de dades, no pel connector més cridaner.
- Cada flux B2B ha de tenir owner, documentació, errors esperats i estratègia de reintent.
- L’autenticació i les credencials no poden quedar repartides en nodes sense control.
- La idempotència evita duplicar comandes, leads, factures o tasques quan una crida es reintenta.
- n8n escala millor quan s’usa com a orquestrador, no com a amagatall de lògica crítica no documentada.
Començar pel cas d’ús, no pel connector
Abans d’obrir n8n, escriu el flux en llenguatge operatiu:
- Quin esdeveniment l’inicia?
- Quin sistema és la font de veritat?
- Quines dades mínimes viatgen?
- Quines accions canvien estat?
- Quins errors són esperables?
- Qui ha de revisar excepcions?
- Com se sap que ha funcionat?
Exemple B2B: “Quan entra un lead qualificat des del web, crear oportunitat al CRM, associar empresa, avisar el responsable comercial i registrar el resum de l’agent IA”.
Aquest flux sembla simple, però implica diverses decisions: deduplicació d’empreses, camps obligatoris, assignació d’owner, permisos d’escriptura, gestió d’errors i traçabilitat.
Contracte de dades: l’assegurança contra fluxos invisibles
Un contracte mínim hauria d’incloure:
| Camp | Pregunta |
|---|---|
| Trigger | Webhook, cron, esdeveniment de CRM, email entrant? |
| Payload | Quins camps són obligatoris i quin format tenen? |
| Validació | Què passa si falta email, CIF, telèfon o consentiment? |
| Acció | Es crea, actualitza, envia, assigna o només es proposa? |
| Resposta | Quin sistema rep confirmació i amb quin ID extern? |
| Error | Es reintenta, es deriva o es bloqueja? |
Sense contracte, n8n pot acabar funcionant com una caixa negra: tothom sap que “hi ha un flux”, però ningú sap quina dada envia, què passa si falla o quin impacte té tocar-lo.
Mètodes HTTP i idempotència
En integracions REST, la semàntica importa. Un GET no hauria de canviar estat. Un POST sol crear o activar alguna cosa. Un PUT reemplaça una representació i sol ser idempotent. Un PATCH modifica parcialment. Un DELETE elimina o desactiva, segons API.
La idempotència és clau en B2B perquè els reintents existeixen. Si un proveïdor triga, si la xarxa falla o si n8n torna a executar un node, no vols crear dues oportunitats, dues factures o dos tickets.
Estratègies habituals:
- usar claus externes (
external_id); - consultar abans de crear;
- desar IDs de resposta;
- dissenyar endpoints d’upsert quan existeixin;
- registrar hash del payload processat;
- evitar reintents cecs en accions d’escriptura.
Autenticació i credencials
Les credencials s’han de gestionar com a part del sistema, no com a detalls de configuració. Revisa:
- tipus d’autenticació: API key, OAuth2, token temporal, Basic Auth;
- rotació de credencials;
- permisos mínims per integració;
- separació entre entorn de prova i producció;
- qui pot editar credencials;
- quins logs podrien exposar secrets;
- com es revoca accés si canvia el proveïdor o una persona de l’equip.
Control d’errors i observabilitat
Un flux B2B sense observabilitat obliga a descobrir problemes per queixes de clients o comercials. Com a mínim, cada flux important hauria de registrar:
| Element | Exemple |
|---|---|
| Correlation ID | ID únic per seguir l’execució entre sistemes |
| Input resumit | Dades no sensibles que permeten identificar el cas |
| Resultat | Creat, actualitzat, omès, duplicat, derivat |
| Error | Codi, missatge, sistema afectat i pas |
| Acció posterior | Reintent, alerta, revisió humana o bloqueig |
No tot error mereix el mateix tractament. Un 401 pot requerir revisar credencials. Un 429 pot demanar backoff. Un 400 sol indicar payload incorrecte. Un 500 pot reintentar-se amb prudència.
Quina lògica no amagaria a n8n
n8n és excel·lent per orquestrar. Però si una regla és crítica, complexa o molt reutilitzada, potser hauria de viure en una API, llibreria o servei amb tests. Exemples:
- càlcul de preus;
- validació fiscal complexa;
- permisos per rol;
- scoring estratègic;
- normalització de dades compartida per diversos sistemes;
- lògica que requereix versionat estricte.
El flux pot cridar aquesta lògica, però no hauria de duplicar-la en nodes difícils de revisar.
Checklist abans de passar a producció
- El flux té owner?
- Existeix diagrama o descripció del procés?
- Hi ha entorn de prova?
- Les credencials estan separades per entorn?
- Cada acció d’escriptura és idempotent o deduplica?
- Els errors generen una alerta útil?
- Es registren IDs externs?
- Hi ha límit de reintents?
- S’ha documentat com desactivar el flux?
- S’ha provat amb dades incompletes i duplicades?
Lectures relacionades
- n8n i agents IA per a l’automatització comercial B2B
- Connectar un agent IA amb CRM, formularis i eines
- Privacitat i seguretat en agents IA comercials
- Automatització comercial amb IA
Conclusió
n8n pot ser una capa molt potent per a processos B2B, sempre que no s’usi com a calaix de sastre. Si cada flux té contracte, owner, logs, errors i idempotència, l’automatització guanya velocitat sense perdre control.
Preguntes freqüents
- n8n és adequat per integrar APIs REST B2B?
- Sí, especialment per orquestrar processos, webhooks, sincronitzacions i tasques de backoffice. S'ha de dissenyar amb contractes, errors, credencials segures i idempotència.
- Quin és el risc més gran d'una integració B2B amb n8n?
- Encadenar nodes sense contracte ni observabilitat. Això fa difícil saber què ha fallat, reintentar amb seguretat o mantenir el flux quan canvia una API.
- Què s'ha de documentar en cada flux n8n?
- Trigger, sistemes connectats, credencials, payload esperat, errors, reintents, owner, SLA operatiu i passos que requereixen revisió humana.