Sealed; the provider is DECLARED again and must be retested

The credential was refused before anything was sealed, for one of two reasons. Either the MECHANISM takes no credential at all — WEBHOOK providers are signed with a per-destination secret configured on the destination, so a credential stored against the provider would authenticate nothing — or the credential does not have the STRUCTURE this mechanism requires: blank, past the size bound, or, for a service-account mechanism, not a JSON object or missing a member the mechanism reads. Structure is all that was examined: nothing was contacted and the credential was NOT verified. Nothing is written and nothing is demoted, so a refused save is not a credential change and any previously sealed credential stays live. The body names MEMBERS, never values, and carries no fragment of what was submitted.

No or invalid token

Missing scope, or the caller is not the ROOT platform tenant

No such provider

The ROOT platform tenant was named as the target

A custody-layer refusal: the seal could not be performed. Nothing is written and nothing is demoted, so a refused save is not a credential change and any previously sealed credential stays live. UNLIKE the destroy verb beside it, this operation DOES refuse when the custody root is unbound or unreachable, because sealing resolves a key protector and dropping a ciphertext row does not. That asymmetry is the whole reason the destroy's own 503 description points back at this one.