n8n integration in production: credentials, environments and webhook boundaries

Credentials should belong to accounts the business controls, not to the personal account of whoever built the workflow. If the builder leaves or the consultant's engagement ends, the integration should keep running and the business should still be able to rotate every key.

n8n's guidance on sharing credentials explains that a credential can be shared with users or with a project, and that people using a shared credential cannot view or edit its details. I would use that model deliberately: a small number of owners who can see and rotate secrets, and builders who can use them without reading them.

For each credential, record what system it accesses, what scopes or roles it has, who owns it, and when it was last rotated. Grant the narrowest access the workflow needs. An integration that only creates tasks should not hold an administrator token for the whole project management system.

Editing a live workflow directly is the fastest way to break something customers depend on. n8n's source control and environments feature uses Git to back multiple environments, so work can move from a development instance to production through a reviewed change. The documentation lists it as a Business and Enterprise feature that an instance owner or admin enables, and notes that project admins can push changes but cannot pull them.

If your edition does not include it, the principle still applies. Keep a separate instance or at least separate workflows for testing, export workflow definitions into version control, and make production changes through a documented step rather than live edits.

Environment-specific values such as API base URLs, test versus live accounts, and notification channels should not be hard-coded into nodes. When they are, promoting a workflow from test to production quietly points it at the wrong system.

Webhooks are public entry points. The Webhook node documentation describes separate test and production URLs, with the production webhook registered when the workflow is published, and supports requiring Basic, Header or JWT authentication from callers.

I would require authentication on every production webhook unless there is a specific reason not to, and validate the payload before any node acts on it. Check that required fields are present, that identifiers have the expected format, and that the request refers to records the caller is allowed to affect. Reject anything else early with a clear status.

Test URLs should never be shared outside the build team. A test URL that ends up in a form or a partner's configuration becomes an unmonitored production path.

Every integration fails eventually. n8n's documentation on handling errors describes error workflows that run when an execution fails. I would set one up before launch and route it to a named owner with enough context to act: the workflow, the business record affected, the failed step and a link to the restricted execution view.

Keep secrets and unnecessary client data out of alert messages. A link to the execution is better than pasting a payload into a shared chat channel.

Retries need care. Repeating a read is usually safe. Repeating a write may create duplicates or send a second message. For each step with side effects, decide whether it can be repeated, how a duplicate would be detected, and what a person should check before retrying by hand.

Many n8n workflows now include a model step that classifies an email, extracts fields from a document or drafts a reply. Treat that step's output as untrusted input to the rest of the workflow. Validate it against a schema, reject values outside the allowed set, and route uncertain cases to a person.

A model should not choose which credential to use, which system to write to, or which customer record to change based on text in an incoming message. Those choices belong in the workflow's fixed logic, where they can be reviewed and tested.

Before go-live, agree who receives failure alerts, who can pause the workflow, who approves changes, and who renews credentials before they expire. Store that with the workflow, along with a short runbook for the most likely failures.

The acceptance condition I would use: the workflow runs under business-owned credentials with documented scopes, production changes go through a tested path, every webhook rejects unauthenticated and malformed requests, and a forced failure reaches the named owner with enough information to act.

Bring the workflows you have, where they run today and which systems they touch.