Answers the question the delivery path itself asks — would a message for this
tenant go out right now — and never the question does a provider row
exist. The two diverge on the state this endpoint exists for: a provider
declared with a valid credential and never probed is present, populated and
syntactically valid, and delivers nothing, because activation requires a
connectivity verdict measured against the configuration the row currently holds.
deliverable is therefore the emptiness of the ACTIVE delivery chain
and nothing else; every other member exists to EXPLAIN a false and
none of them may change it.
The chain is resolved exactly as delivery resolves it: this tenant's own ACTIVE
rows first, and the deployment's whole chain as the fallback when the tenant has
none. effectiveScope reports which of the two answered — and it reads
DEPLOYMENT whenever the fallback was taken, including when that
fallback is itself empty.
One entry is returned per reported channel: EMAIL
unconditionally — account activation and password reset are email-borne — plus
every other chain-borne channel for which a provider row exists at any status, in
either scope.
The reported set is EMAIL, SMS and
WHATSAPP — the three channels whose delivery resolves the provider
chain this verdict is computed from. WEBHOOK is a fourth
NotificationChannel value and is reported in NO state, even when a
WEBHOOK provider row is declared: a webhook resolves an alert DESTINATION, whose
endpoint and signing secret are per-destination and are not in this chain, so a
verdict derived here would be an answer to a question webhook delivery never
asks.
The blocking vocabulary is ordered, and the order is the precedence, so
a scope in more than one condition yields the earliest, which is always the first
action the operator must take:
NO_PROVIDER_DECLARED— no row for this channel. Declare one.PROVIDER_UNVERIFIED— rows exist and none carries a PASSED verdict measured against its CURRENT configuration: never probed, last probe FAILED, or probed and then edited. Run the connectivity test.PROVIDER_NOT_ACTIVATED— a current PASSED verdict exists and no row is ACTIVE. Enable the provider.NOT_REMEDIABLE_HERE— substituted for one of the three above when the rows that explain the block are the DEPLOYMENT's, which this administrator does not administer. Contact the platform operator.
The substitution follows whose rows must be ACTED ON, not whose chain would have
carried the message. A tenant that declared providers of its own receives the
specific token and blockingProviderId naming its own row — even
while effectiveScope reads DEPLOYMENT, because activating
the provider it already declared is what would restore delivery.
NOT_REMEDIABLE_HERE is reserved for a tenant holding no row of its own
for that channel, the one case in which the remedy genuinely is not theirs.
blockingProviderId is present only when the blocking row lies in the
scope this read is about — so, on this plane, only when the tenant holds rows of its
own. No deployment provider is ever named here, and no mechanism, status, verdict or
count about the deployment is disclosed either.
Absence is key omission, never null. A deliverable channel
carries no blocking key at all, rather than a token meaning
"nothing is wrong" — a rendered all-clear cannot be distinguished from a read that
never happened.
The non-blocking notice member is orthogonal to
blocking: it has its own condition, never suppresses and is never
suppressed by a blocking token, and both may ride one channel entry.
INHERITING_DEPLOYMENT_CHAIN states that this tenant declared rows of
its own for the channel and is nonetheless riding the deployment chain, because none
of its own rows is currently ACTIVE. A tenant that declared nothing is inheriting by
design and receives no notice.
Nothing here is cached. Every call is a fresh resolution, so the verdict moves on the read immediately after the remedy — no invalidation call exists because no cache does. The read is available to every tenant: it is not gated by the edition that governs whether a tenant may CONFIGURE its own providers, because a tenant that cannot configure one is precisely the tenant for whom this verdict is the only thing there is to say.
| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||