---
title: "Rename or complete a contact"
method: PATCH
path: "/api/v1/user/contacts/{contact_id}"
tags: ["User"]
---

# Rename or complete a contact

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

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.

## Path parameters

- `contact_id` string, uuid, required

## Headers

- `x-api-key` string, nullable

## Request body

- ContactUpdateRequest — 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, nullable
  - `address` UserAddress — 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.
    - `streetAddress` string, nullable
    - `addressLine2` string, nullable
    - `city` string, nullable
    - `state` string, nullable
    - `country` 'AF' | 'AX' | 'AL' | 'DZ' | 'AS' | 'AD' | 'AO' | 'AI' | 'AQ' | 'AG' | 'AR' | 'AM' | 'AW' | 'AU' | 'AT' | 'AZ' | 'BS' | 'BH' | 'BD' | 'BB' | 'BY' | 'BE' | 'BZ' | 'BJ' | 'BM' | 'BT' | 'BO' | 'BQ' | 'BA' | 'BW' | 'BV' | 'BR' | 'IO' | 'BN' | 'BG' | 'BF' | 'BI' | 'CV' | 'KH' | 'CM' | 'CA' | 'KY' | 'CF' | 'TD' | 'CL' | 'CN' | 'CX' | 'CC' | 'CO' | 'KM' | 'CG' | 'CD' | 'CK' | 'CR' | 'CI' | 'HR' | 'CU' | 'CW' | 'CY' | 'CZ' | 'DK' | 'DJ' | 'DM' | 'DO' | 'EC' | 'EG' | 'SV' | 'GQ' | 'ER' | 'EE' | 'SZ' | 'ET' | 'FK' | 'FO' | 'FJ' | 'FI' | 'FR' | 'GF' | 'PF' | 'TF' | 'GA' | 'GM' | 'GE' | 'DE' | 'GH' | 'GI' | 'GR' | 'GL' | 'GD' | 'GP' | 'GU' | 'GT' | 'GG' | 'GN' | 'GW' | 'GY' | 'HT' | 'HM' | 'VA' | 'HN' | 'HK' | 'HU' | 'IS' | 'IN' | 'ID' | 'IR' | 'IQ' | 'IE' | 'IM' | 'IL' | 'IT' | 'JM' | 'JP' | 'JE' | 'JO' | 'KZ' | 'KE' | 'KI' | 'KP' | 'KR' | 'KW' | 'KG' | 'LA' | 'LV' | 'LB' | 'LS' | 'LR' | 'LY' | 'LI' | 'LT' | 'LU' | 'MO' | 'MG' | 'MW' | 'MY' | 'MV' | 'ML' | 'MT' | 'MH' | 'MQ' | 'MR' | 'MU' | 'YT' | 'MX' | 'FM' | 'MD' | 'MC' | 'MN' | 'ME' | 'MS' | 'MA' | 'MZ' | 'MM' | 'NA' | 'NR' | 'NP' | 'NL' | 'NC' | 'NZ' | 'NI' | 'NE' | 'NG' | 'NU' | 'NF' | 'MK' | 'MP' | 'NO' | 'OM' | 'PK' | 'PW' | 'PS' | 'PA' | 'PG' | 'PY' | 'PE' | 'PH' | 'PN' | 'PL' | 'PT' | 'PR' | 'QA' | 'RE' | 'RO' | 'RU' | 'RW' | 'BL' | 'SH' | 'KN' | 'LC' | 'MF' | 'PM' | 'VC' | 'WS' | 'SM' | 'ST' | 'SA' | 'SN' | 'RS' | 'SC' | 'SL' | 'SG' | 'SX' | 'SK' | 'SI' | 'SB' | 'SO' | 'ZA' | 'GS' | 'SS' | 'ES' | 'LK' | 'SD' | 'SR' | 'SJ' | 'SE' | 'CH' | 'SY' | 'TW' | 'TJ' | 'TZ' | 'TH' | 'TL' | 'TG' | 'TK' | 'TO' | 'TT' | 'TN' | 'TR' | 'TM' | 'TC' | 'TV' | 'UG' | 'UA' | 'AE' | 'GB' | 'US' | 'UM' | 'UY' | 'UZ' | 'VU' | 'VE' | 'VN' | 'VG' | 'VI' | 'WF' | 'EH' | 'YE' | 'ZM' | 'ZW' — ISO 3166-1 alpha-2 country codes.
    - `zip` string, nullable
  - `relationship` 'employee' | 'contractor' | 'vendor' | 'subsidiary' | 'merchant' | 'customer' | 'landlord' | 'family' | 'other' | 'self' — 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.
  - `bic` string, nullable — BIC for an IBAN contact saved without one — Align requires it on IBAN beneficiaries. Ignored when the contact already has a BIC.
  - `bankAddress` BankAddressDetails — The beneficiary bank's own address, kept apart from the holder's. Read/storage shape: only the street is guaranteed, because rows saved before this was structured hold a single free-text line that validates into ``address_line1`` alone. New input goes through BankAddressInput, which requires everything the banking provider does.
    - `addressLine1` string, required
    - `city` string, nullable
    - `state` string, nullable
    - `postalCode` string, nullable
    - `country` string, nullable

## Response `200`

Successful Response

- unknown

## Other responses

- `422` — Validation Error

## Changes

- **2026-08-27** `7ed1b58c5607` — 1 breaking, 5 warning, 3 info
  - removed `#/components/schemas/app__schemas__routers__user__contact__ContactRelationship` from the `relationship` request property `anyOf` list
  - removed the request property `chainId`
  - removed the request property `currency`
  - removed the request property `priorityMethod`
  - …5 more

[Change history](https://skmtc.dev/hevn-inc/apis/hevn-api/changes/api/v1/user/contacts/:contact_id/patch.md)

---

[API](https://skmtc.dev/hevn-inc/apis/hevn-api.md) · [All operations](https://skmtc.dev/hevn-inc/apis/hevn-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/hevn-inc/hevn-api/revisions/7ed1b58c5607/schema)