Skip to main content
Docs/Webhooks
DocsWebhooks
Free

Webhooks

Receive webhook calls from third-party services and send them from your generated apps. Covered by primitives you already use: workflows, functions, and custom handlers.

Receiving Webhooks

Three options, pick by how much code you want to write:

Workflow trigger (zero code)

Create a workflow with a Webhook Trigger node. You get a stable URL; incoming requests fire the workflow. Best when you want to route, branch, send notifications, or chain calls without writing code.

Custom handler (lightweight)

Ask the generator for a webhook receiver and it emits a custom handler at /api/custom/{appId}/{name}. Best for one-shot processing co-located with your app.

Function (most control)

Write a Function in TypeScript or Python. You get full request access, can verify signing secrets, and can call other SDKs. Best when the webhook needs nontrivial validation or downstream calls.

Sending Webhooks

To call an outbound webhook from your app:

  • From a workflow: use the HTTP Request node, configure method / URL / headers / body, and run it on whatever trigger fits (manual, schedule, event from another node).
  • From a Function or custom handler: standard fetch() in TypeScript or httpx / requests in Python.
  • From a scheduled agent: the agent is just Python; call your destination directly.
Store webhook destinations and signing secrets in Environment Variables so they are easy to rotate.

Security

A few non-negotiables for production webhook receivers:

  • Verify the signing secret on every inbound request. Stripe, GitHub, Slack, etc. each ship one; reject if it does not match.
  • Idempotency: third-party providers retry. Record the event ID before processing and short-circuit on duplicates (see the Stripe Connect handler pattern in the platform).
  • Fast acks: respond 2xx quickly. If you have heavy work, enqueue it and process out-of-band.
  • Allowlist source IPs where the provider publishes them.
Do not put secrets in your generated frontend code. Always handle webhook validation server-side (Function, custom handler, or workflow code node).

Patterns

  • Stripe webhook: Function that verifies the Stripe-Signature header and updates a row in your products table on checkout.session.completed.
  • GitHub deploy hook: workflow that listens for push events on main and triggers a redeploy via an agent step.
  • Form bounce: custom handler that receives a SendGrid bounce, marks the address invalid in your users table, and emails an admin.

FAQs

Does GenMB have a dedicated webhooks UI?
Not as a standalone object. Webhooks in GenMB are an integration pattern, not a primary entity. Both directions (receiving and sending) are covered by primitives you already use: workflows, functions, and custom handlers.
Which receiver should I pick?
For event-driven automation that fans out to multiple actions, use a workflow webhook trigger. For a single response that runs custom logic, use a Function or a custom handler. Workflows are zero-code; Functions give you full programmatic control.
How do I verify a Stripe / GitHub signing secret?
Receive the request in a Function, fetch the secret from /docs/environment-variables, and verify the signature header in code. If it does not match, return 401. The platform does not auto-verify provider-specific signatures because every provider has its own scheme.
Can I send a webhook on a schedule?
Yes. Pair a workflow schedule trigger with an HTTP Request node, or use a scheduled agent that calls fetch(). See /docs/workflows and /docs/backend.

Ready to build?

Create your first app for free, no credit card required.