Versions Compared

Old Version 28

changes.mady.by.user Frank Wambacq

Saved on

compared with

New Version Current

changes.mady.by.user Frank Wambacq

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Deze pagina geeft per release weer welke wijzigingen doorgevoerd worden met impact op de publieke API.

Bij elke release vind je 2 data terug: wanneer deze versie beschikbaar komt op de staging omgeving en wanneer deze beschikbaar staat op de productie omgeving.

  • Voor wijzigingen die geen impact hebben op bestaande implementaties (non-breaking changes zoals extra functionaliteiten, extra velden, …) wordt de release op productie 1 week na de release op staging uitgevoerd.

  • Voor wijzigingen met impact op bestaande implementaties (breaking changes) worden de release data zowel op staging als op productie ruim op voorhand aangekondigd.

De versie nummering wordt gelijk gehouden voor alle ontwikkelingen van het verenigingsregister. Soms gebeurt het dus dat een nieuwe versie in productie gezet wordt die geen impact heeft op de publieke API. In dat geval gaan we die versie gewoon vermelden, al was het maar om de versie nummers te kunnen controleren.

Het huidige versie nummer van de publieke API vind je terug in de API documentatie. Helemaal onderaan wordt het versie nummer dat nu op die omgeving staat weer gegeven.

...

Status van de diensten: zie https://www.vlaanderen.be/digitaal-vlaanderen/status/status-overzicht?product=Verenigingsregister

⏳ Versie 8.

...

183.0 automatische adreswijziging door gemeentefusies

Datum staging:

Datum productie:

Expand
titleDetails

Automatische adreswijzigingen omwille van gemeentefusies

Op 1 januari 2025 veranderen alle adressen van de fusiegemeenten. Hierbij wordt de gemeentenaam aangepast en soms ook de straatnaam en/of het huisnummer. We luisteren naar deze events van het adressenregister en kijken of er impact is in het verenigingsregister. Elke vereniging uit een van de fusiegemeenten, waarvan het adresId gekend is, zal vanaf 1 januari automatisch het nieuwe adres toegekend krijgen. Dit wordt voor alle adressen met een adresId gedaan, behalve voor de maatschappelijke zetel die uit KBO komt. Daar blijven we luisteren naar wijzigingen die in KBO worden uitgevoerd.

✅ Versie 8.181.1 lidmaatschappen, parameter API voor werkingsgebied, bugfix totalcount

Datum staging:

Datum productie:

Expand
titleDetails

Lidmaatschappen

De publieke API bevat nu ook het element lidmaatschappen, waarmee aangegeven kan worden dat de ene vereniging lid is van een andere vereniging. Het lidmaatschap wordt enkel weergegeven bij de vereniging die lid is en dus niet bij de vereniging waarvan die lid is.

Hieronder het voorbeeld bij Publiek detail, ook in de zoek functie kan je de lidmaatschappen terugvinden (daar dan wel zonder het veld naam )

Code Block
languagejson
GET <PubliekURL>/v1/verenigingen/<vCode>
{
    "vereniging": {
        "vCode": "<vCode>",
        ...
        "lidmaatschappen": [
            {
                "@id": "lidmaatschap:20a0bce4-b46e-5eb3-9aac-1968f764b34a",
                "@type": "org:Membership",
                "andereVereniging": "<vCode andere vereniging>",
                "naam": "<naam andere vereniging>",
                "identificatie": "<identificatie>",
                "beschrijving": "<beschrijving>",
                "van": "1985-02-11",
                "tot": "2009-03-12"
            }
        ],
        ...
}

Parameter API voor werkingsgebieden

De lijst van mogelijke waarden voor een werkingsgebied kan je terugvinden via de publieke parameter API. Deze call naar de publieke API kan ook zonder API Key uitgevoerd worden.

De mogelijke werkingsgebieden zijn:

  • de NUTS2 codes voor de provincies van Vlaanderen en voor het Brussels hoofdstedelijke gewest

  • de NUTS+LAU codes voor de gemeenten van Vlaanderen en van het Brussels hoofdstedelijke gewest

  • de speciale waarde NVT - Niet van toepassing

Code Block
languagejson
GET <PubliekURL>/v1/werkingsgebieden
{
    "werkingsgebieden": [
        {
            "code": "NVT",
            "naam": "Niet van toepassing"
        },
        {
            "code": "BE10",
            "naam": "Brussels Hoofdstedelijk Gewest"
        },
        ...
        {
            "code": "BE23",
            "naam": "Provincie Oost-Vlaanderen"
        },
        ...
        {
            "code": "BE10021001",
            "naam": "Anderlecht"
        },
        ...
        {
            "code": "BE21111001",
            "naam": "Aartselaar"
        },
        ..
}

De speciale waarde NVT betekent dat er geen beperkingen zijn qua werkingsgebied. Dit is vooral om het onderscheid te maken met de default waarde voor werkingsgebieden: de lege lijst []. Deze default waarde geeft eigenlijk aan dat de werkingsgebieden (nog) niet bepaald zijn.

Door het verschil in betekenis kan de waarde NVT niet gecombineerd worden met een andere waarde:

bugfix totalcount

Wanneer het zoekresultaat bij Publiek zoek meer dan 10.000 resultaten bevatte, werd het juiste aantal resultaten niet correct weergegeven in metadata.pagination.totalcount. Daar werd het aantal afgetopt op 10.000. Nu wordt weer het juiste aantal zoek resultaten weergegeven.

✅ Versie 8.163.0 werkingsgebied

Datum staging:

Datum productie:

Expand
titleDetails

Werkingsgebied

Een nieuw concept werkingsgebied werd toegevoegd. Dit is een lijst van codes (NUTS&LAU) die aan een vereniging kan toegevoegd worden en die aangeeft welke regio's (gemeente, provincie, …) deze vereniging haar werkingsgebied is.

De huidige werkingsgebieden van een verenigingen kan je terugvinden zowel in publiek detail als via de zoek functie, telkens met zowel de code als de naam. Voorbeeld:

Code Block
languagejson
"werkingsgebieden": [
    {
        "@id": "wg:df28db28-1005-5a2f-a892-4495b2f45852",
        "@type": "skos:Concept",
        "code": "BE1",
        "naam": "Brussels Gewest"
    },
    {
        "@id": "wg:66ea53ba-95fd-567f-8610-4761e88a6e8c",
        "@type": "skos:Concept",
        "code": "BE21",
        "naam": "Provincie Antwerpen"
    }
]

In de zoekfunctie kan je de code van het werkingsgebied gebruiken als zoekcriterium. enkele voorbeelden:

Code Block
/v1/verenigingen/zoeken?q=werkingsgebieden.code:BE25
/v1/verenigingen/zoeken?q=werkingsgebieden.code:(BE21 OR BE25)

✅ Versie 8.154.1 Bugfixes

Datum staging:

Datum productie:

Expand
titleDetails

Bugfixes

Er werd een bug gefixt

  • publieke zoek: wanneer er meer dan 20 facets in de zoekresultaten zitten, worden er toch maar 20 facets getoond

✅ Versie 8.148.0 Export publieke informatie voor externe toepassingen

Datum staging:

Datum productie:

Expand
titleDetails

Export publieke informatie voor externe toepassingen

Er is een nieuw endpoint toegevoegd op de publieke API, waarmee externe partijen met specifieke toelating het recht hebben om alle publieke informatie van alle verenigingen op te vragen met 1 streaming endpoint.

✅ Versie 8.146.0 Minimum dataset - Vermijden dat de laatste locatie, vertegenwoordiger of hoofdactiviteit verwijderd wordt

Datum staging:

Datum productie:

Expand
titleDetails

Minimum dataset

Het zal nog steeds mogelijk zijn om vereniging te registreren zonder locatie, vertegenwoordiger of hoofdactiviteit. Maar van zodra een vereniging een van deze elementen bevat, dan zal het niet meer mogelijk zijn om de laatste van zijn soort te verwijderen:

  • Wanneer een vereniging al een locatie heeft, dan kan de laatste locatie niet meer verwijderd worden

  • Wanneer een vereniging al een vertegenwoordiger heeft, dan kan de laatste vertegenwoordiger niet meer verwijderd worden

  • Wanneer een vereniging al een hoofdactiviteit heeft, dan kan de set van hoofdactiviteiten niet meer leeg gemaakt worden

✅ Versie 8.133.5.6 Mutatie dienst + initiële adresmatch

Datum staging: (error) technische fout bij installatie - 2e poging op

Datum productie: nog te bepalen (verwacht in augustus)

Expand
titleDetails

Algemeen: initiële adresmatch

We hebben een proces toegevoegd dat alle adressen overloopt in het register. Elke adres dat nog niet is geverifieerd ten opzichte van het adressenregister, wordt opgezocht via adresmatch. Wanneer een resultaat wordt gevonden, wordt het adresId toegevoegd en worden de adrescomponenten aangepast aan de spelling zoals deze in het adressenregister voorkomt.

Publieke API: Mutatie dienst

In de publieke API is een nieuw endpoint beschikbaar dat kan gebruikt worden voor afnemers die synchroniseren naar hun eigen databank/CRM. Met dit endpoint kan je alle vCodes opvragen waarvoor er een wijziging is gebeurd sinds de laatste keer dat je de synchronisatie hebt uitgevoerd.

Om dit endpoint aan te spreken heb je een API Key nodig.

Voorbeeld:

Code Block
GET <publiekURL>/v1/verenigingen/mutaties?sinds=<vorigeMaxSequence>
response body:
[
    {
        "vCode": "V0001027",
        "sequence": 86
    },
    {
        "vCode": "V0001024",
        "sequence": 89
    }
]

In dit voorbeeld weet je nu dat V0001027 en V0001024 gewijzigd zijn. Om die te synchroniseren, haal je data op via een of meerdere van volgende (bestaande) endpoints:

  • Beheer Detail: <BeheerURLviaMAGDA>/v1/verenigingen/<vCode>

    • om alle gegevens van een vereniging op te vragen

  • Publiek Detail: <PubliekURL>/v1/verenigingen/<vCode>

    • om alle publieke gegevens van een vereniging op te vragen - dit gebruik je wanneer jouw organisatie enkel met publieke gegevens werkt OF wanneer je geen recht hebt om alle gegevens via MAGDA op te vragen

  • Beheer Historiek: <BeheerURLviaMAGDA>/v1/verenigingen/<vCode>/historiek

    • om meer informatie te bekomen over de wijzigingen die zijn uitgevoerd (enkel wanneer je hier toegang toe hebt)

Na synchronisatie, onthou je de hoogste verwerkte sequence (in het voorbeeld is dat 89) zodat je de volgende keer alle nieuwe wijzigingen kan opvragen via

Code Block
GET <publiekURL>/v1/verenigingen/mutaties?sinds=89

Goed om weten: in dit endpoint komen ALLE vCodes voor en worden ALLE wijzigingen gereflecteerd. Dit heeft enkele gevolgen die je best mee overweegt bij de implementatie van deze mutatiedienst. Enkele voorbeelden:

  • Wanneer er iets veranderd aan een vertegenwoordiger van een vereniging, dan is dit een wijziging, maar via de publieke data stroom zal je geen enkel verschil opmerken.

  • Wanneer een vereniging uitgeschreven wordt uit de publieke datastroom, dan komt dit naar voor als wijziging, maar via de publieke datastroom betekent dit dat je de vereniging plots niet meer zal terugvinden. (Publiek detail geeft dan een 404)

  • Wanneer een vereniging verwijderd wordt, dan komt dit naar voor als wijziging, maar noch bij publiek, noch bij beheer detail zal je deze vereniging nog terugvinden (respons = 404). Via beheer historiek kan je wel nog terugvinden dat deze vereniging verwijderd is, met daarbij de reden van verwijdering.

⏳ ✅ Versie 8.121.0 Dagelijkse synchronisatie met het adressenregister

Datum staging:

Datum productie: nog te bepalen (verwacht in augustus)

Expand
titleDetails

Dagelijkse synchronisatie met het adressenregister

Deze kleine update zorgt er voor dat er nu dagelijks automatisch een synchronisatie loopt met het adressenregister.

⌛ ✅ Versie 8.118.0 synchronisatie met adressenregister + bugfix voor lege locatie naam

Datum staging:

Datum productie: nog te bepalen (verwacht in augustus)

Expand
titleDetails

Wijzigingen aan publieke API

Geen

Info over beheer mogelijkheden

Synchronisatie met het adressenregister

Wanneer een adres wordt opgegeven met een adresId EN adrescomponenten (straatnaam, huisnummer, …) dan wordt dit nu geweigerd.

Wanneer een adres wordt opgegeven met enkel een adresId, dan worden de bijhorende adrescomponenten opgehaald uit het adressenregister, maar enkel wanneer het adresId verwijst naar een bestaand adres in status Ingebruik of Voorgesteld.

Wanneer adresmatch de adrescomponenten wijzigt en hierdoor zou een identieke locatie ontstaan (zelfde locatietype, naam en adres), dan zal een van de identieke locaties verwijderd worden: de locatie die als primair is aangeduid blijft behouden, de andere verdwijnt. Wanneer beide locaties als niet primair stonden aangeduid, dan wordt de nieuwste locatie verwijderd

Bugfix voor lege locatie naam

Stel: een vCode heeft een locatie met type = activiteiten en naam leeg ("naam": ""). Wanneer dan een nieuwe locatie wordt toegevoegd met type = activiteiten en hetzelfde adres maar in de request om toe te voegen wordt het naam veld niet ingevuld, dan werd deze locatie toch niet als dubbel gezien. Dit is nu opgelost, zodat het weglaten van het naam veld hetzelfde reageert als het toevoegen van "naam": ""

⏳ ✅ Versie 8.92.1 Adresmatch op ingevoerde adressen + statuspagina

...

Datum productie: (verwacht - uitgesteld) - uitgevoerd

Expand
titleDetails

Adresmatch op ingevoerde adressen

Alle ingevoerde adressen worden nagekeken of ze al dan niet overeenkomen met een bestaand adres uit het adressenregister. Wanneer een match gevonden wordt, wordt de juiste spelling van het adres overgenomen. Het adres krijgt dan ook een adres ID toegewezen (zie locaties.adresId.bronwaarde)

Statuspagina

Op https://www.vlaanderen.be/digitaal-vlaanderen/status/status-overzicht?product=Verenigingsregister vind je de status van de verschillende API’s op de 2 omgevingen terug. Je kan je ook abonneren op meldingen zodat je hiermee automatisch op de hoogte gebracht wordt van nieuwe releases en/of zware incidenten.

...