AgentRaaS sits between your AI agents and every real-world action — guaranteeing exactly-once execution, proven under real concurrent load, not just claimed. Self-hosted or cloud.
From dedup.test.js's own concurrency test — clone the repo and run npm test to reproduce it yourself.
Thousands of teams run n8n, Flowise, Langflow, Dify, Ollama, and LocalAI on their own Docker infrastructure — to cut SaaS fees, and to stay inside GDPR / EU AI Act data-residency rules. AgentRaaS is built to sit inside that stack, not replace it: one more Docker Compose service, zero data leaving infrastructure you control.
Result: the customer is charged twice, and you find out from a support ticket, not a log.
Result: two duplicate contacts, a messier pipeline, and a sales team that stops trusting the data.
Result: the client gets the same update twice — and starts wondering what else is off.
Result: your team approves the same request twice, or gets paged twice for one incident.
Your agent sends the request to AgentRaaS instead of the API directly.
AgentRaaS atomically claims a dedup slot for that exact request in Redis.
First call: forwarded to the real API, the result gets cached.
Retry or duplicate: the cached result comes back — never a second real execution.
Idempotency-Key header is genuinely enough. You don't need this.The honest case for AgentRaaS is narrower and specific: not every provider has native idempotency (Stripe does; Twilio, Slack, most SaaS/CRM APIs, and any custom internal endpoint don't) — no-code tools can't set the header at all (n8n, Make, and Zapier give you a URL field, not a place to compute and attach an idempotency key) — and none of them give you one audit trail across services (Stripe's idempotency keys only tell you what happened inside Stripe; an agent calling Stripe, Twilio, and a custom CRM endpoint in the same run has zero unified record of which of those three actually fired).
| DIY idempotency keys | AgentRaaS | |
|---|---|---|
| Code changes | Modify every API call, only where the provider supports it | Change the URL |
| No-code support | ❌ Not possible — no-code tools can't set custom headers | ✅ Paste webhook URL (n8n, Make, Zapier) |
| Providers without native idempotency | Build your own dedup logic, per provider | One proxy, same guarantee, every service |
| Multiple services | Different logic per API | One proxy, all services — plus any custom endpoint |
| Credential management | Build yourself | Self-serve, encrypted at rest |
| Validation, circuit breaker, rate limiting | Build yourself | Built-in |
| Audit trail, dashboard | Per-provider at best | One trail across every service you call |
AgentRaaS sits in the request path between your agent and the real API. If it's unreachable, your call to it fails — it does not silently succeed un-deduped. There is no fallback path anywhere in the SDK, the n8n node, or the MCP gateway that quietly calls Stripe or Twilio directly when AgentRaaS doesn't respond. That's deliberate: the alternative — routing around an outage — would mean the exact retry-storm double-charge scenario this product exists to prevent happens silently, at the one moment you'd least want it to. Treat AgentRaaS like any other proxy or database on your critical path: standard timeout and retry handling on the calling side applies, same as it would for any dependency.
Honest gap: we haven't published real p99 latency numbers yet. Self-hosted, it's one network hop to a service running on your own infrastructure — not a call out to us — but we're not going to put a number here we haven't actually measured. That's on the roadmap, not fabricated in this paragraph.
Model Context Protocol is the standard Claude Desktop, Cursor, and agent frameworks like LangChain, AutoGen, and CrewAI use to invoke tools. A stalled tool call gets retried just like a stalled HTTP request — same double-execution risk, different protocol. AgentRaaS's MCP gateway is a JSON-RPC proxy that applies the exact same atomic dedup guarantee to every tool call, not just webhooks.
n8n, Make, Zapier, or raw curl — change the target URL, nothing else.
POST /proxy/:service/:action
A clean per-service REST shape for scripts and internal tools.
POST /v1/sdk/:service/:action
Claude Desktop, Cursor, LangChain, AutoGen, CrewAI — any MCP client.
POST /mcp
# agent calls a tool via MCP POST /mcp {"jsonrpc":"2.0","id":"call_82f1","method":"tools/call", "params":{"name":"stripe.createCharge", "arguments":{"amount":4200,"customer":"cus_9f2k"}}} → 200 OK // first call — forwarded, result cached {"result":{"status":"success","charge_id":"ch_1N..."}} # network stalls — agent retries the identical call 400ms later → 200 OK // dedup slot already claimed — cached result, zero re-execution {"result":{"status":"success","charge_id":"ch_1N...", "deduplicated":true}}
AgentRaaS doesn't care what your agent is for — only that when it acts, it acts exactly once. If it can call an API, AgentRaaS can protect it.
Resolve tickets, send replies, trigger refunds — without a retry turning into two replies or two refunds.
Log leads, update deals, enrich contacts in HubSpot or Salesforce — once per real event, not once per retry.
Book meetings, send confirmations, post status updates to a client — exactly the number of times you meant to.
Post to Slack directly, or Microsoft Teams via Custom Actions — trigger approvals, hand off work between systems, SSRF-guarded.
Update inventory, create orders, notify shipping — protected the same way whether it's Shopify or your own warehouse API.
Not on the curated list? Register it as a Custom Action in minutes — same dedup, same audit trail, same protection.
Building client workflows in n8n or Make? Drop AgentRaaS in front of every client's Stripe, CRM, or messaging API so one retry storm doesn't double-charge a client account. The Agency plan adds a white-label dashboard per client tenant.
Every piece your agents need to take real actions safely, out of the box.
Proven under real concurrent load with an automated test suite — not just a claim.
Add your own Stripe, Twilio, or any provider's keys — encrypted at rest, no server access needed.
Not limited to the curated list — register any endpoint, SSRF-guarded, and agents can call it too.
A JSON-RPC gateway for Claude Desktop, Cursor, and any MCP client — every call protected the same way.
Stop hammering a broken upstream service. Trips open, recovers automatically.
Every action logged — who, what, when, status, duration. Searchable dashboard, CSV export.
* via Custom Actions — not a pre-built connector, but reachable the same way any endpoint is: register it once, agents call it by name from then on.
You're being asked to hand this a live Stripe or Twilio key — that shouldn't come from an anonymous handle. I'm an infrastructure engineer with six years in production systems, and I built AgentRaaS, alone, after watching a retry storm double-charge a customer at 2 AM. Every line of the dedup engine, the SDK, and this site is mine to answer for.
Open-core: the engine is MIT/Apache-2.0, genuinely open. Community is free and self-hosted only. Pro, Agency, and Enterprise all run either cloud-hosted or self-hosted, and unlock the separately-licensed enterprise module.
Want to try it without installing anything? Start a free AgentRaaS Cloud account →
The core engine is MIT/Apache-2.0 — genuinely open, no restrictions. Pro/Agency/Enterprise features (src/ee/) are a separate module under a fair-code/source-available commercial license modeled on n8n's Sustainable Use License — full terms in LICENSE.md.
The short, honest answers — full detail is in the docs and LICENSE.md.
Yes. Community, Pro, Agency, and Enterprise are all unlimited actions/month when you run them on your own infrastructure — no cap, no metering, no phone-home check. It's a term of LICENSE.md, not a "soft" limit we quietly enforce. The only metered tier is the free AgentRaaS Cloud account (500 actions/month) — because that one runs on our infrastructure, not yours. Pro/Agency/Enterprise features on a self-hosted instance unlock via a license token you paste into your own .env once at setup, verified entirely offline — never a network call back to us.
Pro ($20/mo) is for an individual builder past the free tier's usage cap — 3 seats and the Human-in-the-Loop approval gateway. Agency ($100/mo) adds multi-tenancy, white-label branding, and inbound webhook receivers — built for agencies managing multiple client workspaces under one dashboard, with 10 seats. Enterprise (custom pricing) adds everything needed for a production multi-team deployment: unlimited seats, active-active HA clustering, PII/DLP redaction, and SAML/OIDC SSO with RBAC. All three run cloud-hosted or self-hosted.
Self-hosted means your audit log, credentials, and traffic never leave infrastructure you control — we don't see any of it. Stored credentials are encrypted at rest (AES-256-GCM), and the Enterprise tier adds PII/DLP redaction before anything touches the audit log, plus tamper-evident, SIEM-exportable logging for compliance-sensitive teams.
Yes — AgentRaaS is a proxy, not an SDK, so no-code tools work the same way code does: point the HTTP Request node at your AgentRaaS URL instead of the API directly. No custom node install required for any of them.
AgentRaaS claims an atomic dedup slot in Redis before anything real happens. The first call gets forwarded and its result cached; any retry or duplicate — even concurrent ones — gets the cached result back instead of a second real execution. This is tested under real concurrent load, not just claimed (see npm test).
The core engine (src/core/ — payload dedup, MCP gateway, dashboard) is MIT/Apache-2.0. Enterprise features (src/ee/ — SSO, HMAC, DLP, distributed rate limiting) are source-available under a separate commercial license. See LICENSE.md for the exact terms.
agentgateway (a Linux Foundation project) is an edge proxy for AI traffic — auth, RBAC, rate limiting, and observability across all your MCP/tool servers, not just AgentRaaS. If you already run it (or want to), AgentRaaS drops in as a backend behind it with zero code changes on either side — see Getting started for the one-command setup. Most self-hosters don't need this; it matters once you're managing more than one MCP server behind a shared gateway.