Plans & errors

Plans

	Solo	Pro
Notifications / month	10,000	250,000
Namespaces	1	Unlimited
Message history	24 hours	30 days
Card badges	✓	✓
`data` metadata bag	—	✓
Team members	—	✓ (owner / member roles)
Getting started	By application	Self-serve, 14-day free trial

Usage is metered by reach — the number of notifications actually delivered. One publish to a topic with five subscribers counts as five. Your namespace dashboard shows a live usage meter.

Pro is billed through Stripe with a hosted billing portal for managing or cancelling; the 14-day trial needs no card to start. Solo accounts apply at app.pinglet.co.uk/apply and are approved manually.

Dead man’s switch alerts bypass the monthly cap — being over quota never hides the news that something went down.

Message retention

Pinglet is a relay, not an archive. Every message is stamped with an expiry from the publisher’s plan (24 hours on Solo, 30 days on Pro) and deleted once it lapses. Idle devices are pruned after 60 days without contact, and orphaned topics (no subscribers, no messages) are cleaned up automatically.

Errors

Errors return a JSON body with a human-readable explanation.

Status	When
`400 Bad Request`	Malformed JSON, empty `message`, an unknown `priority`/`level` (including numeric priorities), over-length `data`/`badges` fields, an invalid topic name, or an unknown `?rewrite=` source.
`401 Unauthorized`	Missing, invalid, or revoked API key.
`402 Payment Required`	The namespace hit its monthly notification cap, or the account has a billing problem. Publishing resumes next month or once billing is fixed.
`403 Forbidden`	The key isn’t scoped to this namespace, or the namespace’s topic cap is reached.
`404 Not Found`	Unknown topic key (key-addressed publish never auto-creates), unknown device, or unknown ping token.
`413 Payload Too Large`	The message payload exceeds the ~4 KB budget. The error states the measured size.
`429 Too Many Requests`	A rate limit was hit — back off and retry.

Handling errors in scripts

For fire-and-forget alerting, curl -fsS plus your scheduler’s failure handling is usually enough. If an alert must not be lost, retry 429 and 5xx with backoff; treat 4xx (other than 429) as a bug in the request rather than something to retry.