Op de onderliggende pagina’s wordt per object (gebouwen, straatnamen…) alle informatie verzameld die een afnemer nodig heeft om een goed gebruik te maken van de edit-API’s. Deze informatie bevat:

• Mogelijke statussen en statusovergangen, eventueel met de afhankelijkheid van statusovergangen van andere gekoppelde objecten.

• Business rules: welke regels moeten gevolgd worden om een bepaalde actie uit te voeren en wat zijn de gevolgen van de actie?

• Validatieregels: welke validaties gebeuren er bij het uitvoeren van een actie? Deze worden onderverdeeld in:

  • Error 4xx: de call wordt niet uitgevoerd door een foutieve (voorafgaande) validatie. Er wordt geen ticket aangemaakt.

  • Ticketing error: de call wordt wel uitgevoerd (code 2xx), maar er gebeurt een fout tijdens de verwerking. Het ticket zal een error geven.

• De betekenis van deze edit events in de feed kan hier worden geraadpleegd.

Decentraal vs intern beheer

De edit endpoints maken decentraal beheer mogelijk in het Gebouwen- en Adressenregister. Deze endpoints worden door de dienstenleveranciers geïmplementeerd in hun software. Zo kunnen bijvoorbeeld straatnamen, adressen, gebouwen, gebouweenheden en percelen toegevoegd, verwijderd of aangepast worden.

Niet alle edit endpoints mogen door iedereen uitgevoerd worden, daarom werden er een aantal rollen opgesteld. Elke rol heeft zijn eigen specifieke eigenschappen.

• Decentrale bijwerker: De decentrale bijwerker staat in voor het beheer van adressen, ingeschetste gebouwen en enkele correcties. Dit zijn de lokale besturen.

• Interne bijwerker: De interne bijwerker staat in voor de verwijdering en correcties van straatnamen, adressen, ingeschetste gebouwen en gebouweenheden. De interne bijwerker kan ook uitvoeren wat een decentrale bijwerker kan. Dit zijn bijvoorbeeld operatoren van Digitaal Vlaanderen.

Correctie vs wijziging

Er wordt een onderscheid gemaakt tussen correcties en wijzigingen. In het eerste geval gaat het om een rechtzetting van een fout (vb. ‘Van Eikstraat’ moet zijn ‘Van Eyckstraat’), in het tweede geval gaat het om een verandering in administratieve toestand (vb. gebouw veranderd van status ‘inAanbouw’ naar ‘inGebruik’).

Voorbeeld: Het wijzigen of corrigeren van de postcode van een adres.

Hiervoor zijn 2 aparte API’s gemaakt. De API ‘Corrigeer de postcode van een adres’ mag door elke decentrale beheerder uitgevoerd worden. Dit wordt uitgevoerd als de verkeerde postinfoID van een gemeente aan het adres is gekoppeld. Deze correctie kan alleen maar naar postinfoId’s worden gezet gekoppeld aan deze gemeente. De API ‘Wijzig de postcode van een adres’ is voor interne bijwerkers en wordt bijvoorbeeld op vraag van Bpost uitgevoerd. Bpost wilt dat postbodes een zo optimaal mogelijke route afleggen om deze reden kan het zijn dat adressen van bepaalde gemeenten een andere postinfoId krijgen dan deze die in de gemeente liggen. Deze API laat dit toe, vandaar dat dit niet door iedereen mogelijk is om uit te voeren.