Overview, keys and webhooks
The three pages that are about the organization's plumbing rather than its audience. Organization settings, members and the activity log are documented under Organizations.
Overview
The landing page of an organization, and the only page that answers "how is this instance doing" in one screen.
- Counters across the top: contacts, messages, templates, channels, domains, webhooks, forms, automations, broadcasts and API keys.
- Health — verified domains, active webhooks and active integrations.
- Messages over time — total, delivered, pending and failed, with the delivery rate, over a range you pick.
- Automation runs over the same range, and the triggers behind them.
- By domain and by channel breakdowns of what was sent.
- Active workflows — the automations currently published and switched on.
The unattributed bucket in "by domain"
Messages written before sender attribution was enforced — and any whose domain has since been deleted — have no domain to file under, so they are reported as their own bucket rather than dropped. Hiding them would make the breakdown disagree with the totals beside it. Channel messages are excluded entirely: a Discord or Telegram message has no sending domain at all.
API keys
Admin and above. Keys authenticate calls to the public API with the X-API-Key header, and a key belongs to exactly one organization — there is no parameter that changes which, so a leaked key exposes one organization's data and no more.
New API key (/keys/new) takes:
- Label — how you will recognise it later.
- Description — optional; what it is used for, where it is deployed.
- Expires — 7 days, 30 days, 90 days, 1 year, no expiry, or a custom date. The custom date is read in your account's time zone.
The key is shown once
Only a hash is stored. Copy it when it is created; there is no way to see it again.
Edit (/keys/<id>/edit) changes the label and description only. The key and its expiry are fixed.
Revoke or delete
Both stop the key working immediately. They differ in what is left behind.
| Effect | |
|---|---|
| Revoke | The key stays in the list marked Revoked, so it stays visible that it existed and when. It cannot be reactivated. |
| Delete | The row disappears. Use it for a key created by mistake. |
Anything the key produced — messages, imports, activity entries — survives either way, and the Messages page can still filter by it.
Expiry
An expired key is rejected exactly like an invalid one: 401, with no hint about which it was. Owners and admins are emailed as a key approaches its expiry and again once it has passed, so a key does not lapse silently inside a running integration.
Webhooks
Every domain event, POSTed to an endpoint you control.
Add webhook takes the URL. The response shows a signing secret — copy it now, it is not shown again.
Each delivery carries the event name in X-Notifyzr-Event and an HMAC-SHA256 of the raw body in X-Notifyzr-Signature. Verify against the raw bytes, before parsing, with a constant-time comparison. There is a worked example in the Webhooks guide.
Deliveries are queued, not sent inline with the request that caused them, so a slow endpoint of yours never slows down the API call that triggered it. Failures are retried with a widening gap between attempts, and a delivery that never succeeds is set aside rather than silently dropped. Notifyzr will not fail somebody's send because your endpoint was unreachable.
Deleting a webhook stops deliveries to it and cannot be undone. There is no edit — replace it with a new one.
Same events, two consumers
Webhooks and automations fire on exactly the same event catalog. An integration you build and an automation someone configures are reacting to the same thing.