Skip to main content
POST
Read payout capabilities for one recipient

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Headers

x-api-key
string | null

Body

application/json

Ask what a payout to one recipient would be allowed to do.

Either end of the client's flow answers the same question, so the request takes either: contactId for a recipient already saved, account for the form that has not been submitted yet. amount is optional and only has the rail limits checked against it — nothing is quoted or booked.

contactId
string<uuid> | null
account
SepaAccountInput · object

SEPA bank contact input.

address
UserAddress · object | null

Address schema for user.

Canonical field names: street_address, address_line_2, city, state, country, zip. Accepts legacy Align/IBAN field names (street_line_1, street_line_2, postal_code) for backward compatibility with existing JSONB data.

relationship
enum<string> | null

How a payout contact relates to the user.

The vocabulary mirrors Swipelux's recipient relationships so the common values project onto their API unchanged, but this is our own domain type: SELF marks a first-party payout to the user's own account at another bank and has no Swipelux counterpart. Providers own that projection — see SwipeluxRecipients._recipient_relationship — so nothing here depends on a provider, and no provider enum has to carry a value it cannot accept.

Available options:
employee,
contractor,
vendor,
subsidiary,
merchant,
customer,
landlord,
family,
other,
self
amount
Required range: x > 0

Response

Successful Response

Everything one recipient can be paid with, and what stands in the way.

recipient
RecipientSummary · object
required

Who is being paid, as the capabilities were resolved against them.

available
boolean
required
options
RecipientPayoutOption · object[]
blockers
RecipientBlocker · object[]