\n\n---\n\nexe-gateway is a self-hosted messaging gateway that connects WhatsApp, Telegram, Discord, Slack, Email, iMessage, Signal, Webchat, and Webhooks behind a single REST API. It handles rate limiting, typing simulation, and multi-account support out of the box — so your messages look human, not automated.\n\n## Features\n\n| Feature | Details |\n|---------|---------|\n| **10 platform adapters** | WhatsApp (Baileys), Telegram (Grammy), Discord, Slack, Email (SMTP/IMAP), iMessage, Signal, Webchat, Webhook, CRM |\n| **Multi-account** | Unlimited numbers per platform. Each account gets its own session and rate limiter. |\n| **Human-like sending** | Typing simulation, randomized delays between messages, per-recipient pacing. |\n| **Anti-ban rate limiting** | Per-platform hourly/daily caps tuned to each platform's tolerance. |\n| **Full history sync** | First WhatsApp link pulls complete message history. |\n| **REST API** | Send messages, list groups, check contacts, view rate limits, health checks. |\n| **One-command install** | Single `curl` command sets up Node.js, clones the repo, builds, configures systemd. |\n| **Production-ready** | Systemd service, nginx config, Docker support, security-hardened. |\n| **Standalone** | Works on its own. Optional hooks for [Exe OS](https://github.com/AskExe/exe-os) integration. |\n\n## Quick Start\n\n### One-command install (VPS — Ubuntu 22.04+ / Debian 12+)\n\n```bash\ncurl -fsSL https://raw.githubusercontent.com/AskExe/exe-gateway/main/install.sh | bash\n```\n\nThis installs Node.js 20, clones the repo to `/opt/exe-gateway`, builds from source, creates a system user, writes `/home/exe/.exe-os/gateway.json`, writes `/etc/exe-gateway/exe-gateway.env`, and installs the systemd service.\n\n### Pair WhatsApp\n\n```bash\nsudo -u exe node /opt/exe-gateway/pair-whatsapp.mjs my-account +1234567890\n```\n\nThe pairing script reads the same config and proxy settings as the gateway, then stores the session under `/home/exe/.exe-os/.auth/`.\n\n### Start the service\n\n```bash\nsystemctl start exe-gateway\n```\n\n### Verify\n\n```bash\ncurl -H \"Authorization: Bearer \" http://127.0.0.1:3100/health\n```\n\nThe raw auth token is shown once during installation; only its SHA-256 hash is stored in `/etc/exe-gateway/exe-gateway.env`.\n\n### Manual install (any platform)\n\n```bash\ngit clone https://github.com/AskExe/exe-gateway.git\ncd exe-gateway\nnpm ci\nnpm run build\nmkdir -p ~/.exe-os\ncp deploy/gateway.example.json ~/.exe-os/gateway.json\ncp deploy/.env.example .env\nset -a && source .env && set +a\nnode dist/bin/exe-gateway.js\n```\n\n## WhatsApp IP Safety\n\n> **Running on a local machine (laptop, home server, office network)?**\n>\n> You're already on a residential IP — **skip this section entirely**. Tailscale is not needed. Just install, pair, and go.\n\nWhatsApp actively detects and bans datacenter IP addresses. If you're running exe-gateway on a VPS or cloud server (AWS, DigitalOcean, Hostinger, Hetzner, etc.), you must route WhatsApp traffic through a residential IP.\n\n### Why this matters\n\nConnecting WhatsApp directly from a datacenter IP will trigger verification loops or outright bans. This is WhatsApp's anti-automation measure — it flags IPs that belong to known hosting providers.\n\n### Solution A: SOCKS proxy (recommended)\n\nRoute only WhatsApp traffic through your home machine via a lightweight SOCKS5 proxy over Tailscale. This avoids routing ALL VPS traffic through the exit node, which can break Cloudflare and other services.\n\n```\nVPS (Cloud/Datacenter) Home Machine\n┌─────────────────────────┐ ┌─────────────────────────┐\n│ exe-gateway │ │ microsocks (SOCKS5) │\n│ Baileys + SocksProxy │◄─────────►│ bound to Tailscale IP │\n│ (only WhatsApp traffic) │ Tailscale │ (residential IP) │\n└─────────────────────────┘ mesh └─────────────────────────┘\n ↓\n WhatsApp servers\n see: residential IP\n```\n\n**1. Install a SOCKS5 proxy on your home machine:**\n\n```bash\n# macOS\nbrew install microsocks\nmicrosocks -i $(tailscale ip -4) -p 1080 &\n\n# Linux\napt install microsocks\nmicrosocks -i $(tailscale ip -4) -p 1080 &\n```\n\n**2. Configure exe-gateway to use the proxy:**\n\n```bash\n# In /etc/exe-gateway/exe-gateway.env\nWHATSAPP_PROXY_URL=socks5://:1080\n```\n\n**3. Verify:**\n\n```bash\n# From VPS — should show your home IP\ncurl --socks5-hostname :1080 https://ifconfig.me\n```\n\n### Solution B: Tailscale exit node (simpler but routes all traffic)\n\nRoute ALL VPS traffic through a home machine using Tailscale's exit node feature. Simpler setup but can interfere with Cloudflare, nginx, and other services on the VPS.\n\n```bash\n# Home machine\ntailscale up --advertise-exit-node\n\n# VPS\ntailscale set --exit-node=\n\n# Verify\ncurl -s ifconfig.me # Should show HOME IP\n```\n\n**Warning:** Exit node routes all traffic, including return paths for inbound connections. If your VPS serves websites behind Cloudflare or a reverse proxy, use Solution A instead.\n\nSee [`docs/tailscale-exit-node.md`](docs/tailscale-exit-node.md) for troubleshooting, DNS issues, firewall config, and keeping the exit node online.\n\n## Multi-Account Configuration\n\nRuntime config lives at `~/.exe-os/gateway.json` by default, or the path set in `EXE_GATEWAY_CONFIG`. Secrets and environment overrides live in `/etc/exe-gateway/exe-gateway.env` in the installer flow.\n\nFor PostgreSQL you can either set `DATABASE_URL=postgresql://user:pass@host:5432/dbname` or use the split `EXE_GATEWAY_DB_*` variables from `deploy/.env.example`.\n\n```json\n{\n \"port\": 3100,\n \"whatsappVerifyToken\": \"\",\n \"adapters\": {\n \"whatsapp\": {\n \"enabled\": true,\n \"credentials\": {\n \"app_secret\": \"set-if-you-use-meta-whatsapp-webhooks\"\n },\n \"accounts\": [\n {\n \"name\": \"sales\",\n \"authDir\": \"/home/exe/.exe-os/.auth/whatsapp-sales\"\n },\n {\n \"name\": \"support\",\n \"authDir\": \"/home/exe/.exe-os/.auth/whatsapp-support\"\n }\n ]\n },\n \"telegram\": {\n \"enabled\": true,\n \"accounts\": [\n {\n \"name\": \"main-bot\",\n \"bot_token\": \"123456:ABC-DEF...\",\n \"secret_token\": \"set-if-you-use-telegram-webhooks\"\n }\n ]\n },\n \"discord\": {\n \"enabled\": true,\n \"accounts\": [\n {\n \"name\": \"community-bot\",\n \"bot_token\": \"your-discord-token\",\n \"public_key\": \"set-if-you-use-discord-interactions\"\n }\n ]\n },\n \"slack\": {\n \"enabled\": true,\n \"accounts\": [\n {\n \"name\": \"workspace-bot\",\n \"bot_token\": \"xoxb-...\",\n \"app_token\": \"xapp-...\"\n }\n ]\n },\n \"email\": {\n \"enabled\": true,\n \"accounts\": [\n {\n \"name\": \"notifications\",\n \"smtp_host\": \"smtp.example.com\",\n \"smtp_port\": \"587\",\n \"smtp_user\": \"bot@example.com\",\n \"smtp_pass\": \"your-password\",\n \"from_address\": \"bot@example.com\"\n }\n ]\n }\n }\n}\n```\n\nAdmin API bearer tokens are hashed at rest. Save the raw token once during install; the installer persists only `EXE_GATEWAY_AUTH_TOKEN_HASH` in `/etc/exe-gateway/exe-gateway.env`.\n\nIf you expose inbound provider webhooks, configure the matching signature secret in `gateway.json`:\n\n- **WhatsApp (Meta Cloud API):** `adapters.whatsapp.credentials.app_secret` → validates `X-Hub-Signature-256`\n- **Telegram:** `accounts[].secret_token` (or adapter-level `secret_token`) → validates `X-Telegram-Bot-Api-Secret-Token`\n- **Discord interactions/webhooks:** `accounts[].public_key` (or adapter-level `public_key`) → validates the Ed25519 signature headers\n\nPair each WhatsApp account separately:\n\n```bash\nsudo -u exe node /opt/exe-gateway/pair-whatsapp.mjs sales +1234567890\nsudo -u exe node /opt/exe-gateway/pair-whatsapp.mjs support +0987654321\n```\n\n## API Reference\n\n`/api/*` and `/v1/usage/*` require the `Authorization: Bearer ` header (except `/health`).\nProvider webhook routes use provider-specific signature validation instead of the admin bearer token.\n\n| Method | Endpoint | Description |\n|--------|----------|-------------|\n| `GET` | `/health` | Server health, uptime, registered platforms |\n| `POST` | `/api/send` | Send a message (rate-limited, with typing simulation) |\n| `GET` | `/api/groups` | List WhatsApp groups |\n| `GET` | `/api/group/:id` | Group metadata + participants |\n| `GET` | `/api/limits` | Rate limit stats per platform |\n| `POST` | `/webhook/:platform` | Incoming webhook payload from external platform |\n\n### Send a message\n\n```bash\ncurl -X POST http://127.0.0.1:3100/api/send \\\n -H \"Authorization: Bearer \" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"platform\": \"whatsapp\",\n \"account\": \"sales\",\n \"to\": \"+1234567890\",\n \"text\": \"Hey — just following up on our conversation.\"\n }'\n```\n\nThe message enters the outbound queue and is sent with realistic typing simulation and randomized delay. You don't need to manage pacing — the limiter handles it.\n\n### List groups\n\n```bash\ncurl -H \"Authorization: Bearer \" http://127.0.0.1:3100/api/groups\n```\n\n### Check rate limits\n\n```bash\ncurl -H \"Authorization: Bearer \" http://127.0.0.1:3100/api/limits\n```\n\n## Rate Limiting\n\nOutbound messages are paced per-platform with human-like timing. These are the defaults — tuned to avoid platform bans:\n\n| Platform | Per Hour | Per Day | Typing Simulation | Delay Between Messages |\n|----------|----------|---------|-------------------|----------------------|\n| WhatsApp | 30 | 200 | 1.5–8s (25 cps) | 5–15s per recipient |\n| Telegram | 60 | 500 | 1–5s (40 cps) | 2–8s per recipient |\n| Discord | 120 | 1,000 | 0.5–4s (50 cps) | 1–5s per recipient |\n| Slack | 120 | 1,000 | 0.5–4s (50 cps) | 1–5s per recipient |\n| Email | 20 | 100 | None | 10–30s per recipient |\n\nInbound messages are also rate-limited: 10 req/s per sender, 100 req/s global (sliding window).\n\n## Teddy Memory Scope\n\nTeddy is read-only by default. You can further restrict which agent memories Teddy can read:\n\n```bash\n# Empty = all readable memory. Example below restricts memory reads to Mari/CMO only.\nEXE_GATEWAY_TEDDY_MEMORY_AGENTS=mari\n```\n\nThis is enforced in Teddy's tool handlers, not just the prompt. Requests for non-allowed agents return an access denied message.\n\n## Automated Outbound Guardrail\n\nAutomated outbound is **deny-by-default**. A fresh install can ingest and store WhatsApp messages, but it will not send bot responses, rate-limit notices, or auto-replies until an explicit response scope is configured.\n\nThere are three separate permission categories:\n\n1. **DM sender** — respond to this person only in direct messages.\n2. **Whole group** — respond to any allowed message in a specific group.\n3. **Specific person in group** — respond only when a specific number/JID speaks inside a group.\n\n```bash\n# empty = ingest-only, no automated replies\nEXE_GATEWAY_RESPONSE_ALLOW_DMS=\nEXE_GATEWAY_RESPONSE_ALLOW_GROUPS=\nEXE_GATEWAY_RESPONSE_ALLOW_GROUP_PARTICIPANTS=\n\n# DM only with one person\nEXE_GATEWAY_RESPONSE_ALLOW_DMS=+16179354486,16179354486@s.whatsapp.net\n\n# Whole group by group JID\nEXE_GATEWAY_RESPONSE_ALLOW_GROUPS=120363428671509944@g.us\n\n# Specific person in any group, or scoped to one group\nEXE_GATEWAY_RESPONSE_ALLOW_GROUP_PARTICIPANTS=+16179354486\nEXE_GATEWAY_RESPONSE_ALLOW_GROUP_PARTICIPANTS=120363428671509944@g.us:+16179354486\n\n# Optional group command gate: even allowlisted groups/participants only get replies\n# when the message starts with /ted or /ted. DMs are unaffected.\nEXE_GATEWAY_RESPONSE_GROUP_PREFIX=/ted\n# Optional group stop command: allowed group speakers can send /stop to suppress\n# an in-flight/stale group response. Default in code: /stop. Empty disables.\nEXE_GATEWAY_RESPONSE_GROUP_STOP_COMMAND=/stop\n\n# Legacy DM alias still supported\nEXE_GATEWAY_RESPONSE_ALLOW_CONTACTS=+16179354486\n\n# Emergency switch: true ignores all group response scopes\nEXE_GATEWAY_RESPONSE_DM_ONLY=false\n```\n\nA DM allowlist never grants group response permission. This guard applies even if a bot is registered as the default route. It exists to prevent a newly linked WhatsApp account from unexpectedly messaging contacts or groups.\n\n### Teddy delegated sends\n\nTeddy can be allowed to send WhatsApp text messages on Henry/operator's behalf from an approved DM. This is **not** auto-response: Teddy only sends when the approved operator explicitly asks it to send a specific message to a specific chat/contact.\n\n```bash\n# Empty = disabled. If unset, Teddy falls back to EXE_GATEWAY_RESPONSE_ALLOW_DMS.\nEXE_GATEWAY_OPERATOR_SEND_ALLOW_DMS=+16179354486\n```\n\nGuardrails:\n- only approved direct-message senders get this write permission;\n- group prompts never grant delegated send permission;\n- Teddy can only use the `send_whatsapp_message` tool, not Exe OS task/memory writes;\n- recipient is resolved from stored WhatsApp groups/contacts, or an explicit JID/phone.\n\n### Operator notifications for contact segments\n\nOperator notifications are separate from auto-response. They do **not** reply to the sender. They send a private alert to configured operator DMs when a watched contact messages the gateway.\n\nThis supports local/operator-defined contact segments using a suffix convention such as `(Alpha)`, `(VIP)`, or `(Agency)`. The segment is not hardcoded; it is configured per deployment.\n\n```bash\n# OFF by default\nEXE_GATEWAY_CONTACT_SEGMENT_NOTIFY_ENABLED=false\n\n# When enabled, contacts whose alias/saved/local/display/push/profile name ends\n# with this suffix trigger an operator notification.\nEXE_GATEWAY_CONTACT_SEGMENT_NOTIFY_NAME_SUFFIX=\"(Alpha)\"\n\n# Send the alert to these operator DMs.\nEXE_GATEWAY_CONTACT_SEGMENT_NOTIFY_RECIPIENTS=+16179354486\n\n# Default false: only notify for DMs to the gateway, not group chatter.\nEXE_GATEWAY_CONTACT_SEGMENT_NOTIFY_INCLUDE_GROUPS=false\n```\n\n## Auto-Reply\n\nAutomatic replies for incoming messages — **disabled by default**, allowlist-gated, with 8 safety gates to prevent spam. Auto-reply `allowContacts` / `allowGroups` also opt those exact senders into the global automated outbound allowlist.\n\nAdd to `gateway.json`:\n\n```json\n{\n \"autoReply\": {\n \"enabled\": true,\n \"message\": \"Received. We'll get back to you shortly.\",\n \"allowGroups\": [\"120363428671509944@g.us\"],\n \"allowContacts\": [\"+16179354486\"],\n \"cooldownHours\": 24,\n \"dailyCap\": 20,\n \"dmOnly\": false\n }\n}\n```\n\n| Setting | Default | Description |\n|---------|---------|-------------|\n| `enabled` | `false` | Master switch. No replies sent unless explicitly `true`. |\n| `message` | `\"Received.\"` | Text to send as the auto-reply. |\n| `allowGroups` | `[]` | Only reply in these group JIDs. Empty = no group replies. |\n| `allowContacts` | `[]` | Only reply to these phone numbers/JIDs. Empty = no DM replies. |\n| `cooldownHours` | `24` | Minimum hours between replies to the same contact. |\n| `dailyCap` | `20` | Maximum total auto-replies per day across all contacts. |\n| `dmOnly` | `false` | If `true`, blocks all group replies regardless of `allowGroups`. |\n\n**Safety gates (always enforced, not configurable):**\n\n1. Must be explicitly enabled (default OFF)\n2. Never replies to historical/sync messages\n3. Never replies to your own messages\n4. Never replies to empty or system messages\n5. Never replies to read receipts, reactions, or calls\n6. Only replies to allowlisted groups or contacts (must have at least one allowlist)\n7. Per-contact cooldown (default 24h)\n8. Daily cap (default 20)\n\nAuto-replies include a random 3–15 second delay and typing indicator simulation to appear human.\n\n## Read-Only Mode\n\nBackground conversation monitoring — receives and stores all messages with zero bot footprint. No auto-reply, no typing indicators, no read receipts, no outbound sends.\n\nAdd to `gateway.json`:\n\n```json\n{\n \"readOnly\": true,\n \"database\": { \"host\": \"...\", \"port\": 5432, \"user\": \"...\", \"password\": \"...\", \"database\": \"...\" }\n}\n```\n\nWhat happens in read-only mode:\n\n| Behavior | Status |\n|----------|--------|\n| Receive messages | ✅ Normal |\n| Store to PostgreSQL | ✅ Normal |\n| Pipeline ingest (CRM, contacts) | ✅ Normal |\n| History sync | ✅ Normal |\n| Auto-reply | 🔴 Force disabled |\n| Bot responses | 🔴 Suppressed |\n| Typing indicators | 🔴 Suppressed |\n| POST /api/send | 🔴 Rejected (403) |\n| Online presence | 🔴 Already off (`markOnlineOnConnect: false`) |\n\nThe `/health` endpoint shows `\"mode\": \"read-only\"` when active.\n\nCombine with `storageFilter` to selectively ingest only specific groups/contacts.\n\n## Data Ingestion Adapters\n\nexe-gateway serves as the data ingestion layer for the Exe platform. It runs API adapters (cron or webhook) that pull data from clients' external systems and stage it for routing into the wiki and CRM.\n\n### How it works\n\n```\nExternal APIs → exe-gateway adapters → staging.raw_imports → (routing handled downstream)\n```\n\nThe gateway's job is to **pull and stage** — it does not route data into wiki or CRM schemas. Routing happens in a separate transform step after staging.\n\n### Adapter lifecycle\n\n1. Adapter runs on a configurable schedule (cron: 15min / hourly / daily)\n2. Checks `staging.sync_cursors` for the last pull position per source\n3. Pulls new/updated records from the external API\n4. Writes raw JSON to `staging.raw_imports` (same Postgres instance, `staging` schema)\n5. Updates `sync_cursors` with the new position\n\nFor platforms that support it (Stripe, Asana), webhooks provide real-time ingestion alongside cron-based pulls.\n\n### Supported adapters (current / planned)\n\n| Adapter | Protocol | Status |\n|---------|----------|--------|\n| Xero | OAuth 2.0 REST | Planned |\n| Stripe | REST + Webhooks | Planned |\n| Asana | REST + Webhooks | Planned |\n| Banking APIs | Open Banking REST | Planned |\n| QuickBooks | OAuth 2.0 REST | Planned |\n\n### Configuration\n\nEach adapter is configured via environment variables:\n\n```bash\n# Example: Xero adapter\nXERO_CLIENT_ID=your-client-id\nXERO_CLIENT_SECRET=your-client-secret\nXERO_TENANT_ID=your-tenant-id\nXERO_SYNC_INTERVAL=hourly # 15min | hourly | daily\n```\n\n### Related repos\n\n- **[exe-wiki/ARCHITECTURE.md](https://github.com/AskExe/exe-wiki/blob/master/ARCHITECTURE.md)** — Full staging/routing architecture, schema definitions, routing rules\n- **[exe-crm](https://github.com/AskExe/exe-crm)** — CRM-side entity mapping and how routed data lands in contacts/deals/activities\n\n---\n\n## Integration with Exe OS (Optional)\n\nexe-gateway is fully standalone. To integrate with [Exe OS](https://github.com/AskExe/exe-os) for memory, wiki, and CRM hooks:\n\n```typescript\nimport { setHooks } from \"@askexenow/exe-gateway\";\nimport { orgBus } from \"@askexenow/exe-os/dist/lib/state-bus.js\";\nimport { ingest } from \"@askexenow/exe-os/dist/lib/pipeline-router.js\";\n\nsetHooks({\n onEvent: (event) => orgBus.emit(event),\n onIngest: (msg) => ingest(msg),\n});\n```\n\nThis pipes all incoming messages through the Exe OS memory pipeline and broadcasts events to the organization bus.\n\n## Deployment\n\n### Systemd (recommended for VPS)\n\nThe installer sets this up automatically. To configure manually:\n\n```bash\ncp exe-gateway.service /etc/systemd/system/\nmkdir -p /etc/exe-gateway\ncp deploy/.env.example /etc/exe-gateway/exe-gateway.env\nsystemctl daemon-reload\nsystemctl enable --now exe-gateway\n```\n\nView logs:\n\n```bash\njournalctl -u exe-gateway -f\n```\n\nThe service runs as a dedicated `exe` system user with security hardening. Tune `NODE_OPTIONS` and other secrets in `/etc/exe-gateway/exe-gateway.env`.\n\n### Nginx reverse proxy\n\nFor SSL termination and public-facing deployments:\n\n```bash\ncp nginx-gateway.conf /etc/nginx/sites-available/gateway.example.com\nln -s /etc/nginx/sites-available/gateway.example.com /etc/nginx/sites-enabled/\nnginx -t && systemctl reload nginx\n```\n\nReplace the example domain and certificate paths first. The template now proxies `/health`, `/webhook/*`, `/api/*`, and `/v1/*`, and includes an optional `/ws` block for the WebSocket relay.\n\n### Docker\n\n```bash\ndocker build -t exe-gateway .\ncp deploy/gateway.example.json ./gateway-data/gateway.json\n# Copy deploy/.env.example to your own env file and replace EXE_GATEWAY_AUTH_TOKEN first.\ndocker run -d \\\n --name exe-gateway \\\n -p 3100:3100 \\\n -p 3101:3101 \\\n --env-file ./gateway.env \\\n -v ./gateway-data:/data \\\n exe-gateway\n```\n\n## WhatsApp v7 upgrade: QR re-link required\n\nexe-gateway uses Baileys v7 for WhatsApp linked-device support. Baileys v7 is a breaking auth-state migration from 6.x. If you upgrade an existing WhatsApp-connected gateway, you must re-link each WhatsApp account once by scanning a new QR code.\n\nWhy: WhatsApp/Baileys changed the linked-device session format. Reusing old 6.x auth state can break receive/decrypt, especially for group messages.\n\nMigration steps:\n\n1. Back up the current WhatsApp auth directory.\n2. Reset the account auth directory.\n3. Restart exe-gateway.\n4. Open `https:///pair/default?token=`.\n5. Scan from WhatsApp → Linked Devices.\n6. Verify direct receive, group receive, send, and history sync.\n\nInstaller users: if existing WhatsApp auth is detected, the installer stops instead of silently breaking the account. To intentionally back up and reset auth for v7, rerun with:\n\n```bash\nEXE_GATEWAY_CONFIRM_BAILEYS_V7_REPAIR=1 bash install.sh\n```\n\nNo conversation data is deleted. Expect 2-5 minutes of WhatsApp downtime per account while re-linking. See `docs/BAILEYS_V7_MIGRATION.md` for the full runbook.\n\n## Platform Adapters\n\n| Platform | Library | Status | Notes |\n|----------|---------|--------|-------|\n| WhatsApp | Baileys (Web protocol) | Production | Multi-account, full history sync, QR pairing |\n| Telegram | Grammy | Production | Bot API, inline keyboards, media |\n| Discord | discord.js | Production | Slash commands, threads, embeds |\n| Slack | Bolt + Web API | Production | Socket Mode, interactive messages |\n| Email | Nodemailer + IMAP | Production | SMTP outbound, IMAP inbound |\n| iMessage | macOS native | Beta | Requires macOS host |\n| Signal | signal-cli | Beta | Requires signal-cli daemon |\n| Webchat | WebSocket | Production | Browser widget, real-time |\n| Webhook | Generic HTTP | Production | Any platform via HTTP POST |\n| CRM | Exe CRM bridge | Production | Bi-directional contact/deal sync |\n\n## Contributing\n\n1. Fork the repo\n2. Create a feature branch (`git checkout -b feat/my-feature`)\n3. Make your changes with tests\n4. Run `npm test` and `npm run typecheck`\n5. Open a PR\n\n## License\n\n[MIT](LICENSE)\n","readmeFilename":"README.md"}
![\"MIT](\"https://img.shields.io/badge/license-MIT-blue.svg\"){kind=icon}
\n ![\"Node](\"https://img.shields.io/badge/node-%3E%3D20-brightgreen.svg\"){kind=icon}
\n ![\"10](\"https://img.shields.io/badge/platforms-10-orange.svg\"){kind=icon}
\n