nlqdb

Solve · Backend engineers

How do I store webhook events in a database I can query in plain English?

If you receive webhooks from Stripe, GitHub, or Twilio and want to ask 'how many events per type this week' without standing up a database first, write each verified payload to an nlqdb-provisioned Postgres and ask the report in English — the compiled SQL is shown underneath.

A webhook receiver is easy; the database behind it is the part nobody wants to own. You wire up a tiny endpoint to accept the POST, and then you need somewhere to put the payloads and a way to ask 'how many checkout events failed yesterday' later. Standing up Postgres, designing a schema for an evolving payload, and writing the reporting queries is a side-quest for what should be an afternoon's plumbing.

The snippet that solves it.

> webhook events grouped by event type with a count of each

What nlqdb does for this

  • Provision a Postgres in seconds, then write each webhook payload from your receiver via the `@nlqdb/sdk` client or `POST /v1/run`.
  • Ask 'how many events per type this week' in English — nlqdb compiles the `GROUP BY` and shows the SQL it ran.
  • Postgres JSONB stores the raw payload, so you query nested fields later without designing every column up front.
  • Mutating writes accept an `Idempotency-Key` (`GLOBAL-005`), so a retried delivery isn't processed twice into your store.

Drop into any HTML page

<nlq-data goal="webhook events grouped by event type with a count of each"></nlq-data>

The first question you ask of a webhook log — how many of each event type arrived — is one English goal here, not a schema design plus a GROUP BY you hand-write.

What this replaces

What nlqdb doesn't try to do here

  • nlqdb is not the webhook receiver — you still need a tiny endpoint (a Cloudflare Worker or serverless function) to accept the provider's POST and verify its signature. nlqdb is where you store and query, not the HTTP listener.
  • The public `<nlq-data>` embed reads; writes go through the authenticated SDK or `POST /v1/run` with an API key the browser never sees.
  • No built-in signature verification or dead-letter queue — that stays in your receiver; nlqdb stores the verified payloads and answers questions over them.

Questions buyers ask

How do I store webhook events without standing up my own Postgres?
Point your webhook receiver at nlqdb: it provisions a Postgres for you, and each verified payload is written via the `@nlqdb/sdk` client or `POST /v1/run`. There's no connection string to manage or migration to run before the first event lands. The trade-off is honest — nlqdb owns the database it provisions, so it isn't a connector over a warehouse you already run.
Can I query the stored webhook events in plain English?
Yes. Ask 'how many checkout events this week, grouped by day' and nlqdb compiles the SQL, runs it, and shows the query alongside the rows so you can audit the grain. The raw payload is kept as JSONB, so you can also filter on nested fields you never promoted to columns.
Does nlqdb receive the webhook and verify the signature for me?
No — you keep a small receiver (a serverless function or Worker) that accepts the provider's POST and verifies its signature, then writes the payload to nlqdb. nlqdb is the queryable store and natural-language reporting layer, not the HTTP listener. Mutating writes accept an `Idempotency-Key` so a retried delivery isn't double-processed.
How is this different from storing form submissions without a backend?
Form capture is browser-side — the page's own `fetch` writes a submission behind a key. Webhooks are server-to-server: a provider like Stripe or GitHub POSTs to your endpoint, you verify, then write. Both end at the same place — a Postgres you ask 'how many' over in English — but the write path differs. See /solve/store-form-submissions-without-backend for the form case.

Where this pain shows up in public

Enduring discussion hubs where you can verify the theme without taking our word for it. We don't quote individual posts; we cite search-result and subreddit URLs that stay live as new threads land.

Try nlqdb in 30 seconds

No sign-in. The anonymous database lasts 72 hours; adopt it with one click if you keep it.

Start with a goal →

Looking at this from a different angle? Browse all solve pages or browse competitor comparisons.