Webhooks (Preview)

SmartGate lets each team register outbound webhook endpoint URLs and signing secrets. This feature is in Preview: you can create and manage endpoints today, but SmartGate does not deliver business events to those URLs yet.

For observability now, use Activity Logs and Dashboard audit views.

Preview — what works today

The Dashboard shows a Preview notice on Dashboard → Webhooks with the same message.

Do not confuse with billing webhooks

Billing integration is described in Billing. This page covers team outbound endpoints only.

Plan limits

Each plan includes a maximum number of registered endpoints (not delivered events):

Connect and Billing docs reference the same entitlements. Creating endpoints beyond your quota is blocked in the UI.

Register an endpoint

1. Open Dashboard → Webhooks.
2. Click Add Endpoint.
3. Enter:
   • URL — HTTPS endpoint you control
   • Description — optional label
   • Events — optional comma-separated filter (stored for future delivery; empty = all events when delivery ships)
4. Copy the signing secret immediately — it is shown once at creation.

Store the secret securely. You will use it to verify payloads when event delivery becomes available.

Managing endpoints

From the endpoints table you can:

• Pause / Resume — disable delivery without deleting configuration
• Delete — remove endpoint and delivery history for that endpoint

Delivery counts in the UI reflect test or future delivery attempts — during Preview they will typically stay at zero.

What to use instead (today)

Roadmap expectation

When delivery GA ships, SmartGate will POST signed event payloads to your registered URLs. Event types, retry policy, and delivery logs will be documented in an updated version of this page.

Until then, treat outbound webhooks as configuration-only Preview.

Related

• Activity Logs — supported observability path
• Billing — plan limits including webhook quota
• Security — secret handling

Preview status (read carefully)

Webhooks are in Preview: you can register outbound endpoints and manage signing secrets in-product, but business event delivery is not generally available yet. Design integrations assuming you may need to poll audit/export APIs today (Logs) and switch to push events when delivery ships.

Why register early anyway

Registering endpoints lets teams agree on URL allowlists, secret storage, and ownership before event catalogs freeze. Treat Preview as configuration rehearsal: rotate secrets, validate HTTPS endpoints, and document which system would consume audit or billing events later.

Suggested consumer patterns

1. Security mirror: when delivery exists, forward tool-failure spikes to your on-call tool.
2. FinOps mirror: budget threshold events to a cost channel (still use dashboard alerts meanwhile).
3. Ops mirror: pipe completion events to a workflow tracker.

Until delivery is on, schedule /api/v1/audit/export or dashboard reviews. Do not build a production dependency on Preview push semantics.

Safety

• HTTPS only for callback URLs.
• Store signing secrets like API keys (Security).
• Prefer team-owned endpoints over personal tunnels for anything beyond local debugging.
• Document retry/idempotency expectations in your consumer before go-live.

Positioning

Webhooks extend the Agent/Human interfaces outward; they do not change SmartGate category. SmartGate remains an MCP-native intelligence layer—not an LLM proxy—and webhook payloads will describe gateway tool and account events, not host-model chat transcripts.

Practical adoption notes

Treat SmartGate as shared infrastructure: one gateway URL, team-scoped keys, and audit on by default. Prefer pipe templates for repeatable research paths so Activity Logs show a coherent chain instead of ad-hoc tool spam. Keep host-model prompts focused on decisions; let Research and Context primitives prepare evidence. When FinOps asks for savings, export Usage Reports alongside the gateway benchmark explanation—never present Est. USD saved as a vendor LLM invoice. When security asks for evidence, export an audit window and show retention tied to the current plan catalog.

If you are migrating from scripts, replace raw HTTP fetch helpers first, then add dedup and compression, then budget guard. If you are migrating from a model gateway mindset, stop expecting chat completions on /api/mcp and wire MCP hosts instead. If you are writing human-facing product copy, lead with Smart Research / Smart Decision outcomes; keep MCP JSON on builder paths. These habits keep the site and the product aligned with the Positioning Bible: intelligence layer between AI and the world, not an LLM proxy.

Related reading

• Overview for the capability map and plan table
• Connect Guide for host JSON and troubleshooting
• Tools Reference for when to search, fetch, compress, or pipe
• Activity Logs for audit, trace, and export
• Pricing for fair-use limits, Gainshare, and plan ceilings
• Token Control, Traffic Customs, and Audit and Compliance for pillar narratives aligned with this docs set

Keep English-first public docs consistent with the Positioning Bible: SmartGate is an MCP-native algorithmic gateway and intelligence layer—not a chatbot, ChatGPT alternative, AI search engine, LLM proxy, or model router. Humans research and decide through Web experiences; agents connect through MCP/API; both share the same runtime primitives and team-scoped governance.

One more operational reminder

Document your team naming scheme, key rotation cadence, and who owns Gainshare questions before you scale agent count. Prefer bounded Playground or single-tool MCP checks when validating Connect JSON. Prefer audited smart_pipe templates for recurring research once the handshake works. Prefer exporting Activity Logs before plan downgrades that shorten retention. These habits cost little and prevent the two failure modes we see most: empty tool lists from incomplete MCP initialize, and missing audit evidence when a reviewer asks what an agent fetched last week.