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:
One rather than two requests
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.
Thema / Theme
Klantinteracties API
Omschrijving / Description
Update the
partijenCreatepayload to accept one or more partij identificatoren, e.g.:Toegevoegde waarde / Added value
A common pattern emerging in Open Inwoner Platform is (1) creating a
Partijand immediately subsequent to that (2) creating aPartijIdentificator. We canonically identify parties in OK through the usual suspects from the basisregistraties:bsn,kvk, and so on.Although the bare
Partijhas thenummerfield, its intent is not very clear when it is client provided: OIP might choose to use thenummerto 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 aPartij.{uuid|nummer}.TLDR: we would like to canonically identify a
Partijthrough aPartij Identificator, and this would be eased by being able to create thePartijwith itsIdentificatoratomically. The added value is thus it facilitates our use-case, in at least two ways:Partijcreation 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