Developers: Free Encrypted Webhooks and Bots

Webhook bots

A webhook with a chat window at the end of it

A bot is an identity your phone creates and owns. Your systems post to it over HTTPS, and everyone subscribed to that bot receives what it has to say.

Created in the app, in seconds

Open the Bots tab, tap New, name it after the system that will post. You get a webhook URL and a token immediately. Nothing to register, nobody to ask.

One POST is the whole API

Send JSON with a text field and a bearer token. Anything that speaks HTTP can drive it: curl, a CI step, a Cloudflare Worker, a monitoring action, a script.

Subscribers scan, they do not sign up

People start receiving a bot by scanning its QR code in the app, and can stop whenever they want. No invite link to forward, no subscriber list to hand over.

Receive only, on purpose

The composer stays hidden in a bot chat. A bot can page you, and can never be turned into a way of talking back to your infrastructure.

Quickstart

From nothing to a delivered alert in about a minute

Three steps, none of which involves a signup form or an approval queue.

Create the bot

In the app, open the Bots tab and tap New. Give it the name of the system that will post: build-server, uptime, payments.

Keep the token

It is shown once and stored only as a hash, so put it straight into your secret manager. If it ever leaks, rotate it from the bot's detail screen and the old one stops working at once.

Share the QR, then post

Whoever should get the alerts scans the bot's code in the app. From then on every POST reaches them in about a second, with a notification showing the bot's name and nothing else.

Request

curl -X POST https://api.talkridge.com/hook/YOUR_BOT_ID \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"text":"Deploy 4.2.1 finished, 0 errors.","source":"ci"}'

Response

{ "ok": true, "v": "t1", "delivered": 3 }

delivered is the number of subscribed devices the message was sealed for. A bot with no subscribers yet answers zero instead of failing, so a first deploy never breaks on it.

Reference

The entire API, on one screen

No SDK to install, no versioned client to keep up with. This is the whole surface.

Endpoint

POST https://api.talkridge.com/hook/{bot_id}, over HTTPS only. The bot id is part of the webhook URL the app shows you.

Authentication

Authorization: Bearer {token}. The token is compared in constant time against a stored hash, and can be rotated from the app at any time.

Body

JSON with text (required) and source (optional). When present, source is prefixed to the message, so one bot can carry several systems and you can still tell them apart.

Success

200 with ok: true and delivered: N, where N is how many subscribed devices the relay sealed a copy for.

Errors

Plain JSON with ok: false and a short reason. 400 when text is missing, 401 for a bad token, 404 for an unknown bot, 429 when you are over the rate limit.

Limits

4,000 characters per message, 60 posts per minute per bot, up to 20 bots per owner. Longer text is truncated rather than rejected.

What you are not signing up for

The parts other webhook endpoints leave out

Wiring up alerts usually means adding your systems to a chat platform that bills per seat and keeps every message it has ever carried. This one does neither.

Free, with no seats to count

No team plan, no per-user price, no admin console. A bot belongs to the phone that created it, and can be handed to another identity if that phone is replaced.

No archive in the cloud

The relay holds each sealed envelope only until the subscribed device collects it, then deletes it. Your alert stream never becomes a searchable history on someone else's servers.

Content-free notifications

Push notifications carry no message body. A lock screen says that something arrived, never what it said.

It travels with the app

Alerts land in the same app as private conversations, on iOS and Android, behind the same device lock. On-call staff do not need a second messenger installed.

Straight answer

Where the trust boundary actually sits

Between two people, TalkRidge holds no key that can open a message: the keys are generated on the two phones and exchanged by scanning. A webhook sender is a server, not a phone, so a bot's identity key is held by the relay, which seals every delivery to the subscriber's own device key on the bot's behalf.

So an alert stream is protected in transit, sealed in storage and readable on the subscriber's device, but it is not the zero-knowledge model of a private chat. We would rather write that plainly than let you assume something stronger. Send operational messages through a bot, and keep your most sensitive material in a conversation.

What the relay can see

The text a bot posts, because it seals a copy of it for each subscriber.

The mailbox identifiers it delivers to, which carry no name, phone number or email address.

Nothing whatsoever about your private conversations, which never involve a bot.

TalkRidge’s encryption is built exclusively from vetted, unmodified open-source cryptographic primitives, and the protocol design is documented openly. The applications have not yet undergone an independent external security audit — we say so plainly rather than borrow trust, and independent review is on the roadmap.

Where it fits

What teams already point at a bot

Anything you would have wired to a chat webhook, minus the workspace, the invoice and the retention policy.

Deploy and CI notices, without inviting a build server into a company chat workspace

Uptime and on-call alerts that reach a phone even when the laptop is closed

Payment, fraud and order events for a small team that would rather not route them through a public platform

Website form submissions, which is exactly how the contact form on this site is delivered

Security tooling output, kept away from the vendors and the network being monitored

Anything a customer of yours needs to be told, without asking them to install one more account-based app

Talk to us about an integration →

Webhooks that land in an encrypted inbox

A webhook with a chat window at the end of it

From nothing to a delivered alert in about a minute

The entire API, on one screen

The parts other webhook endpoints leave out

Where the trust boundary actually sits

What teams already point at a bot

Questions? Talk to a human.

Headquarter

Email us