Associate a payee with an Account (trusted platform)

Trusted-platform binding action for payer-managed onboarding. The caller is the payer-side Account from X-Wingspan-Account and must also have explicit access to the incoming payeeAccountId (for example, both Accounts are controlled by the same Organization, or the authenticated Person has an Authorization grant to both). ServiceAccount-attributed association requires ServiceAccount bearer enforcement and is not enabled for this route yet. This action sets Payee.payeeAccountId without requiring recipient-side acceptLinkRequest, creates or completes the durable PayerPayeeLinkRequest as Linked, and records the supplied authority evidence for audit. It is intended for same-Org / platform-operated migrations where the platform has already established the worker's consent and identity binding outside Wingspan.
Payee creation never accepts or resolves an Account hint. Association is the audited, idempotent transition that mutates the relationship. Fires PayerPayeeLinkRequest.Linked, then Payee.Activated when activation requirements are met. A different already-linked Account returns 409 ResourceConflict; an inaccessible payeeAccountId returns 403 AccountMismatch.
Do not pass an account binding during payee creation; create-time account hints are intentionally not part of the public V3 REST flow.

Recent Requests
Log in to see full request history
TimeStatusUser Agent
Retrieving recent requests…
LoadingLoading…
Path Params
string
required
^[A-Za-z0-9_.]{22,80}$
Body Params

Request body for associatePayeeAccount. The caller must be acting as the payer Account and must also be authorized to act on the incoming Payee Account. Idempotency is keyed by (payerAccountId, payeeId, payeeAccountId, Idempotency-Key).

string
required
^(?:[A-Za-z0-9_.]{22}|[a-f0-9]{24})$

The Account to bind to this Payee relationship.

authority
object
required

Audit evidence for a trusted platform's assertion that the Payee can be bound to the supplied Account without a recipient-side Wingspan accept step. This records the source of authority; it is not a substitute for any banking terms or electronic-consent acceptance that must be captured separately by the relevant finance/onboarding flow.

metadata
object

Free-form key-value pairs. Max 50 keys; key length at most 40 characters; value length at most 500 characters. Where a list endpoint declares metadata filtering, it uses the QueryQL namespace via filter[metadata.{key}][eq]=value or filter[metadata.{key}][in][]=value. Endpoints that do not declare the dynamic Metadata filter do not support Metadata filtering.

Headers
string
^(?:[A-Za-z0-9_.]{22}|[a-f0-9]{24})$

Select the Account for an Account-scoped operation. A direct ServiceAccount API key MUST supply this header, and the target must be within the ServiceAccount owner's or Authorization grant's Account boundary. A Person bearer may select an Account on which it has an active Stakeholder, and an Account session may select its bound Account (or a descendant only when the session explicitly includes descendants).

string
length between 1 and 255
^[\x21-\x7e]{1,255}$

Optional idempotency token for authenticated POST and PATCH requests. Reusing the same key and body returns the cached response for 24 hours, except credential operations that explicitly document a 409 because one-time secret material is never cached; reusing it with a different body returns 409 IdempotencyKeyConflict. Use 1-255 printable ASCII characters.

string
enum
Defaults to application/json

Generated from available response content types

Allowed:
Responses

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