Webhook Push Notifications: Turn Any Service Into an iPhone Alert

Stripe just refunded a customer. Your CI pipeline went red. A new signup hit your database at 2 a.m. You want to know — on your phone, right now — without writing a single line of backend code to make it happen.

That's the whole pitch for webhook push notifications. Almost every service you already use (GitHub, Stripe, Coolify, Sentry, a Zapier zap, your own app) can fire an HTTP request when something happens. Point that request at the right URL and it lands on your iPhone as a notification. No server to host, no SDK, no APNs certificate dance.

Here's how to wire it up in about two minutes.

First, what a webhook actually is

A webhook is just an HTTP request a service sends to a URL you give it, the moment an event happens. Instead of you polling an API every 30 seconds asking "anything new yet?", the service pushes the news to you. The catch is you normally need a server sitting at that URL to catch the request and turn it into something you'll actually see.

That "something on the receiving end" is the part TheNotificationApp handles for you. You get a URL, you paste it into the other service's webhook settings, and incoming requests become push notifications. Two flavors exist depending on how much you care about formatting.

Get a key first (30 seconds)

Sign in with Apple at thenotification.app, create an app, and copy its app_key. That key is the only credential you'll need — it goes in the URL, so the service sending the webhook doesn't need to know how to set custom headers. That matters, because half the services out there only let you paste a plain URL.

The fast way: the static webhook

If you just want to know that something happened and you don't care much about pretty formatting, use the static webhook. It takes whatever JSON the service sends and turns the entire payload into the notification body.

The URL looks like this:

https://thenotification.app/api/webhook/static/?app_key=YOUR_API_KEY&title=Deploy%20finished

The title is optional (it defaults to "Webhook Notification"), and spaces have to be URL-encoded as %20. Test it from your terminal right now — no other service required:

curl -X POST "https://thenotification.app/api/webhook/static/?app_key=YOUR_API_KEY&title=Test" \
  -H "Content-Type: application/json" \
  -d '{"status":"deployed","commit":"a1b2c3d","branch":"main"}'

Your phone buzzes, and the body shows the status, commit, and branch laid out as readable text. A successful call returns:

{
  "success": true,
  "message": "Notification sent to 1 device(s)",
  "devices_sent": 1,
  "failed_count": 0
}

That's the entire setup. Paste the URL into the webhook field of whatever service you're using and you're done. The static webhook docs cover the rest.

The clean way: the dynamic webhook

Dumping a whole JSON blob onto your lock screen gets noisy fast. When a payload has 40 fields and you care about three of them, switch to the dynamic webhook. It lets you pick which fields become the title, body, and tappable link.

Same idea, different path, plus a few extra query params:

https://thenotification.app/api/webhook/dynamic/?app_key=YOUR_API_KEY&title=action&url=html_url&exclude=sender,repository

What's happening here:

• title=action — pull the payload's action field and use it as the headline
• url=html_url — make the notification open the html_url value when tapped
• exclude=sender,repository — drop those two noisy fields from the body

Field matching is case-insensitive and forgiving: deployment_url matches Deployment Url, deployment-url, and DeploymentUrl. Spaces, underscores, and hyphens are all treated as the same thing — so you don't have to guess the exact casing the service uses.

A real one: GitHub pull requests

The URL above is an actual GitHub example. Drop it into a repo's webhook settings (Settings → Webhooks → Add webhook), set the content type to application/json, and pick the "Pull requests" event. Now every time someone opens, closes, or merges a PR, you get a notification titled with the action ("opened", "closed") that opens the PR when you tap it.

If you'd rather get the full firehose of GitHub events on your phone — pushes, issues, workflow runs — there's a dedicated walkthrough for GitHub push notifications on your iPhone that goes deeper on the event types.

When you outgrow webhooks

Webhooks are perfect when the sender controls the format. But sometimes you're the one writing the code — a cron job, a script, a backend route — and you want to compose the exact message yourself. For that, skip the webhook endpoints and POST straight to the send API:

curl -X POST https://thenotification.app/api/sendNotification \
  -H "app_key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title":"Deploy finished","body":"main is live on prod","link":"https://status.example.com"}'

Note the difference: here app_key rides in a header, and you spell out title, body, and an optional link and image yourself. Use webhooks when you're connecting someone else's service; use the send API when you own the code.

The honest tradeoff

Fair warning on the free tier: it's 100 notifications total, not per month. That's plenty to wire up a few deploy and payment alerts and live with them for a while. But point a chatty webhook at it — say, one that fires on every GitHub push across an active repo — and you'll burn through 100 in an afternoon. Put noisy events behind a filter (only PRs, only failed payments), or grab Pro at $2.99/month for 1,000 notifications a month. Match the firehose to the bucket.

That's it

If a service can send a webhook, it can now reach your phone — no backend, no SDK, one URL. Worth a look if you're tired of finding out about events from an email three days later. Grab a key at thenotification.app and paste your first URL.