Use case

Webhook processors you can reason about

Verify fast, acknowledge on time, hand heavy work to jobs—built for duplicate deliveries.

Create webhook route →Webhook ingress

Situation

Failure modes

Duplicate deliveries and slow downstream calls cause time-outs unless you design idempotency and async handoff.

One overloaded endpoint drags down unrelated user traffic.

Why workarounds fail

Common shortcuts

Skipping signature checks “temporarily”.

Doing database writes synchronously before returning 200 OK.

How Inquir fits

Structure

Dedicated functions per provider reduce accidental coupling.

Pipelines continue work after a fast HTTP response.

Capabilities

Tools

Route-level auth

API keys or custom schemes per ingress.

Tracing

See which stage failed—verify, enqueue, or apply.

Tenant routing

Map hosts or prefixes when each customer has a webhook URL.

Steps

How to process webhooks on Inquir Compute

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

Authenticate event

Reject early on bad signatures.

Ack

Return quickly within provider limits.

Process

Apply idempotent writes keyed by provider IDs.

Code example

Idempotency key

Gateway sends body as a string; parse JSON after verify. Store provider event IDs before mutating state.

persist.mjs

export async function handler(event) {
  const evt = JSON.parse(event.body || '{}');
  if (await alreadyHandled(evt.id)) {
    return { statusCode: 200, body: 'duplicate' };
  }
  await handle(evt);
  return { statusCode: 200, body: 'ok' };
}

Fit

Good fit

When to use

SaaS integrations
Payment providers
Git hosting events

When not to use

Bi-directional sockets—different transport

FAQ

Why must the raw body stay untouched for HMAC verification?

Providers sign exact bytes; JSON re-serialization or charset changes alter the payload and cause false “invalid signature” failures.

Should webhooks do heavy work before returning 200?

No—acknowledge within provider timeouts, then continue in a pipeline or background function so retries do not duplicate expensive side effects.

How do I handle duplicate webhook deliveries?

Treat provider event IDs as idempotency keys: persist “seen” before mutating data so at-least-once delivery stays safe.