Accept Partij Identificatoren as part of Partij creation

[swrichards]

Thema / Theme

Klantinteracties API

Omschrijving / Description

Update the partijenCreate payload to accept one or more partij identificatoren, e.g.:

// POST /partijen
{
  "indicatieGeheimhouding": false,
  "indicatieActief": true,
  "soortPartij": "persoon",
  "partijIdentificatie": { /* ... */ },
   // ...   

   // New field
   "partijIdentificatoren": [
     {
        // "identificeerdePartij" will be automatically set to the created party
        "partijIdentificator": {
			"codeObjecttype": "bsn",
			"codeSoortObjectId": "inp",
			"objectId": "123456789",
			"codeRegister": "brp",
	},
	"anderePartijIdentificator": "optional_identifier_123",
     }        
   ]
}

Toegevoegde waarde / Added value

A common pattern emerging in Open Inwoner Platform is (1) creating a Partij and immediately subsequent to that (2) creating a PartijIdentificator. We canonically identify parties in OK through the usual suspects from the basisregistraties: bsn, kvk, and so on.

Although the bare Partij has the nummer field, its intent is not very clear when it is client provided: OIP might choose to use the nummer to build its own scheme (e.g. setting it to our internal user ID, or some pseudonymised version thereof), but this might not play well with other clients reading and writing from OK. We would in any case like to avoid having to maintain our internal mapping between a Partij.{uuid|nummer}.

TLDR: we would like to canonically identify a Partij through a Partij Identificator, and this would be eased by being able to create the Partij with its Identificator atomically. The added value is thus it facilitates our use-case, in at least two ways:

1. One rather than two requests
2. It improves atomicity, as having to use two requests creates a transactionality problem: the Partij creation could succeed by the PartijIdentificator could fail. This forces clients to maintain a retry/compensating transaction queue, which is a nuisance. But also, it runs the risk of orphaned Partij objects lacking a clear identificator due to such a failed transaction.

Our assumption is that this is probably a common use-case, but that is just a hunch.

Aanvullende opmerkingen / Additional context

No response