Inquir Compute · webhooks

Webhook ingress through the Inquir API Gateway

Stable URLs on your domain, raw bodies for signatures, then pipelines or jobs for the slow part.

Situation

Why webhooks get fragile

SaaS vendors retry liberally. If your handler does thirty seconds of database work before it responds, you invite timeouts, duplicate deliveries, and angry on-call threads.

Skipping HMAC verification “just for staging” or forgetting idempotency keys feels fine until two identical events create two charges.

Sharp edges

Common shortcuts

A single monolithic app endpoint often mixes auth modes for users and machines, complicating observability.

Running handlers inline with your main API couples scaling dimensions you wanted to keep separate.

How Inquir fits

A clearer split

One function per provider (or per event type) keeps verification logic small and reviewable. You are not mixing cookie-based user auth with machine credentials in the same handler.

Because routes are first-class configuration, security reviewers can read which URLs exist, which keys they expect, and how they differ from customer-facing APIs.

Capabilities

Webhook-focused building blocks

Route isolation

Map provider-specific paths to small handlers with narrow permissions.

Execution traces

Inspect bodies (redacted) and timings when a provider pauses delivery.

Async handoff

Ack fast, continue processing in a pipeline when work is heavier than a timeout window.

Steps

How to process webhooks on Inquir Compute

Verify signatures, acknowledge within provider timeouts, apply writes idempotently.

Verify

Confirm signatures and parse events defensively.

Ack or defer

Return quickly; enqueue durable work if needed.

Apply

Update datastore idempotently using provider event IDs.

Code example

Sketch: verified handler

Gateway passes API Gateway–style events: body is a string (raw bytes for signing), headers as received. Swap in your provider’s verify helper and header names (casing matches the incoming request).

webhooks/stripe-ish.mjs

export async function handler(event) {
  const rawBody = event.body ?? '';
  if (!verifySignature(rawBody, event.headers)) {
    return { statusCode: 400, body: 'invalid signature' };
  }
  const evt = JSON.parse(rawBody);
  await enqueueForProcessing(evt.id, evt.type);
  return { statusCode: 200, body: 'ok' };
}

Fit

Good fit

When to use

You need stable HTTPS ingress for providers (custom domain on the gateway, DNS in your control).
You want isolation between webhook traffic and customer-facing APIs.

When not to use

You only consume webhooks into a SaaS iPaaS and never touch the runtime.

FAQ

How do I handle slow downstream work?

Acknowledge the webhook quickly, then continue in an async pipeline so provider timeouts do not stall critical side effects.

Can I pin routes per tenant?

Multi-tenant routing patterns let you segment paths or hosts; see the dedicated feature page for details.

What about replay attacks?

Combine signature verification, timestamps where supported, and idempotent writes keyed by provider identifiers.