Suppliers registry

Field	Required	Notes
name	yes	1–512 chars, trimmed
address_line1	no	≤512 chars
address_line2	no	≤512 chars
city	no	≤512 chars
region	no	≤512 chars
postcode	no	≤512 chars; no country-specific format validation
country	no	ISO 3166-1 alpha-2; lower-case accepted, response upper-case
statement	no	1–4000 chars
external_id	no	Your caller-side identifier, per-organization, ≤256 chars

The fingerprint field on responses is read-only — it's a lower-cased, whitespace-collapsed concatenation of the identity fields used for global dedup.

PATCH /parties/suppliers/:id may take one of four code paths depending on how many organizations link to the supplier and whether the edited identity collides with another row. The response surfaces the outcome on meta.outcome and the list of affected pending DDS versions on meta.affected_dds_version_ids.

outcome	When
in_place	Only your organization links to the supplier; the row is updated in place.
fork	Multiple organizations link; a new global row is created for the edited identity, your link is repointed, other orgs continue to see the original row.
fork_into_existing	Multi-org-linked AND the new fingerprint collides with an existing global row; your link repoints to the collider, no new row minted.
merge	Single-org-linked AND the new fingerprint collides; your link repoints to the collider, the original row is soft-deleted.

In every case the response data.id is authoritative for "where your link points now" — it may differ from the request's :id when a fork or merge happens. Pending DDS versions of your organization are repointed accordingly, and one supplier.propagated event is appended per affected version (plus supplier.forked or supplier.merged as appropriate). The full audit-trail catalog is on the Mitigation Audit Log endpoint reference.