MagicBell vs ntfy

MagicBell

A public OpenAPI 3.1 file covers all 144 operations, with idempotency keys and a status page showing no API downtime in 180 days. No batching or digest step, llms.txt, error code list, SLA or sub-processor list was found, and project tokens carry no scopes.

ntfy

Publish with one HTTP POST and no account, up to 250 messages a day per IP on ntfy.sh. Unreserved topics on ntfy.sh can be read and written by anyone who knows the name.

MagicBell

1. Ask the owner for a Project JWT from the dashboard's Project Auth page. The terms forbid accounts registered by automated methods
2. Send Idempotency-Key with a UUID on POST /v2/broadcasts, and reuse it on a retry within 24 hours
3. Stay under 500 requests a minute per IP. A 429 blocks the address for 60 seconds, so put many recipients in one broadcast
4. Use a Project JWT for broadcasts, users, integrations and workflows, and a User JWT for one user's inbox, tokens and preferences
5. Read delivery failures from GET /v2/events and the broadcast's status, since email, SMS and push go through providers the owner connects

ntfy

1. Use a long random topic name, or a reserved topic with a Bearer token
2. Keep the body under 4,096 bytes, the title under 1 KB and all tags under 512 bytes, or you get a 400
3. Don't blind-retry a publish. There's no idempotency key, so the person gets it twice
4. Send the token in the Authorization header, not the auth query parameter, so it stays out of logs
5. Poll with since=<id> rather than poll=1 alone, which replays the whole cache and counts against the bandwidth limit