ingestlayer/recipes

Track waitlist signups in Discord

See who joins the waitlist as it happens — with their position and where they came from — so launch outreach starts the day they sign up, not after the next export.

01source

sourcesdk.eventTypeScript SDK
matchwaitlist.joined

02pipeline · 2 steps

  • 01ENRenrich.personemail → company · role
  • 02CTLfilter.matchskip disposable-email domains

03destinations · 1

  • todiscordDiscord
    channel#ops

the event

You emit waitlist.joined with this shape. The TypeScript SDK keeps the call type-safe, and the event is stored whole — so every field below is available to the pipeline by name.

  • emailstring
  • positionnumberplace in line
  • referrerstringwhere they came from
  • created_atstringISO 8601

emit it

From your code with the TypeScript SDK — or any language over the REST endpoint and signed webhook ingress.

emit waitlist.joined
import { ingest } from "@ingestlayer/sdk";

await ingest("waitlist.joined", {
  email:    form.email,
  position: list.length + 1,
  referrer: req.headers.referer,
}, {
  idempotencyKey: form.email,   // one slot per email
});

route it to Discord

Send rich embeds to a channel via a connected bot or a channel webhook.

  1. 01

    connect the bot

    Add the ingestlayer bot to your server, or paste a channel webhook URL. Either credential is held in-region.

  2. 02

    choose the channel

    Select the target channel from the picker. Each connected channel is one reusable destination row.

  3. 03

    shape the embed

    The default embed carries the event name as its title and the payload as name/value fields; override with $event.* references.

in discorddelivered
┌─ #ops ─────────────────────────────────┐
│ ▎ payment.failed                        │
│ ▎ customer   acme-inc                   │
│ ▎ amount     €240.00                    │
│ ▎ reason     insufficient_funds         │
│ ▎ attempt    2                          │
└─────────────────────────────────────────┘

notes

questions

Can I treat work emails differently?
Yes. enrich.person resolves the email to a company, then a filter or a branch routes business signups somewhere louder than personal ones.
How do I stop duplicate entries?
Pass the email as idempotencyKey; the gate enforces uniqueness, so a double-submit counts once and keeps positions honest.
Can I keep a full copy of the list?
Fan out: send the alert to a chat channel and the same event to Postgres, so the canonical list lives in your own database.
build this pipelineor read the quickstart →

waitlist signups, routed elsewhere

more, into Discord