Usage and health

Usage

GET /v1/usage

The organization's plan, its effective limits, and what has been spent against them.

{
  "plan": "pro",
  "quotas": {
    "messages_per_month": 10000,
    "contacts": 5000,
    "automations": 25,
    "automation_runs_per_month": 20000,
    "forms": 20,
    "webhooks": 20,
    "domains": 5,
    "channels": 10,
    "templates": 50,
    "members": 10,
    "api_keys": 10
  },
  "usage": {
    "messages_per_month": 3182,
    "contacts": 1204,
    "automations": 7,
    "automation_runs_per_month": 4410,
    "forms": 3,
    "webhooks": 2,
    "domains": 1,
    "channels": 2,
    "templates": 11,
    "members": 4,
    "api_keys": 3
  }
}

usage carries every dimension, so quotas and usage have the same keys — pair them up rather than special-casing the two monthly ones.

A null limit means unlimited. quotas reflects the effective limit — a per-organization override set by a site admin replaces the plan default, so read this rather than assuming the plan's table.

The dimensions

Two are per calendar month and reset: messages_per_month and automation_runs_per_month. The rest are standing counts of what currently exists.

What happens at the ceiling

Exceeding one returns 422 notifyzr.quota.error.exceeded.

Crossing one never corrupts work in flight. A contact import or a broadcast fan-out that runs out of quota completes, with the remainder counted as skipped — the records that fit are real. Owners and admins are emailed at 80% of a watched monthly quota and again at the limit, once per calendar month.

Self-hosted instances

On a self-hosted instance the plan is stored but quotas are not enforced.

Health

GET /health

Unauthenticated. Returns the service's status, and is what the status page at status.<DOMAIN> probes. Every service in the platform exposes one at the same path.

curl http://api.localhost/health