Whether this tenant's notifications would be delivered right now

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:

  1. NO_PROVIDER_DECLARED — no row for this channel. Declare one.
  2. 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.
  3. PROVIDER_NOT_ACTIVATED — a current PASSED verdict exists and no row is ACTIVE. Enable the provider.
  4. 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.

Recent Requests
Log in to see full request history
TimeStatusUser Agent
Retrieving recent requests…
LoadingLoading…
Path Params
uuid
required
Headers
string
enum
Defaults to application/json

Generated from available response content types

Allowed:
Responses

Language
Credentials
Bearer
JWT
URL
LoadingLoading…
Response
Click Try It! to start a request and see the response here! Or choose an example:
application/json
application/problem+json