Whether the deployment would deliver notifications right now

Answers the question the delivery path itself asks — would a message 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.

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.

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 plane 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.

NOT_REMEDIABLE_HERE, the fourth member of the vocabulary, is never

emitted on this read: it names an operator who owns a remedy the caller does not,
and on the deployment plane the caller administers every row that could be
blocking.

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 reports an informational state that

is orthogonal to blocking and never suppresses it. It cannot arise on
this read, which is about the deployment and therefore cannot be inheriting.

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.

Recent Requests
Log in to see full request history
TimeStatusUser Agent
Retrieving recent requests…
LoadingLoading…
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