Rename or complete a contact

Renames a contact and fills in details it is still missing (address, relationship, BIC, bank address). Values already stored are kept as they are, and whatever the payout providers keep about the recipient is updated on their side too. Use this instead of deleting and re-creating a contact to add a field — a re-created contact is a new row, and the provider beneficiary registered for the original stays behind on it.

PATCH /api/v1/user/contacts/{contact_id}

Rename or complete a contact

cURL

curl --request PATCH \
  --url https://api.example.com/api/v1/user/contacts/{contact_id} \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '{}'

422

{
  "detail": [
    {
      "loc": [
        "<string>"
      ],
      "msg": "<string>",
      "type": "<string>"
    }
  ]
}

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

Path Parameters

contact_id · string<uuid> · required

Body

application/json

Request to update a contact.

The display name is freely mutable. Requisites, address and relationship are fill-only: a field that is already set on the contact keeps its value, and only the still-empty ones are filled in. Recreating the contact to add a missing field is what produced duplicate rows — the requisites identity changes with the added field, so the upsert misses the original and its provider account ids are stranded on the deleted row.

name · string | null

Required string length: 1 - 200

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.

Show child attributes

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

bic · string | null

BIC for an IBAN contact saved without one — Align requires it on IBAN beneficiaries. Ignored when the contact already has a BIC.

bankAddress · BankAddressDetails · object | null

The beneficiary bank's own address (street + city), required by the banking provider payouts. Parts the contact already carries are kept; missing ones are filled, so a legacy free-text address can gain its city.

Show child attributes

Response

200

application/json

Successful Response