OpenBesluitvorming

OpenBesluitvorming is the successor to Open Raadsinformatie and provides access to the same type of information for the same levels of government. The platform was developed by Ontola and can be found at openbesluitvorming.nl .

It adds two features that its predecessor did not have: motions recorded with the vote of each individual member, and recordings of meetings with a transcript.

What’s inside

Recorded on 13 September 2026 by taking a measurement on the platform itself:

• 5,554,063 documents, compared with 5,146,062 on 12 August 2026;
• 329 organisations: 307 municipalities, 13 water authorities and 8 provinces;
• motions with voting records, and meeting recordings with transcripts.

How it’s structured

flowchart TD
    subgraph LEV["Suppliers"]
        IB["iBabs, 167 sources"]
        NB["Notubiz, 129 sources"]
        GO["GemeenteOplossingen, 34"]
        PA["Parlaeus, 4"]
    end

    LEV --> EX["Standardisation<br/>towards a single data model"]
    EX --> CD["Change detection<br/>any change<br/>is an event"]
    CD --> QW[("Search index")]
    EX --> S3[("Object storage<br/>originals, text,<br/>page images")]
    BB["BesluitBron"] --> API["Application API<br/>OpenBesluitvorming. nl/api"]
    API --> QW
    API --> S3

The platform records every change as an event and indexes those events. This means that not only can you see what is currently there, but also that something has been changed.

Strengths

• Motions, with details of how each member voted. In local government, this information is rarely available centrally;
• Recordings of meetings with a transcript, making the spoken word searchable;
• An application API rather than an exposed search engine. This makes the contract more stable than its predecessor;
• Searching for a phrase. Two or more words enclosed in double quotation marks must appear consecutively and in that order. This has been the case since 16 August 2026; before that, quotation marks had no effect.

Search by phrase

Words without quotation marks are combined using ‘AND’. They may appear on different pages, and the search result does not have to relate to the combination. Two or more words enclosed in double quotation marks must appear consecutively and in that order.

Use quotation marks for set phrases, quotations or addresses. Do not use them for a topic: in that case, it is better to use separate words, as a text may refer to the same topic using different wording.

There is a significant difference depending on the address. Measured on 16 August 2026, nationwide:

Of those 24 documents, exactly one appeared in the first 100 individual hits. The other 99 were included because the number 4 appeared somewhere as a page number, an article number or a measurement. That is why BesluitBron automatically combines a street name with a house number to form a phrase, even if you do not use quotation marks. The answer states this at query_sent and at more_to_find, so you can reverse the process by rephrasing the query itself.

Two things to bear in mind:

• A single word in quotation marks is not a phrase, but an ordinary word. The platform does, however, apply stricter criteria in such cases: the inclusion of related words is omitted;
• A phrase searches the title and the text, not the classification of an article.

This works from version 1.3.25 onwards. Up to and including version 1.3.24, quotation marks were ignored and the words were searched for individually.

Restrictions

• The total is not always exact. If the entire collection of search results fits within the scope of the platform’s search, the total is a count. If it does not, it is an estimate. BesluitBron reports both and adds ‘total_is_exact’ (approximate total), see Zoekprecisie. The search screen displays ‘approximately’ when an estimate is given. This has been the case since version 1.3.91. Up to and including version 1.3.90, BesluitBron omitted the estimate because the platform would then return a different figure for each query; since 6 September 2026, the platform has been returning the same figure, rounded to three decimal places;
• From version 1.4.6 onwards, BesluitBron always requests 100 rows from the platform, even if fewer are needed. The larger the page, the further the platform searches, and the more often it can provide an exact total. Measured on 12 October 2026: of 39 estimated totals, 18 were confirmed by a count. An example is a search for “motion” in Rijswijk from 10 to 12 November 2025: previously approximately 52, now exactly 52. A search query therefore costs 1.3 units instead of 1. Up to and including version 1.4.5, BesluitBron requested 24 rows;
• When using a broad search query, the browsing process tends to stop before all the results have been displayed. For each search query, the platform reads a maximum of 6,000 rows from the index, and a single document often occupies several of these rows. Measured on 15 October 2026 at gouda, type Document: approximately 14,500 results, of which 672 can be accessed with the newest first and 5,457 with the oldest first. A search for “budget” at gouda returns 1,521 of the 3,820 hits. Specifying a time period or a single type narrows the collection: all 2,513 documents from gouda dating from 2025 are accessible. The platform displays hasMore: true up to and including the page where it ends, and hasMore: false on the following page. From version 1.4.8 onwards, BesluitBron no longer displays next_offset on the page where the platform ends. more_to_find then states the reason window_capped, including the point where it ends and the estimated total, and window_note indicates that this marks the end of the browsing process and not the end of the search results. Up to and including version 1.4.7, BesluitBron displayed an next_offset on that page. The following page stated that the end of the results had been reached, whilst the total was well above that figure. Anyone wishing to see more should search using a single source, a single type or a specific period;
• There is a request limit of 60 weighted units per minute, enforced by the platform itself. On 12 October 2026, this was measured again: the limit has not been raised, and one unit per second has been added. A search query costs one unit, plus one unit for every 250 rows beyond the first 24. BesluitBron adheres to this limit and waits rather than continuing to send requests. The platform reduced this rate on 26 August 2026; prior to that, every 24 rows cost one unit, meaning BesluitBron retrieved less data per minute;
• The national parliament is not included, just as it was not in the previous version. The four suppliers this platform draws on are not used by the Tweede Kamer;
• The coverage is not the same as that of Open Raadsinformatie: 329 organisations compared with 331 sources. If you want to be sure that a particular municipality is included, you can check this at list_sources;
• Even an organ that is collected may still be missing parts. The platform compares itself with the supplier of each organ on a weekly basis. On 13 September 2026, 155 of the 330 organs compared were missing something, and in the case of one organ, 303 of the 311 parts from the past year were missing. The Laadstatus shows this comparison for each organ;
• A municipality formed as a result of a merger has, since 28 September 2026, also been providing documents relating to the dissolved municipalities. For example, voorne_aan_zee also provides documents relating to Westvoorne. The same applies to part of a municipality: amsterdam also provides documents relating to the Weesp urban area. On 15 October 2026, all 9 results for “Decision List AB” at amsterdam were documents relating to the Weesp urban area. Anyone wishing to search for documents relating solely to the former municipality or the urban area should use the relevant search term;
• From version 1.4.6 onwards, each hit has an source_key. This is the key of the body under which the platform has categorised the hit. If hits come from an organisation other than the requested source, other_bodies lists those organisations. This field specifies, for each organisation, the number of hits and the reason for its inclusion: a merger, including the date thereof, or the same local authority code from Statistics Netherlands (CBS). Up to and including version 1.4.5, the organisation was listed only in the source field of each hit, and the response itself contained no further information;
• Two municipalities that share a single site with their supplier are sometimes listed under one account and sometimes under both. On 15 October 2026, there were 98 meetings from 2026 listed under boxtel. The titles of 20 of these mention Sint-Michielsgestel. There were no meetings from 2026 listed under sint_michielsgestel. On 16 October 2026, the entire site for Druten and Wijchen was listed under druten and also under wijchen: 1,427 meetings and all 272 motions. The same applied to Voorschoten and Wassenaar, and to the dissolved municipalities of Cuijk, Grave, and Mill and Sint Hubert. A count for one of these municipalities therefore includes the others. For example, 202 of the 272 motions listed under druten come from the lists for Wijchen. Every deletion is recorded in the change log for both municipalities. No field on the platform specifies which municipality a meeting belongs to. From version 1.4.6 onwards, other_bodies therefore lists those meetings whose title mentions another body but not its own. From version 1.4.8 onwards, get_meeting does the same. In the case of a motion, the name of the list serves as proof, such as “Motions (Wijchen)”. From version 1.4.8 onwards, get_motion then specifies the other municipality. find_motions indicates this if the motions that BesluitBron reads for motion_register originate from such a list. A title or a list without a municipality’s name is meaningless. For example, the lists for Voorschoten are simply called “Motions” and “Amendments”. A document, a meeting or a motion without a municipality’s name may therefore still belong to the other municipality. Anyone attributing a list of decisions to a municipality should therefore first check the meeting. Up to and including version 1.4.7, get_meeting, get_motion and find_motions made no mention of this;
• Not every source of the type gemeente is a municipality. The seven districts of Amsterdam and the Weesp urban area also have this type. In addition, there are ten defunct municipalities included. On 15 October 2026, the 310 sources of the type gemeente corresponded to 302 different municipal codes from Statistics Netherlands (CBS). Of these, 292 were from a municipality that still exists. From version 1.4.6 onwards, list_sources provides the cbs_code for each source. A disbanded municipality is assigned discontinued_on and succeeded_by. Sources with the same code are assigned shares_cbs_code_with. The field cbs_codes counts the codes in the list. Therefore, when counting municipalities, one counts codes rather than sources;
• A motion may exist here without a document. As of 12 October 2026: for 11 out of 27 bodies using Notubiz, not a single motion submitted appeared as a document in the index, although they were listed as motions. find_motions is also incomplete: Notubiz only lists motions that have been voted on, whilst GemeenteOplossingen lists none. Anyone wishing to check whether a motion is missing should therefore search using both tools;
• On Notubiz, motions from before 2025 are almost entirely absent. As of 15 October 2026, out of all 129 bodies using Notubiz: 98 have motions, and 91 of those 98 have none dated from 2015 to 2024 inclusive. For 56 bodies, the register begins in 2025 or later. For 35, there are only a few motions from 2012 to 2014 inclusive, followed by those from 2025. An empty result for find_motions for a year prior to 2025 does not therefore mean that there were no motions for that body, but rather that data for that year has not been imported. The motion is often listed as a document in the index, under the relevant agenda item for the meeting. For example, Altena has the motion ‘Tackling rat-running’ listed as a document on 17 December 2024, and no motions at all in 2024. The platform does not import those years using the code for motions. This was reported in report 377. From version 1.4.8 onwards, this is also stated in the description of find_motions;
• For some of the bodies, the motion register contains only motions that have been adopted. Such a register is also known as a motion monitor: it tracks what happens to an adopted motion. A motion that has been rejected or withdrawn is therefore not included in find_motions. However, it is often listed as a document in the index. As of 15 October 2026: this applied to 12 of the 146 bodies using iBabs that submit motions, and to 3 of the 98 bodies using Notubiz. For 3 of these, the name of the register makes this clear, such as ‘Adopted Motions’. For the other 12, this is only apparent from the motions themselves. None of them have been rejected, withdrawn or deferred. The status is “Adopted”, or a processing status such as “Completed” or “Pending”;
• From version 1.4.6 onwards, find_motions indicates, for each body, whether the register contains only adopted motions. This is shown in the field motion_register, along with the grounds for the assessment and the counts. This works when the query concerns a single body. BesluitBron reads up to 100 motions from that body for this purpose. This costs one unit of the request limit, and the assessment is retained for four hours. In the case of a large register, this sample may omit a single rejected motion. For example, Westland is given the verdict ‘only adopted’, whilst 27 of its 1,451 motions were not adopted. Up to and including version 1.4.5, BesluitBron did not report anything about this;
• The list of motions for a meeting has the same scope as find_motions. It therefore does not contain everything that has been tabled. On Notubiz, only motions that have been voted on are listed; on GemeenteOplossingen, none are listed; and on Notubiz, almost none from before 2025 are listed. An empty list therefore does not mean that no motion was tabled. motions_note indicates this when the list is empty. According to its code, the platform reads a maximum of 100 motions per meeting. If the list contains exactly 100, one may therefore be missing, and motions_note also indicates this. This has not been verified for a meeting with that many motions. Measured on 17 October 2026 for the Haarlem council meeting of 3 November 2025: 39 motions, and 41 calls from get_meeting; find_motions and get_motion combined result in 1 call from get_meeting. At the Dijk en Waard council meeting of 6 October 2026: 13 motions and 15 calls count as 1. The list contains the same motions with the same results as those calls. In iBabs, an amendment may appear twice in the list: once with the appendix and once without. In the case of Dijk en Waard, 12 of the 13 entries were six pairs. The platform sends them in this format, including to find_motions. The frequency of this occurrence has not been measured. motions_count therefore counts lines and not always decisions. This has been the case since version 1.4.9. Up to and including version 1.4.8, there was no list in get_meeting;
• The result of a motion is often missing, or is labelled overig, even though the motion has in fact been passed or rejected. The platform retrieves the result from the status provided by the source. It only recognises the words ‘passed’, ‘rejected’, ‘withdrawn’ and ‘deferred’. A status such as “Accepted” or “Rejected” thus becomes overig. A status such as “Not adopted” even becomes aangenomen, because it contains the word “adopted”. This was the case for all 30 motions with that status at the Brabantse Delta water authority. The Province of Fryslân records the status in Frisian, such as ‘Oannommen’ and ‘Fersmiten’. There, all 553 motions are labelled overig. If the source does not provide a status, there is no result, even if the votes have been counted. As measured on 15 October 2026 across five randomly selected bodies using iBabs: 20 out of 46 motions had no usable result. For five bodies using Notubiz, all 60 motions had a result. From version 1.4.6 onwards, get_motion then displays in implied_result the result derived from the status, the name of the list or the count. A Frisian status is also taken into account from the same version onwards. This also applies to “unanimous”, which Brunssum uses for a motion passed by a unanimous vote. If the status indicates that the votes were tied, implied_result remains empty. outcome_note then indicates that a tie is not in itself a result. A list that cites the source “Motions (adopted)” or “Adopted motions” contains only adopted motions. outcome_note indicates the basis for this, or why no result is given. The platform’s fields status and result remain unchanged. Up to and including version 1.4.5, get_motion only passed on those two fields;
• A document that was previously found may later be marked as ‘not found’. Since 1 October 2026, the platform has been removing documents that the source of a meeting has deleted. Furthermore, a replaced file is assigned a new number. From version 1.4.6 onwards, the error message states this and recommends searching for the title again;
• A motion may refer to a meeting that the platform does not have. The field meeting_id of get_motion is the meeting cited as the source for the motion. The platform does not always have that meeting. In Heerenveen, on 15 October 2026, every meeting from 20 January 2023 up to and including 22 July 2024 was missing. The municipality does, however, publish them in iBabs. Consequently, all 58 motions from 26 January 2023 up to and including 18 July 2024 referred to a meeting that get_meeting cannot find. The platform’s weekly comparison with the supplier only looks at the last twelve months and therefore does not detect such a gap. In a random sample of 20 other iBabs municipalities, this issue did not occur. A 404 error for such a meeting therefore does not mean that it has been withdrawn or did not take place. The motion itself, including its title, date and outcome, remains usable. Anyone looking for the meeting should search using search_documents and the type Meeting on the same day, or check the municipality’s portal. From version 1.4.8 onwards, the error message for get_meeting states that the platform does not have the meeting and that this is not evidence of a withdrawal. The description of get_motion also mentions this. Up to and including version 1.4.7, the error message for every meeting stated that the ID had previously been removed;
• If the platform returns an exact zero, BesluitBron checks whether a search for “raad” across the whole country still returns any results. If that search also returns nothing, then the platform’s search index is broken. BesluitBron will then report a fault rather than displaying “nothing found”. This occurred on 12 October 2026 between approximately 10:00 and 11:20 Dutch time. This feature has been in operation since version 1.4.6.
• Almost all recordings are from 2025 or later. Only Notubiz’s organs have recordings. As of 15 October 2026: of the 129 Notubiz organs, 116 have at least one recording, and for 112 of these, there are no recordings from 2015 to 2024 inclusive. The recordings there begin in January 2025, with some organisations also having recordings from 2012 to 2014. There are 4,902 recordings from 2025, but only 135 from 2024. It has not been established whether Notubiz has the earlier recordings or whether the platform has not yet imported data for those years. A meeting held before 2025 without a recording is therefore not necessarily unrecorded. From version 1.4.8 onwards, find_recordings and get_recording state this themselves, and get_recording displays it beneath a meeting from before 2025 without a recording. Up to and including version 1.4.7, there was no such information. The query to the platform can be found at #377.

Address and tools

Address: https://besluitbron.nl/mcp/openbesluitvorming/v1. The old address without /v1 will remain accessible.

• list_sources: the affiliated organisations, together with their type and their CBS local authority code;
• corpus_stats: the size of the corpus. Use this figure to indicate the size; never use the total number of results from a search;
• search_documents: search within the documents. Enclose two or more words in double quotation marks to search for them as a phrase. A street name with a house number is automatically treated as a phrase, and the result shows in query_sent what was searched for. When a source is included, other_bodies indicates which hits belong to another organisation;
• get_document: a single document containing its text;
• get_meeting: one meeting with its agenda and motions. From version 1.4.6 onwards, the download link for a document points to the copy on the platform itself. This link works even where the iBabs link returns an error message. From version 1.4.8 onwards, the response also includes source_key, and other_bodies lists the other municipality as the title mentioned. From version 1.4.9 onwards, the motions from the meeting are listed in motions. Each motion shows the status and result as provided by the platform. Where the source provides a vote count, this is also included. If the result is missing or incorrect, implied_result and outcome_note show what follows from the record, just as with get_motion. The vote of each councillor is not included. member_vote_count states how many votes there are, and get_motion lists them. A motion has the same fields in the list as in get_motion, with two exceptions. The votes are missing, and the address of the annex, in download_url and attachment_is_pdf, appears only in the list. Furthermore, the identifier in the list is motion_id, whilst for get_motion it is entity_id. motions_count counts the motions, and motions_note specifies what the list does and does not include. If motions come from a register containing only adopted motions, register_note indicates this. other_bodies also mentions the other municipality when referring to the name of the register of motions. Up to and including version 1.4.8, get_meeting only displayed the agenda. Anyone wishing to find out the results of a meeting would search for the motions using find_motions and then call up get_motion for each motion;
• upcoming_meetings: the scheduled meetings;
• find_motions: search for motions and amendments. The result does not specify a match. get_motion provides this for a single motion, and from version 1.4.9 onwards, get_meeting provides it for all motions from a single meeting. If the query concerns a single body, motion_register indicates whether that body’s register contains only adopted motions. If motions from that register originate from a list belonging to another municipality, other_bodies will specify that municipality, from version 1.4.8 onwards;
• get_motion: a single motion containing all the information provided by that motion’s platform. This includes the result, the vote count and, where the source provides it, the vote of each councillor. From version 1.4.9 onwards, the other fields relating to the motion are also included, such as parties, vote_summary, date, agenda_item or agenda_item_hint, attachment_id and proposers, as well as any fields the platform may add in future. In Notubiz, vote_summary, for example, “Against: OPH”, is the only information the source provides about the vote. Up to and including version 1.4.8, get_motion did not provide those fields, even though they were included in the list of get_meeting. The address of the attachment is not included with the motion itself, so download_url and attachment_is_pdf only provide get_meeting. Using attachment_id, the attachment can be retrieved via get_document. If a usable result is missing from the platform, implied_result indicates what follows from the status or the count. If the name of the register indicates that it contains only adopted motions, register_note reports this. The field meeting_id specifies the meeting cited as the source for the motion; the platform does not always have this information, see the limitations above. From version 1.4.8 onwards, other_bodies lists the other municipality alongside the name of the list it refers to. From version 1.4.9 onwards, the motions from a meeting are also included in get_meeting, without the vote of each councillor. Only this tool provides those votes;
• topic_timeline: the development of a topic over time;
• find_recordings: meetings for which the platform has a recording, with the most recent ones listed first. Almost all recordings are from 2025 or later; see the ‘Limitations’ section. From version 1.4.8 onwards, a time period can be specified using date_from and date_to, just as with search_documents and find_motions. A date refers to a full day in UTC. The platform then filters the results based on the meeting date, and the response covers that period. Consequently, the total is more often an exact figure. Measured on 16 October 2026 for haarlem: without a time period, approximately 317 recordings; from June to December 2025 inclusive, exactly 66. From the same version onwards, the result also includes total_is_exact, source_distribution and more_to_find, and for each meeting match_type; see Zoekprecisie. Up to and including version 1.4.7, the tool did not support a time period. Anyone searching for an earlier period had to scroll through all the more recent meetings. Any specified date_from or date_to was ignored without notification;
• get_recording: a single recording, showing the time in the recording for each agenda item. The platform also provides a transcribed text for some of the recordings. This text has been generated by speech recognition and is not a report. This tool does not include that text; search_documents, using the type Recording, does, however, search through it. From version 1.4.6 onwards, search_documents indicates, for each match in summary_source, where the excerpt comes from. With the type Recording, this is always the transcript; with the type Meeting, it never is. Without a type, it could be either in the case of a meeting, as the platform does not specify. summary_note then explains how to use such an excerpt. Up to and including version 1.4.5, there was no accompanying text;
• list_platform_calls: the calls to the platform in this session.

In addition, list_capabilities.

municipality``list_sources The response thentype specifies, in type_applied, the Dutchgemeente``provincie``waterschap``verzameling value that was used. If theall_ibabs requestedOpen Raadsinformatie typeprovince doeswater_authority not exist, the response indicates this in type_not_recognised, listing the types that are available.

This works from version 1.4.6 onwards. Up to and including version 1.4.5, the tool’s description gave municipality as an example. That value returned zero sources, without any message.

Where to find this platform

These addresses belong to the organisation behind this source and not to BesluitBron. Anyone who finds an error in the data or in this source’s API should report it there:

• Report a bug: the OpenBesluitvorming issues on GitHub ;
• Read the API: API.md ;
• Search for yourself on the source website: OpenBesluitvorming.nl .

This is the source where reports have so far been dealt with most quickly: seven of the eight issues reported by BesluitBron in August 2026 were resolved within a few days.

These addresses were checked on 18 August 2026. No email address has been included deliberately: where a party publishes only an address, BesluitBron refers to the page on which that address appears.

What this source is suitable for

For two questions that no other local source answers: how did each councillor vote, and what was said during the meeting? For both of these, BesluitBron is the only local source of information.

What it is not for

For an exact figure on a broad topic. A broad query returns more results than the platform can process, so the total is an estimate. A narrow query, however, does return an exact figure: a phrase, a single organisation or a single period is usually sufficient. If you need an exact figure on a broad topic, use Open Raadsinformatie.

Current situation, as of August 2026

This is the follow-up to Open Raadsinformatie and does include new material. Of the 316 documents viewed on 16 August 2026, the most recent harvest stamps were dated up to 15 August.

As with its predecessor, the current status varies by body. Since 16 August 2026, this platform has been publishing its own data status for all bodies simultaneously, and the Laadstatus retrieves this in a single call. This specifies, for each body, whether the platform still retrieves its data, which source system underpins it, and whether an organisation has been dissolved. Up to and including version 1.3.22, retrieving this status required one call per organisation and was spread over four hours.

This means that a fault in a single source system is also flagged as a fault. In August 2026, 161 of the 330 organisations received no new data – not for 161 separate reasons, but because iBabs blocked the address from which the platform retrieves data.

list_sources displays the date for each organ once the list has been narrowed down to a maximum of eight organs. That tool does, however, make one call per organ, because it answers a slightly different question: it searches for the most recent item that is not in the future, whilst the load status returns the most recent date known, even if that date has yet to occur.

Up to and including version 1.4.7, list_sources did not display a date for authorities with a large number of scheduled items, such as Amsterdam and Haarlem. At that time, the tool only read the 75 most recent items, all of which were scheduled for the future. The response explained this, but the date itself was missing. From version 1.4.8 onwards, the tool directly requests the latest document up to and including today from the platform. Such organisations now also receive a date.

Please note when reading these dates: they refer to the meeting and not to the time of harvest. During a recess, the latest meeting date therefore automatically falls behind, without anything coming to a standstill.