2020-07-29 Deprecations and their replacements

Several deprecated endpoints will be removed near the end of this year. For endpoints that have an available alternative, those alternatives have been enabled for all connectors that use the deprecated version on either staging and production. When the deprecated endpoints are removed, calls to those endpoints will fail with a 404 http status code. The endpoints and their replacements are:

  1. /t/users/by_user_name/{user_name} is replaced by /t/users/by_user_name?user_name={user_name}
  2. /t/clients/by_bsn/{bsn} is replaced by /t/clients/by_bsn?bsn={bsn}
  3. /t/dossier/medical/simplified/propensity_to_adverse_reaction is replaced by /t/dossier/medical/simplified_propensity_to_adverse_reaction
  4. /t/client_collab/shared_resources is replaced by /t/client_collab/shared_resources/{id}
  5. /t/portal/notifications is replaced by /t/hermes/notifications
  6. /t/dossier/action_entries/{id} and /t/dossier/demand_entries/{id} are a special case - please contact us or Maarten Botterhuis

Some endpoints will be removed without an alternative. These are all related to authentication - see Shield for more information:

  1. /t/authorization/user_team_responsibilities
  2. /t/clients/{client_id}/client_authorization
  3. /t/users/{user_id}/authorization_profiles
  4. /t/users/{user_id}/scoped_teams
  5. /t/users/{user_id}/viewable_locations

We will also be removing the /f/-context. For an explanation behind this choice, see our newspost of 2019-12-17.

  1. /f/teams/{id} is replaced by /t/teams/by_code/{code}
  2. Calls to /f/teams/{id}/$ are replaced by a call to /t/teams/by_code/{code} to gather the team id, and a subsequent call to /t/teams/{id}/$
  3. /f/employees/{id} is replaced by /t/employees/by_identification_no/{identificationNo}
  4. Calls to /f/employees/{id}/$ are replaced by a call to /t/employees/by_identification_no/{identificationNo} to gather the employee id, and a subsequent call to /t/employees/{id}/$
  5. /f/clients/{id} is replaced by either /t/clients/by_bsn?bsn={bsn} or /t/clients/by_identification_no/{identificationNo}
  6. Calls to /f/clients/{id}/$ are replaced by a call to either /t/clients/by_bsn?bsn={bsn} or /t/clients/by_identification_no/{identificationNo} to gather the employee id, and a subsequent call to /t/clients/{id}/$


The 5th of may 2020 is considerd a ‘banking holiday’in the Netherlands. Due to this overlapping with our maintenance window, we decided to re-schedule our maintenance window to the 6th of may (still between 19.00 - 22.00). We are sorry for the inconvenience this may cause.

2020-02-05 Removal of unsafe ciphers

During the maintenance window of February 4th we have dropped the support for two unsafe ciphers:


We were notified of this by two parties and have contacted the three other parties that are also affected.

2019-12-17 Deprecation of functional context

Ons API endpoints have always been offered in two contexts: technical and functional. Technical endpoints, starting with /t/, always behave as documented in the APIs overview. However, for clients, teams and employees we offered the functional context which allows the use of certain ‘logical identifiers’ (e.g. bsn or identificationNo) to be used instead of ‘technical identifiers’ (id).
We’ve decided to deprecate the functional context. Meaning that from now on, we will accept new endpoints on the technical context only. Reasoning behind this is that the functional context is often used incorrectly and seems to be increasingly confusing for new connectors.
For existing connectors the functional context will keep working; we do not have the intent to remove it completely.

2019-11-28 Problem with document upload on development

Development is experiencing issues with uploading and downloading of documents, where an error code “AWS S3 Access Key niet ingesteld” is returned. This is a known issue. We are working on a fix, however, it will take time to cleanly implement this. Receiving this error on development means the request was almost certainly correct and would have worked on staging and production. This should therefore not prohibit rollouts to staging.

2019-08-27 Deprecation of authorization & Shield APIs

When a customer environment is being switched over to Ons Autorisatie you should keep in mind that authorization APIs are not being used anymore and that requests returning empty bodies. All Shield APIs are being deprecated. See full list below:

  - delete /authorization/authorization_profiles/{}
  - delete /shield/definition/duties/{}
  - delete /shield/definition/roles/{}
  - delete /shield/definition/scopes/{}
  - get /authorization/authorization_profiles
  - get /authorization/authorization_profiles/{}
  - get /authorization/authorizations
  - get /authorization/authorizations/{}
  - get /authorization/user_location_responsibilities/x-stream-connect/data.xml
  - get /authorization/user_team_responsibilities/x-stream-connect/data.xml
  - get /shield/definition/roles
  - get /shield/definition/roles/{}
  - get /shield/definition/tasks
  - post /authorization/authorization_profiles
  - post /shield/definition/duties
  - post /shield/definition/roles
  - put /authorization/authorization_profiles/{}
  - put /shield/definition/duties/{}
  - put /shield/definition/roles/{}
  - put /shield/definition/scopes/{} 

2019-08-19 Welcome to the new API site

For the past months we have been working to get the Ons APIs available as an OpenAPI specification. And we’re happy to announce that we can now offer this specification for external parties to use!

Because of the new OpenAPI spec we also have more possibilities in generating our documentation. For instance, our old site did not offer an overview of our models, but now can we show the models in a separate section.

We’re still improving both the spec and the site so if you have any feedback, please let us know.

2019-03-26 Replacement of Healthcare Certificate Authorities

All certificates that have been given out by Nedap Healthcare are signed with a CA (Certificate Authority). The default life cycle of a CA at Nedap is 5 years and for External certificates that life cycle is coming to an end on Apr 13 17:08:49 2019 GMT.

This means that after that date no certificate signed with the current CA will work.

To make sure the continuity for our shared customers is safe we will distribute new certificates based on the last CSR (certificate signing request) that has been requested. This will happen in the next few days, if you haven’t received a new certificate on April 1st, please contact Nedap via Topdesk.

The newly distributed certificates can be used immediately so it is important to replace your current certificates as soon as possible! If you have any questions please send us a ticket via Topdesk.

We will distribute all the production certificates ourselves. If you require any development of staging certificates to be renewed please request them via Topdesk.

We’re excluding development and staging certificate from the distribution since these are used for a short period in most cases.

You can find the new chain under Security.

2018-08-01 - Data filtering

We, the Ons API team, are aware that there is sensitive data flowing through our APIs and we care about the information that we are sending. According to us it is necessary to send the least data as possible to a connector. Therefore we’ve build a functionality to filter out the requested data. We are doing that by only allowing specific fields from our models. For example: you are calling the client API and only need the birthday, firstname and address fields. The response will be a client thats been filtered on those 3 fields in stead of the complete client model. This gives as a result that the connector doesn’t get unnecessary fields and we can protect privacy better by minimizing the data. That’s why we’ve stopped with approving new connectors.

If you have already a connector running we want to test this functionality on development, but for the future on all our stages. Pay attention: if you want to continue using Ons API in the future, you have to take action. This functionality will be mandatory when you want to renew your certificate, because we enforce model filtering. We don’t know how your connector handles the filtered model, so maybe there is some work to do. When the connector works like expected on development, we can continue with configuring the settings on staging and eventually production.

Please send us a ticket in topdesk and mention your CN, the ‘GET’ API calls that you need and the necessary fields per API call.

2018-07-12 - Blocking unused API calls per connector

Before July 3rd it was possible to do every API call as long as you had a valid certificate, not anymore. For the last 3 months we have gathered a list of used API calls per connector, and now we are blocking all other API calls on both staging and production. We are still keeping it open for the development at the moment. If an API call is blocked you will receive a status code 403 with an “API call not allowed” message.

We are doing this for 2 reasons:

  1. Now we are actually enforcing that a connector can only do the API calls for which it was designed for.
  2. This makes sure there can be no connector development against the staging/production environment.

This means that if you are doing updates for your connector and adding functionality which requires API calls the connector didn’t do before, please open a ticket when you are ready to test the new version on a staging environment.

Besides blocking API calls, we are also working on filtering data. Meaning we can filter out unnecessary fields per API model. More on that soon!

If you have any questions, please let us know.