Set a declared destination
Sets declared_destination_id to a destination the Beneficiary already holds and that can be paid: the one a payout resolves to when it names none. The Beneficiary may set it too, through a collection link; the last write wins. Idempotent: naming the current declaration changes nothing. A change the Business makes is announced to the Beneficiary by email. Returns the Beneficiary.
https://docs.usecleff.com/api-reference/beneficiaries-declared-destination-update.md.Authorizations
Cleff API key, created in the dashboard under Settings → API keys
Path Parameters
Body
A destination the Beneficiary already holds, from GET /v1/beneficiaries/{id}/bank-accounts. It must be payout-usable.
Response
person, business Legal display name (first+last or business name); never piped
Preferred display label: nickname when set, else legal name
pending, compliant, suspended Derived: false while the per-type required identity field is still deferred (a stub in the awaiting_pii state). True once the identity is complete. Never stored. Computed against the CURRENT required-field list, so a compliant beneficiary can read false after that list grows: that is a top-up prompt, not a block — the beneficiary keeps its status and keeps receiving payouts, and supplying the field on PUT /v1/beneficiaries/:id or over a full_onboarding collect link flips it back to true.
Soft flag: a trigger PII field changed after acknowledgment. Compliance status stays compliant, but new Payout creation is blocked until the Business re-acknowledges.
Identity collection sub-state. Only a full_onboarding link advances it; a payout_destination link lands no identity. Either link records the destination the beneficiary chose, which is declared_destination_id and not this field.
not_invited, invited, details_submitted When the beneficiary completed the full_onboarding collection-link form.
The destination a payout goes to when it names none: the one the beneficiary chose in the collection flow, or the one the Business set with PUT /v1/beneficiaries/{id}/declared-destination, whichever was written last. Cleff never substitutes a sibling for it. null while none has been declared, in which case a destination resolves only while exactly one is payout-usable and is otherwise refused as ambiguous.
Derived read-model Status chip: a pure projection over {identity completeness, compliance state + re-ack flag, bank-account validation/verification}. The invited chip was retired. Not a stored state machine.
suspended, reacknowledgment_required, pending_details, pending_kyc, action_required, ready Derived: the beneficiary's live (unconsumed, unexpired) collection-link requests — {id, scope, expires_at} — read off the live-token store, never stored. Consumed/expired tokens never appear. Cardinality is 0..1 today (resend invalidates the prior link), but the shape is a list.
When the Business archived this Beneficiary, or null while it is active. An archived Beneficiary is gone from the address book (list, CSV export) and refuses new Payouts, but stays readable by id so a Payout's payee can still be resolved.
sandbox, production Business-facing display label, when set
Optional structured postal address; null when unset
Provider enrollment status for the default payout rail, or null when the Beneficiary has never been enrolled. rejected means the last synchronous enrollment attempt failed (e.g. the rail rejected the bank): the Beneficiary is compliant but payouts cannot reach them until re-enrollment succeeds.
pending, verified, rejected, suspended, closed The payment rail's own words for the refusal behind enrollment_status: rejected, stripped of the provider; null in every other enrollment state, a retry still in flight included. Beneficiary-level: a refusal that named a bank account repeats it on that account's rail_rejection_reason, while one that named none — a person-level refusal, or a Beneficiary with no destination yet — is readable only here.
The bank account the refusal behind enrollment_status: rejected named, or null when it named none (a person-level refusal, or one that landed before any destination existed) and in every other enrollment state. A named account repeats the same reason on its own rail_rejection_reason; an unnamed one is readable only on enrollment_failure_detail.