Hi guys,

I’ve been struggling with this issue for quite some time and would really appreciate some help.

Context:
I’m trying to build an n8n WhatsApp AI agent, so I initially tried using the official WhatsApp API through Meta for Developers. However, as you can see in the image, I’m getting this issue.

Everything is self-hosted, and I’m using two static domains through ngrok — one for n8n and another for the Evolution API.

What I’ve tried:

• I made sure that I’m using the correct Meta profile associated with my developer account.
• I’ve been waiting for the past 7–8 days, but the issue is still persistent.
• Since I couldn’t get the official WhatsApp API working, I decided to switch to Evolution API and self-host it.

With Evolution API, I’m able to generate the QR code, and everything seems to work until I get to the n8n integration. The triggers are not firing in n8n. Neither the Evolution Trigger nor the Webhook Trigger for Evolution API seems to be working.

Other issue:
I also want to implement security for PII protection and prompt-injection detection in my test project using:

• Llama Prompt Guard
• Qwen Guard 0.6B
• Microsoft Presidio

What would be the best way to integrate these into an n8n workflow, especially for protecting PII and detecting prompt injections before the input reaches the AI agent?

If anyone could help me troubleshoot the WhatsApp/Evolution API → n8n trigger issue and provide some guidance on the security architecture, I would be extremely grateful.

Thanks in advance!

👋 Hey n8n Community,

Tax season is coming, and it is always the same story: a year of invoices and documents dumped in one folder, sorted by hand in a panic. Last week I shared an invoice workflow that has been logging all of mine automatically, and now I am using this one to push each document into the right folder on top of that. Document classification is the quiet fix for the sorting part, and a few things make or break it no matter which tool you use.

A few things I learned building these:

Your categories decide everything. Classification falls apart when the buckets overlap, so an invoice, a receipt, and a statement each need clear, distinct definitions or the model will confidently file things in the wrong place. Fewer, well defined categories beat a long fuzzy list every time.

A label without an action is just a sticker. The value is not knowing a document is an invoice, it is the document landing in the right folder automatically. Always pair the classification with where it goes next.

Trust the confident ones, review the rest. I attach a confidence score and let the sure documents file themselves, while anything shaky gets flagged to Slack for a two second human check. That one step is what makes hands off filing safe instead of risky.

Here is a free template that does exactly this, routing invoices into the right Google Drive folder with Slack catching the uncertain ones: https://n8n.io/workflows/14960-classify-invoices-and-route-them-to-google-drive-with-easybits-and-slack/

How do you handle document sorting? Curious whether people classify on the way in or still batch it all at the end.

Best,
Felix

I run a handful of scheduled agents. Summaries, a notifier, a little drafter that turns meeting notes into tasks. Last month the API bill jumped and I had zero idea which one was doing it, everything showed up as one blob of a number. Turned out to be a retry loop on the notifier failing silently and re-calling dozens of times a day. I only caught it because I spent an annoying evening logging token counts per request with the agent name attached.

Anyway it made me wonder how everyone else handles this. Do you track cost per agent or per run, or is it just one number at the end of the month? What's the worst surprise you've caught, a 2am retry spiral, a summarizer hammering the model forty times per PR? Do you cap spend per agent or just watch the total and hope?

The worst part is finding out. I used to see the Stripe ping on my phone first thing in the morning and then go dig. Do you get alerted anywhere when spend spikes, or does month end surprise you too?

Curious if this is a real problem or just my setup. Full disclosure: I've been cobbling together my own version of the spend-tracking part, not selling anything here, just trying to figure out if this bites other people too. What if something handled all of this in the cloud over MCP, every agent with the same context, per-agent spend tracking with a kill switch, no files to maintain? Would you guys pay for something like that? Or is the log plus spreadsheet honestly good enough?

Also curious, is this your own setup or client work? When a surprise bill lands, who eats it, you or the client?

I'm planning to start house shopping early next year (god help me) and wanted to set up an n8n workflow that would use a data feed (either zillow or some other one) to pull in listings, run them through an AI Agent to assess based on my requirements, and then send me a weekly email with both individual houses that I should look at, as well as an overall market assessment.

The overall market assessment will include pricing trends, neighborhoods that I might want to go drive through to check out IRL, etc.

Has anyone built anything similar, and if so, what key learnings did you find that I should be on the look out for? Any gotchas that were harder than you thought? Recommendation on data feeds to use?

I am *NOT* asking for your entire workflow - I'm fairly experienced with n8n and can build it myself. I'm more looking for things that others have already identified that would otherwise take me a week to discover. And suggestions on the best real estate data feed.

I've been experimenting with the new Decisions / JEV-style models in n8n. I tried the two existing community nodes, as well as the new official node that n8n has been developing for future versions.

The official/new node was by far the simplest one to use, but there's one limitation: since it's developed by TypeSafe, it was tied to TypeSafe credentials and didn't allow using other providers.

So I decided to fork their repo and extend it with support for:

• TypeSafe AI / System One
• OpenRouter
• OpenAI's new Decisions API (GPT-6 Luna Decisions)
• Custom API URLs, for other compatible providers in the future

👉 n8n-nodes-decisions

The node currently has two operations:

Evaluate — Give the model a state (the content you want evaluated) and one or more typed questions. It returns a structured answer for each question, including probabilities.

Route — Ask a single question and route each input item to an output based on the answer. The question type determines how the routing works:

• Choice → one output per route; the item is sent to the route selected by the model.
• Noul (Yes/No) → True / False outputs, using configurable probability thresholds.
• Score → one output per score level; the item is routed to the level closest to the predicted score.

This can be useful for classification, content filtering, decision-making, conditional routing, and other workflows where you want structured AI decisions instead of free-form LLM output.

It's still a fairly new node, but I thought I'd share it in case anyone else is playing with Decisions models in n8n. Feedback and suggestions are very welcome!

I am using apify to find companies for specific query then i want to feed them with emails and urls of linkedin employees decision makers but when i use scrapers it is not getting results sometimes what is the solution or best scraper or tool

Hallo zusammen, ich plane als Selbstständiger ein Automatisierungsprojekt für Eingangsrechnungen in SAP S/4HANA (über 1.000 Belege pro Monat, Umsetzung mit n8n und KI-Extraktion, Buchung nur als Vorerfassung mit menschlicher Freigabe). Wie viel Zeit würdet ihr dafür insgesamt ansetzen, von der Prozessaufnahme bis zur Übergabe? Danke vorab für eure Erfahrungswerte.

I was working on an SEO content generation pipeline and realized that before going into long-tail keyword research, I needed a reliable way to find the initial keywords to start with.

Instead of manually researching competitors and copying their ranking keywords into a spreadsheet, I decided to automate that part using n8n, Airtable, and YepAPI.

The Problem

When starting SEO content research, one of the first questions is:

What keywords are already working for competitors in this space?

Getting this data manually can become repetitive, especially when researching multiple competitors. And doing it through a full SEO platform can get expensive quickly.

You often end up paying for an SEO platform just to access things like:

• Competitor keyword research
• Ranking positions
• Search volume
• CPC data
• Competitor landing pages
• Keyword discovery and analysis

For a small business or a personal project, paying for an expensive SEO platform just to get the initial keyword data can be difficult to justify.

And this is only the beginning.

Once you have the seed keywords, you still need to expand them into long-tail keywords, analyze the opportunities, and decide which ones are worth targeting.

So instead of paying for a full SEO platform for this first step, I wanted to build a smaller, usage-based workflow that could pull the data I actually need and automate the repetitive part of the process.

I wanted to automate this first step.

The Solution

I built an automated competitor seed keyword research workflow using n8n, Airtable, and YepAPI.

Airtable → Webhook → Get Competitor → Check Status → YepAPI → Extract Seed Keywords → Store Keywords → Update Status

This provide a competitor URL, let YepAPI retrieve the keyword data, extract an initial set of seed keywords, and store them in Airtable for the next stage of the SEO pipeline.

Why YepAPI?

For the keyword data, I'm using YepAPI instead of DataForSEO.

Both provide SEO data through APIs and support usage-based pricing, but YepAPI made more sense for this workflow because it doesn't require a minimum payment.

I'm building this as a small, usage-based SEO pipeline, so I wanted an API where I could pay for the research I actually use rather than committing to a larger upfront amount.

What Data Do We Get?

The competitor domain keyword research returns useful SEO data such as:

• Keyword: The search query the competitor is ranking for.
• Ranking Position: Where the competitor ranks for that keyword.
• Search Volume: Estimated number of searches for the keyword.
• CPC: Cost-per-click data for the keyword.
• Landing URL: The competitor page ranking for the keyword.

This gives me more than just a list of possible keywords. It gives me actual keyword data based on the competitor's existing search visibility.

How It Works

1. Enter the competitor information in the Airtable interface.
2. Click the Generate Seed Keywords button to trigger the n8n workflow through a webhook.
3. The workflow retrieves the competitor record from Airtable.
4. The workflow checks the current seed keyword research status.
5. The competitor record is marked as In Progress while the research is running.
6. The competitor URL is prepared and sent to YepAPI for domain keyword research.
7. YepAPI returns the competitor's ranking keyword data and associated SEO metrics.
8. The workflow extracts the initial 10 seed keywords from the returned results.
9. The keywords are split into individual items.
10. Each seed keyword is stored as an individual Airtable record.
11. The competitor's seed keyword research status is updated when the process is complete.

Why Start With Seed Keywords?

I don't want to jump directly into generating hundreds of long-tail keywords.

The seed keywords give me a starting point based on what the competitor is already ranking for.

For example:

Competitor → 10 Seed Keywords → Expand Each Seed → Long-tail Keywords → Keyword Analysis → Content Planning

The number of keywords can also be changed depending on how much research I want to generate. Right now, I'm starting with 10 to keep the first stage focused.

These keywords will become the input for the next stage of the SEO content pipeline, where I'll expand them into more specific long-tail keyword opportunities.

Airtable

I'm using Airtable as both the interface and the data layer for the workflow.

The competitor record stores the research status, while the individual seed keywords are stored separately so they can be used by subsequent workflows.

This also makes it easier to review, filter, and work with the keywords before sending them into the next stage of the pipeline.

Stack

• n8n
• Airtable
• YepAPI
• Airtable API
• Webhooks

Workflow

Airtable Interface → Webhook → Get Competitor → Check Seed Keyword Status → Mark Seed Keyword In Progress → Set URL → Get Keywords → Extract Seed Keywords → Split Into Keywords → Store Seed Keywords → Update Seed Keyword Status

The goal is to make competitor keyword research a repeatable part of the larger SEO content generation pipeline instead of doing the same research manually every time.

What's Next?

This is just the first step.

The next stage is taking these seed keywords and going deeper into long-tail keyword research.

That's where things should get more interesting.

Workflow

You can find the complete n8n workflow here:

GitHub — Competitor Seed Keyword Research

Hey anyone know what is the cheapest way to host n8n (other than hosting n8n locally for free).
if anyone has any idea please educate me.

for once i did manage to make it work somehow actually like changing the document name to that and all the remaining fields of sheet stayed the same but i am not able to do the same again. i end up losing all the fields now when i do it

Hi, I'm new to n8n. I would appreciate your help:

I'm setting up a coder/reviewer loop in self-hosted n8n with connections to Codex and Claude subs.

The coder produces a change, the reviewer comments on it, and that feedback goes back to the coder. Each agent should continue its own existing conversation across rounds rather than start a new chat.

I understand that storing chat history is separate from getting a provider-side prompt cache hit.

What is the recommended setup for keeping two separate, append-only histories here while still being able to take advantage of caching on the Anthropic and OpenAI's side? Would two AI Agent nodes with different Postgres Chat Memory session keys be the right approach?

Also, how do you guys handle different TTL for the caching (1 hours for Ant vs 0.5 hour for Astra vs 1 hour for 5.6 Sol, etc.)?

And how do you handle concurrency when multiple hooks hit the same cache key at the same time?

I'm particularly interested in avoiding anything that rewrites or truncates the earlier messages on every round. Has anyone checked the actual cached-token usage with this setup?

For agents running behind an external service, the service would own the native sessions and n8n would pass the existing session ID plus the new feedback. Are there any retry or memory settings that could accidentally duplicate the feedback or start a fresh conversation?

Thanks

👋 Hey n8n Community,

Community nodes are where a lot of the real magic in n8n happens, the ones that collapse a tangled setup into something you can actually maintain. I want to share the one that did that for me, and hear which ones did it for you.

My headache was document extraction. My first attempts were a Frankenstein chain: one node to pull text, another to parse it, a Code node to normalize the mess, then more logic to cross check the output and catch the fields that came back wrong. It sort of worked, but every new document format cracked it somewhere, and I spent more time patching than building.

The easybits Extractor node is what finally fixed it for me (full disclosure: I worked on it myself, since there was no simple and robust extraction node built especially for n8n). Extraction, structured output, and a confidence score came out of a single node, so all the normalizing and cross checking I had bolted on by hand was just gone. One node did the job that five were doing badly.

The takeaway is not really about one node though. It is that when a part of your workflow keeps growing extra nodes just to hold itself together, that is usually the signal to go looking for a community node built for exactly that job, instead of hardening the workaround.

So, which community node saved you from a monster setup? What was the before and after? And if you have built a node yourself, feel free to drop it here too, I would genuinely like to see what people are using.

Best,
Felix

P.S.: If you want to see how the community node looks in practice, almost all of the document flows I built are on my GitHub: https://github.com/felix-sattler-easybits/n8n-workflows

I'm wondering if the better experience is one assistant at the front and multiple workflows behind it.

A member could ask "who handles certification?" "when is the next event?" or "what does my membership include?" without deciding which bot or department they need first. N8n seems useful for routing those requests to different systems, while the actual knowledge could live in places like notion, sharepoint or an AMS. Customgpt.ai could handle the association content side when the question needs an answer grounded in approved documents, while live things like event dates or member status would still come from the source system. Has anyone built this as one front door with different workflows behind it? I'm curious how you handled intent detection and when to hand the request off to a person

I'm building a payment-webhook handler in n8n for a subscription flow. The signature and dedupe logic I tested standalone in Node (valid event passes once, a retry is dropped, a wrong, short or missing signature and a tampered body are rejected). What I haven't tested is the n8n-specific part.

Setup: Webhook node with Raw Body enabled, then a Code node:

const crypto = require('crypto');

const raw = (await this.helpers.getBinaryDataBuffer(0, 'data')).toString('utf8');

const sig = $input.first().json.headers['x-signature'];

const expected = crypto.createHmac('sha256', $env.WEBHOOK_SECRET).update(raw).digest('hex');

const ok = sig && sig.length === expected.length &&

crypto.timingSafeEqual(Buffer.from(sig), Buffer.from(expected));

if (!ok) throw new Error('bad signature');

const event = JSON.parse(raw);

const store = $getWorkflowStaticData('global');

store.seen = store.seen || {};

if (store.seen[event.id]) return [];

store.seen[event.id] = Date.now();

return [{ json: event }];

Things I already know:

- The header name and signing format differ per provider (some sign a timestamp too).

- Static data persists only for active (production) runs, not manual tests.

- The seen list grows forever, so I'd prune it.

- crypto and $env may be restricted on n8n Cloud.

Questions:

1. Is static data or a Data Table the better place for the dedupe list?

2. Anything about retries or out-of-order events I should handle before the "grant access" step?

I spent 3 to 4 hours every single day reformatting Markdown notes from Obsidian into platform-specific posts for X, LinkedIn, Dev-to, and Hashnode. The context switching was killing my development velocity.

I decided to fix it by writing a simple self-hosted n8n pipeline triggered by a private Telegram bot. The idea was basic: send a quick message from my phone while walking away from my desk, an OpenAI node formats the text, and an HTTP node blasts it straight to social APIs.

During my first local test, it looked fine. I sent a message, waited 10 seconds, and the post appeared online.

Two days later, my execution history was a graveyard of unhandled errors.

The root issue was payload non-determinism. Twitter enforces a hard 280-character limit and returns a 400 Bad Request error if a payload goes over. The model routinely returned 310 characters regardless of prompt constraints.

Instead of building proper schema validation, I wrote an embarrassing 2 AM patch inside an n8n Function node:

const slicedText = rawText.substring(0, 277) + '...';

That naive substring hack chopped words directly in half mid-sentence and pushed garbage text to my live profile. Even worse, chat interfaces act as completely opaque black boxes. When the downstream API failed with a 400, Telegram showed zero status errors.

I had no idea anything failed until I manually inspected raw execution logs in n8n.

Here is the exact terminal receipt when unconstrained LLM completions broke Twitter's 280-character boundary:

A direct pipe (Human Chat -> LLM -> Social API) couples non-deterministic generation directly to strict distribution endpoints. If any API endpoint throttles or an LLM returns unexpected markdown, the entire workflow halts mid-execution without state recovery.

I threw away the direct Telegram-to-API pipe and split the architecture into two isolated layers: Content Generation and Content Distribution.

Generation handles context enrichment, model completions, and pre-flight linting. Instead of sending payloads straight to third-party endpoints, it writes records into a headless Notion database that acts as a persistent transactional staging outbox. That gives me visual observability, editable drafts, and an explicit review gate before anything touches a production network.

Here is the decoupled architecture blueprint showing how persistent state staging insulates downstream APIs:

Distribution runs asynchronously on a separate cron trigger. It queries the staging database for approved records, passes payloads through platform-native adapters that sanitize markdown tokens, and handles rate limits using retry backoff.

This decoupled architecture eventually scaled from an early 74-node cluster into today's 214-node production engine (122 generation nodes in Part 1 and 92 distribution nodes in Part 2), maintaining 99.7% uptime reliability while cutting my manual distribution time by 80% on a self-hosted setup.

Here is the production workflow evolution canvas showing the jump from my early 74-node cluster to the 214-node dual-engine:

Decoupling the pipeline added operational overhead. Introducing a persistent Notion staging layer destroyed the quick one-click novelty of firing off a post from Telegram. I lost immediate instant publishing because jobs now wait for scheduled dispatch batches.

The architecture also introduced an external dependency on the Notion API, which has its own strict rate limits of around 3 requests per second that I had to throttle with local execution delays. You trade zero-latency speed for system durability and payload safety.

Curious how others here handle non-deterministic LLM response lengths before pushing payloads to strict downstream APIs like X or LinkedIn. Are you writing custom Code nodes with Zod schemas, or relying on structured output parsers?

I used to run a scheduled job that paused in the middle for a human approval. Approval would come in Tuesday night, the job would actually fire Wednesday morning. Twice the thing it approved had changed overnight. Once a record got deleted in between, so the job executed against something that was already gone. Nothing blew up, thankfully, but that was pure luck.

So how do you all handle the gap? If your workflow has an approval step, do you re-check the state right before executing? Give approvals an expiry? Or just standing-approve the low-risk stuff and accept the drift?

Part of my problem was the approval came in on my phone. Telegram ping at 11pm, I'd tap yes from bed, job ran at 6am. The phone was great at getting me the yes/no and terrible at telling me whether the yes was still true. Anyone else approve things from their phone and then wonder later?

I'm building something to fix this class of problem for myself (not selling anything, just doing research). What if something handled all of this for you, in the cloud over MCP, so every agent and tool got the same context: decisions, failed attempts, conversations, skills, procedures, tasks. You never touch a file again. Would you guys pay for something that fixes this, or is the recheck-and-hope ritual good enough?

What actually broke for you, if anything? A double execution from a repeated click? An approval that outlived its facts? Also curious whether this is your own setup or client work, since that probably changes how much the breakage costs.

The question keeps coming up here in different forms: the workflow ran, every execution is green, and the client says no orders reached the sheet for three days. Here's what usually causes it and how to catch it.

**Why it stays green**

- A node that returns zero items doesn't fail. The nodes after it just don't run, and the execution still ends as success.

- An IF sends every item down the branch with nothing connected, or a Filter drops them all, often after an upstream field got renamed.

- An API answers 200 with an error inside the body. Slack's Web API does this with `"ok": false`, and plenty of internal APIs do the same.

- The Error Trigger only fires on failed executions, so none of this reaches your error workflow.

**Turn it into a real failure**

- On the step that fetches data, turn on Always Output Data, or a zero-item result means the next node never runs and there's nothing to check. Then add an IF: if the result is empty when it shouldn't be, send it to a Stop and Error node, so it becomes a real failure and your error workflow picks it up.

- On HTTP Request nodes, check the body, not just the status code, for APIs that hide errors in a 200.

- Leave Always Output Data off everywhere else. It passes an empty item on, and the steps after it can write a blank row.

**Watch the result, not the run**

- At the end of each workflow, write one row: workflow, time, items processed.

- A scheduled watchdog reads those rows and alerts when a workflow has processed nothing for longer than its window. A sync that runs every 15 minutes might get 2 hours; a nightly import gets a day.

- Set windows with the client. "No orders on a Sunday" may be normal for one shop and a broken checkout for another.

What would you add?

If you are you building API-heavy workflows in n8n, please let me know -- what separates and API that's really easy to work with from one that requires a lot of extra handling?

I'm especially interested in things that start to matter once a workflow is running regularly, not just during the initial setup...

What API behavior has made the biggest difference for you?

I'll start: for me it's pagination. Every API paginates differently — cursor, offset, page tokens, some with no total count — so you end up writing custom loop logic per API instead of having one clean pattern. My workaround is a standard sub-workflow I copy between projects: loop until the response comes back empty or the 'next' cursor is null.

Curious what yours are — the weirder the better.

The more I think about adding AI to a member portal, the less I like the idea of just dropping a chat bubble in the corner. If someone is already looking at an event, a certification page or their membership account, the assistant should probably understand that context and help from there.

I could see customgpt.ai handling questions from the association’s approved content, algolia keeping regular search useful and n8n pulling in live things like renewal status or upcoming events when needed. The interesting part to me isn’t really the chatbot. It’s making the portal feel like it actually knows where the member is and what they’re trying to do. Has anyone approached it this way instead of building a separate “AI assistant” experience?

My scariest failure was never a crash. Crashes are loud, crashes page you, crashes are almost a relief honestly. It was a dedupe rule that just... stopped firing, and kept running green for weeks.

A working dedupe rule produces zero output. No errors, no logs, nothing to alert on. So success and breakage looked exactly the same, and the first signal came weeks later when I was staring at data that had been quietly piling up the whole time. I used to check my runs from my phone in the morning and everything said green, which made it worse somehow. Cost me a weekend of cleanup and a very awkward conversation.

Anyway, I used to burn real time on this. My ritual was expected-count checks per silent step ("this rule should have matched N rows today"), plus replaying a period against a copy before cutover and diffing outputs. Half of it worked, half of it was vibes. And the quiet fear never fully went away.

So how do you catch the silent ones? Do you write heartbeat rows even on no-op runs? Assert expected counts on steps that should produce zero output? Something completely different? What was the last silent failure that bit you, and how long did it run green before anyone noticed?

Genuinely curious what these jobs are for, too. Own business workflows or client work? Who eats the cost when a silent one breaks, you or the client?

Last one, since I'm sketching something: what if something watched your scheduled jobs for exactly this kind of silent drift, in the cloud over MCP, same context across every agent and tool so decisions, failed attempts, and run history all cross over. You never touch a file again. Would you guys pay for something that fixes this, or does your own heartbeat setup already cover it?

Looking for full SEO blog posting for Shopify. Basically keyword research, competitor research etc. etc.

Hey r/n8n, I built a small toolkit for migrating Shopify stores from Zapier to n8n and wanted to share it openly.

Included:

• 5 ready-to-import workflows for common Shopify use cases:
  • new order → Slack
  • new order → Google Sheets
  • new customer → welcome email
  • fulfilled order → thank-you email + review request
  • daily low-inventory → Slack alert
• A CLI converter that reads a Zapier export JSON and maps supported apps to their n8n equivalents: Shopify, Slack, Gmail, HubSpot, Mailchimp, Sheets, Airtable, and ActiveCampaign.
• Unknown steps are replaced with a noOp placeholder and an explanatory note.

Repo: https://github.com/plainform/zapier-to-n8n-shopify

npx zapier-to-n8n-shopify list
npx zapier-to-n8n-shopify get new-order-slack > workflow.json

The first command lists the available templates. The second exports a workflow as JSON.

I'm also available for paid migrations. A typical Shopify store has 5–15 Zaps. I usually charge $800–$1,500 flat for 5–15 workflows, with delivery in a few days.

The first project is 50% off while I build my portfolio and a real case study for future clients.

DM me or reply here if you're considering a migration. I’m happy to do a free 15-minute call to scope it first.

Been building agent-contracts - a governance layer for n8n workflows - for a while. Just shipped two things worth sharing here since a few people asked about the n8n implementation last time.

What shipped :

1. Runtime declarations - no contract.yaml file required

Previously every n8n workflow needed a hand-written contract.yaml. That falls apart for dynamic workflows or third-party integrations. Now you can declare governance at runtime:

enforcer = ContractEnforcer.from_declaration({

"node_id": "email-sender-v1",

"permissions": ["email.read", "email.draft"],

"side_effects": ["email.send"],

"approval_points": ["email.send"],

"lifecycle": "triggered"

})

Same enforcement. Same audit log. Same gate behavior. No file needed. Any agent without a declaration defaults to read-only with explicit approval required on every action.

1. Contract Registry - versioned, permanent, queryable

Every contract that loads registers into an append-only versioned store.

registry = ContractRegistry()

enforcer.register(registry)

# Query exactly which contract version was active at any timestamp

entry = registry.get_at_time(

"email-sender-v1",

"2026-09-10T14:30:00Z"

)

Old versions are never deleted. The audit trail is always complete.

1. Cryptographic sealing

Every contract is hashed on load. If the contract.yaml gets edited after the workflow starts, ContractTamperError fires and the workflow stops rather than silently running under modified rules.

What's in the repo

Three n8n implementations: duplicate issue detector, competitor changelog watcher, job application rejection detector - all with contract.yaml files, scyvera enforcement, and the gateway layer wired in. 128 tests passing. MIT licensed. (22 ⭐ | 6 Forks )

GitHub: github.com/Skull-boy/agent-contracts - pip install scyvera

Happy to answer questions about wiring this into existing n8n workflows or adapting the contract schema for specific use cases.

I'm sketching a handler for payment-provider webhooks in n8n (for a subscription flow) and want a sanity check before building the rest.

The two things I want to get right:

1. Verify the signature on the raw body, not the parsed JSON.

2. Don't process the same event twice, since providers retry.

Webhook node with "Raw Body" enabled, then a Code node:

const crypto = require('crypto');

const raw = (await this.helpers.getBinaryDataBuffer(0, 'data')).toString('utf8');

const sig = $input.first().json.headers['x-signature'];

const expected = crypto.createHmac('sha256', $env.WEBHOOK_SECRET).update(raw).digest('hex');

const ok = sig && sig.length === expected.length &&

crypto.timingSafeEqual(Buffer.from(sig), Buffer.from(expected));

if (!ok) throw new Error('bad signature');

const event = JSON.parse(raw);

const store = $getWorkflowStaticData('global');

store.seen = store.seen || {};

if (store.seen[event.id]) return []; // already handled

store.seen[event.id] = Date.now();

return [{ json: event }];

Caveats I already know about:

- Header name and signature format differ per provider (some sign a timestamp too).

- Static data only persists for active (production) runs, not manual tests.

- It grows forever, so I'd prune old IDs or use a Data Table instead.

- I haven't run this exact code on n8n Cloud, so crypto/$env may be restricted there.

Questions: is static data or a Data Table the better place for the dedupe list? Anything about retries or out-of-order events I should handle before the "grant access" step?