Met de BRP API Personen Web API kun je gegevens van actuele personen in de basisregistratie personen (BRP) voor jouw applicatie zoeken en raadplegen met hun identificerende gegevens.
In de BRP worden personen uniek geïdentificeerd met behulp van hun burgerservicenummer. Is het burgerservicenummer van de te raadplegen persoon/personen bekend, dan moet jouw applicatie de Raadpleeg persoon met burgerservicenummer operatie gebruiken om de betreffende persoon/personen te raadplegen.
Is het burgerservicenummer van de te raadplegen persoon/personen niet bekend, dan kun je deze laten opzoeken met de Zoek persoon operaties.
De BRP bevragen API is ontworpen conform de REST principes. Om ook aan de AVG te conformeren zijn er concessies gedaan aan het toepassen van de REST principes. De belangrijkste concessie is dat de POST methode en niet de GET methode wordt gebruikt om personen te bevragen. Dit zorgt er voor dat er geen persoonlijk identificeerbare informatie (PII) terecht komen in de url van een request en daardoor ook niet in server logs.
Je kunt de volgende zoekoperaties gebruiken om een persoon met niet-uniek identificerende persoonsgegevens te vinden:
Het resultaat van de “zoek met adresseerbaar object identificatie” operatie is een GezagPersoonBeperkt collectie/lijst, en bevat naast de PersoonBeperkt lijst ook de gezagsrelaties van alle personen die op dit adres wonen. Het resultaat van alle andere operaties is een PersoonBeperkt collectie/lijst. Standaard bevat deze lijst alleen personen die in leven zijn. Om een overleden persoon te zoeken, moet de inclusiefOverledenPersonen parameter op true worden gezet.
Voor overleden personen wordt altijd het opschortingBijhouding veld geleverd met reden code ‘O’ en omschrijving ‘overlijden’. Zie de overlijden overzicht feature voor meer informatie over dit veld.
Als het burgerservicenummer van de te bevragen personen bekend is, kan de volgende operatie worden gebruikt om gegevens van de persoon te raadplegen:
Het resultaat van deze operatie is een Persoon collectie/lijst.
Voor overleden personen wordt altijd het opschortingBijhouding veld geleverd met reden code ‘O’ en omschrijving ‘overlijden’. Zie de overlijden overzicht feature voor meer informatie over dit veld.
Elke bevraging moet verplicht een fields parameter bevatten om aan te geven welke velden van de gevonden persoon/personen geleverd moet worden. Om de privacy van de gevraagde personen te beschermen mag een afnemer uitsluitend die velden vragen waarvoor hij doelbinding heeft en wat op dat moment nodig is voor de uit te voeren taak. Bijkomend voordeel van deze data minimalisatie is dat er ook wordt bijgedragen aan verduurzaming. Hoe minder velden er worden gevraagd, hoe minder de server en het netwerk worden belast.
Een veld wordt gevraagd door het volledige pad van het betreffende veld op te geven in de fields parameter. Het volledige pad van een veld is de samenvoeging van de naam van het veld en de namen van zijn ‘ouder’ velden met een ‘.’ karakter tussen de veld namen. Voorbeelden van volledige paden zijn:
Zie de fields en de fields fout cases feature bestanden voor meer informatie en voorbeelden van het gebruik van veldpaden en de fields parameter.
Het fields-filtered-PersoonBeperkt.csv bestand bevat een overzicht van de toegestane fields waarden voor de Zoek personen operaties. Voor de Raadpleeg persoon operatie is de overzicht van toegestane fields waarden te vinden in het fields-filtered-Persoon.csv bestand.
Wil je dit snel en foutloos doen? Stel dan je fields eenvoudig samen met de fields tool.
De BRP API Personen Web API kent de volgende datum types:
en de volgende waardetabel types:
Bij het vragen van één of meerdere velden van deze types worden altijd alle velden van het gevraagde type geleverd. In het fields feature bestand vind je voorbeelden hiervan onder de volgende rules:
De volgende velden worden indien van toepassing automatisch geleverd:
Automatisch geleverde velden mogen niet worden gevraagd met de fields parameter.
Voor verblijfplaats zijn er twee autorisatie profielen:
Afnemers die geautoriseerd zijn voor alleen verblijfplaats binnenland gegevens kunnen hierdoor de standaard veld paden van verblijfplaats niet gebruiken om alleen verblijfplaats binnenland velden te vragen. Met deze veld paden worden namelijk zowel verblijfplaats binnenland als verblijfplaats buitenland gevraagd.
Afnemers die niet geautoriseerd zijn voor verblijfplaats buitenland gegevens moeten daarom de verblijfplaatsBinnenland fields alias gebruiken om aan te geven dat alleen verblijfplaats binnenland gegevens wordt gevraagd.
Het gebruik van de verblijfplaatsBinnenland fields alias is beschreven in de volgende feature bestanden:
De adresregelvelden van een persoon worden samengesteld uit de verblijfplaatsvelden van een persoon. Om de adresregelvelden te kunnen vragen moet de afnemer minimaal geautoriseerd zijn voor de verblijfplaatsvelden waarmee de adresregelvelden worden samengesteld.
Dit betekent dat de twee autorisatieprofielen van verblijfplaats ook gelden voor het vragen van adresregelvelden. Afnemers die niet geautoriseerd zijn voor het vragen van adresregels van een verblijfplaats buitenland moeten daarom de adresseringBinnenland fields alias gebruiken om aan te geven dat alleen adresregels voor verblijfplaats binnenland worden gevraagd.
Het gebruik van de adresseringBinnenland fields alias is beschreven in de volgende feature bestanden:
Bij het vragen van de partners van een persoon worden de gevraagde gegevens van actuele partners (= niet ontbonden huwelijk/geregistreerd partnerschap) geleverd. Heeft de persoon alleen ontbonden huwelijk/geregistreerd partnerschappen, dan worden alleen de gevraagde gegevens van het meest recente ontbonden huwelijk/geregistreerd partnerschap geleverd.
In het volgende feature bestand zijn de bovenstaande regels geïllustreerd aan de hand van scenario’s/voorbeelden:
De BRP API Personen Web API kent de volgende nationaliteit types:
Er wordt alleen gegevens van actuele (= niet beëindigde) nationaliteiten geleverd.
In het volgend feature bestand zijn de bovenstaande regels geïllustreerd aan de hand van scenario’s/voorbeelden:
Wanneer velden van de verblijfstitel wordt gevraagd, dan worden de gevraagde gegevens geleverd als de verblijfstitel niet is beëindigd. Gegevens van een verblijfstitel worden ook niet geleverd als de aanduiding gelijk is aan ‘geen verblijfstitel (meer)’.
In het volgende feature bestand zijn de bovenstaande regels geïllustreerd aan de hand van scenario’s/voorbeelden:
Om een afnemer te informeren dat één of meer gevraagde velden in onderzoek zijn, worden de bijbehorende inOnderzoek en datumIngangOnderzoek velden ook geleverd. Wanneer één of meer velden waaruit een andere veld wordt afgeleid (bijv. de adressering velden) in onderzoek zijn, dan is het afgeleide veld ook in onderzoek en wordt het inOnderzoekveld van het afgeleide veld ook geleverd. In het in onderzoek featurebestand zijn de regels beschreven wanneer de inOnderzoekvelden wel/niet worden geleverd.
Wanneer tijdens onderzoek is vastgesteld dat een persoon niet meer verblijft op het geregistreerde adres en verblijfplaatsgegevens en/of adresregels van de betreffende persoon worden gevraagd, dan wordt het indicatieVastgesteldVerblijftNietOpAdres veld met waarde true meegeleverd.
De functionaliteit van het indicatieVastgesteldVerblijftNietOpAdres veld is beschreven in de volgende feature bestanden:
Om de payload van een response klein te houden, is er voor gekozen om velden met de volgende waarden niet te leveren in de response: