integrations

Integrations

Per-service playbooks. Each integration entry covers the things that aren't in the vendor docs but bite you the first time you wire a workflow up: auth model, rate limits, idempotency behaviour, recommended node settings, and known footguns.

Currently documented

• HTTP Request (generic) — base patterns for any REST integration.
• OpenAI / Anthropic LLM calls — request shape, retries, cost-aware patterns.
• Slack — webhook vs bot token, rate limits, message threading.
• Google Sheets — append vs update, batching, quota behaviour.
• Postgres — connection pooling in long-running workflows.

HTTP Request (generic)

• Always set a sane timeout. Workflow runtimes default to "forever" surprisingly often.
• Set a User-Agent that identifies the workflow library and the workflow ID. Makes vendor abuse reports actionable.
• Treat any 4xx as terminal unless it is 408, 425, or 429.
• Combine with the bounded retry pattern.

OpenAI / Anthropic LLM calls

• Pin the model ID explicitly. Aliases like latest will change behaviour silently.
• Set max_tokens low enough that runaway generations don't drain budget; raise it deliberately when needed.
• Capture both prompt and completion in the workflow's audit log when a downstream system depends on the output — needed for later debugging and for learning events.
• Use streaming only when the consumer can actually consume a stream. Otherwise it adds latency without benefit.
• LLM calls fail in ways HTTP retries can't fix (refusal, schema mismatch, hallucinated tool calls). Validate the shape of the response, not just the HTTP status.

Slack

• Incoming webhooks are simple but cannot read or update messages. If a workflow needs to edit or thread, use a bot token.
• Slack rate-limits per-method, not per-app. Posting messages is 1/sec per channel for most workloads — design batched updates accordingly.
• Always send thread_ts when replying. Without it, related updates appear as separate top-level messages.

Google Sheets

• "Append" and "update" are different APIs with different quotas. Mixing them in a hot loop trips the per-minute write quota fast.
• Batch writes wherever possible — a single values.batchUpdate with 100 rows costs the same quota as one row.
• The "row index" returned after an append is not stable if other writers are active. Don't store it as a foreign key.

Postgres

• n8n's Postgres node opens a fresh connection per execution by default. In a workflow library running thousands of executions, a poorly tuned Postgres will run out of connections before it runs out of CPU.
• Use a connection pooler (PgBouncer) in front of Postgres for any workflow that runs on a schedule shorter than ~1 minute.
• Wrap multi-statement workflows in an explicit transaction — the default per-statement autocommit will leave partial state behind if a later node fails.

---

This list is not complete. It seeds the structure. Additional integrations will be added as they are extracted from the existing workflow collection during audits.

Integration labels referenced by Expansion Pack V0

The generated pack at workflows/generated/open-workflow-library-v0/ uses symbolic integration labels (e.g. crm, helpdesk, ats, ehr, scheduling, warehouse, paging, ci, llm-service). These are symbolic only — every actual HTTP call in the generated workflows points at a placeholder URL and carries no real credentials.

The labels are intended as anchor points for future wiki entries: when a real integration playbook is written for, say, helpdesk, every generated template tagged with that label becomes a natural example.

This does not mean the wiki has learned anything from the pack automatically. The connection between labels and playbooks is a curation step that has not been done yet.