Order alerts from your webshop
Setting this up takes about a minute. The slow part is not the software — it is deciding what to call yourself, because the handle ends up on a poster and cannot be changed afterwards.
What this actually looks like
An order confirmation email is opened by about half your customers and a shipping email by fewer. A channel your buyers opted into at checkout carries the order number and the state, sent automatically by the shop with one API call.
How you would set it up
- Create a channel for the shop and offer the subscribe link on the order confirmation page.
- Send the order number and what changed — packed, shipped, at the pickup point. Never a name or an address.
- Trigger it from your shop’s webhook so it happens without anybody in the warehouse remembering to.
Everything the console does, from your own code
A REST API you can read in an afternoon: one key, one POST, one alert. Credentials carry scopes, so the cron job that sends can be forbidden from deleting a channel, and a key can be bound to a single channel. Webhooks push sends, cancels and subscriptions to your endpoint with a signature you verify, instead of you polling us for something you already know. There is also an MCP server, so an assistant can be connected over OAuth — no pasted keys, revocable per client, and narrowed to the scopes you approve on a consent screen you read first.
One handle, printed once, permanent
A channel lives at drop.top followed by its handle, and that address never changes. It cannot be edited after creation, because it ends up on a poster in a school entrance, on a festival gate and inside a QR code somebody has already laminated. The page behind it explains what the channel is, what it asks a phone for, and how to subscribe — so a stranger reading a poster can decide before installing anything. We generate the QR code for you, server-side, and it is never sent to a third-party image service.
Draft, schedule, send — and what cancelling cannot undo
Composing and sending are deliberately different permissions, so the person or script that writes an alert can be forbidden from publishing it. A scheduled alert becomes visible at its time without anything having to run at that minute, which means a server that was briefly down delivers late rather than never. Cancelling is honest about its limits: it stops an alert reaching phones that have not fetched it yet and does nothing at all to the phones that already have it. An alert cannot be unsent.
Questions, answered plainly
Is there an API?
Yes — the same one the console uses, so anything you can do by hand you can automate. Scoped keys, signed webhooks, and an MCP server if you want an assistant to do it.
Can I change my handle later?
No, and that is on purpose. It gets printed on posters and encoded into QR codes, and a handle that could change is a handle that turns somebody’s laminated sign into a dead link. Choose it the way you would choose a street name.
Can I unsend an alert?
No. Cancelling stops it reaching phones that have not fetched it yet, and does nothing to the ones that already have it. Compose as a draft and read it back before you send; that habit is worth more than any undo button we could offer.
Do subscribers need an account?
No. They install the app, subscribe to a handle, and that is the whole of it. Only the person running the channel signs up for anything.
Say it once. Every subscribed phone gets it.
Free up to 100 subscribers, no card to start, and the handle is yours permanently.
Start a channel