PNotify

Features

Notification gateway: one request, email + Telegram + PCall, tracked until it is delivered.

Notifications you can trust to arrive

A queue, retries and status per recipient — instead of a script that fires and forgets.

One request, many recipients and channels; each recipient gets its own delivery to track.

Every delivery is stored in PostgreSQL before it is sent, so a crash or restart never loses a notification.

Temporary errors are retried with growing delays; permanent ones stop at once instead of hammering a provider.

Templates ship inside the binary. Missing data keys are an error, so nothing half-filled is ever sent.

Reach people inside CalixOne: a chat message, or a call that rings the app and reads the message in a natural Vietnamese voice.

Send an Idempotency-Key and a retried request returns the original result instead of notifying twice.

Every recipient moves through the same visible states.

1
Send
Your system calls POST /v1/notifications with a template, data and recipients. You get 202 back.
2
Queue
One delivery per recipient is stored as pending.
3
Deliver
A worker claims the delivery and hands it to the channel: sending, then sent.
4
Confirm
Channels that can confirm — PCall — report back by webhook: delivered or failed.
5
Track
GET /v1/notifications/{id} lists every delivery with its status; dead means PNotify gave up.

Tell us who needs to be notified, about what, and how quickly.