openapi-directory
Version:
Building & bundling https://github.com/APIs-guru/openapi-directory for easy use from JS
1 lines • 6.33 MB
JSON
{"openapi":"3.0.2","servers":[{"description":"Production environment","url":"https://api.loket.nl/v2"},{"description":"Acceptance environment","url":"https://api.loket-acc.nl/v2"}],"x-hasEquivalentPaths":true,"info":{"description":"<span style=\"color:green\">**Is this your first time here? Please check out our [introduction to Loket (API)](./Introduction)**</span>\n\n**The initial loading time of this developer portal may be very long due to the large number of endpoints designs being rendered when loading the page.\nWe are looking into an alternative solution but for now please bear in mind.**\n\n\n# General\nThe Loket.nl API is a RESTful API that exposes the data and features of the Loket.nl platform.\nThe API accepts and returns JSON and can only be accessed by registered users.\nThis documentation describes version 2 of the API.\n\n\nAre you looking to partner up and start building an integration based on the Loket RESTful API? Please check out the steps for partners on our [website](https://www.loket.nl/koppelingen/koppelen-met-loket/) .\n\nHave you received your client and user credentials from us? Check out the following Postman collection to help you start making your first API calls on our acceptance environment. We would recommend to install the Postman desktop app.\n\n[](https://god.gw.postman.com/run-collection/19604713-42728000-2df3-4ff0-908e-dc6ab410990c?action=collection%2Ffork&collection-url=entityId%3D19604713-42728000-2df3-4ff0-908e-dc6ab410990c%26entityType%3Dcollection%26workspaceId%3Ddde2c409-9fb2-4f40-9981-f937f73750ea#?env%5BLoket.nl%20Test%20Environment%5D=W3sia2V5IjoiQXV0aGVudGljYXRpb25TZXJ2ZXJVcmwiLCJ2YWx1ZSI6Imh0dHBzOi8vb2F1dGgubG9rZXQtYWNjLm5sLyIsImVuYWJsZWQiOnRydWUsInR5cGUiOiJ0ZXh0Iiwic2Vzc2lvblZhbHVlIjoiaHR0cHM6Ly9vYXV0aC5sb2tldC1hY2MubmwvIiwic2Vzc2lvbkluZGV4IjowfSx7ImtleSI6Ikxva2V0QXBpVXJsIiwidmFsdWUiOiJodHRwczovL2FwaS5sb2tldC1hY2MubmwvIiwiZW5hYmxlZCI6dHJ1ZSwidHlwZSI6InRleHQiLCJzZXNzaW9uVmFsdWUiOiJodHRwczovL2FwaS5sb2tldC1hY2MubmwvIiwic2Vzc2lvbkluZGV4IjoxfSx7ImtleSI6IkNsaWVudF9JZCIsInZhbHVlIjoiIiwiZW5hYmxlZCI6dHJ1ZSwidHlwZSI6InRleHQiLCJzZXNzaW9uVmFsdWUiOiIiLCJzZXNzaW9uSW5kZXgiOjJ9LHsia2V5IjoiQ2xpZW50X1NlY3JldCIsInZhbHVlIjoiIiwiZW5hYmxlZCI6dHJ1ZSwidHlwZSI6InRleHQiLCJzZXNzaW9uVmFsdWUiOiIiLCJzZXNzaW9uSW5kZXgiOjN9LHsia2V5IjoiUmVkaXJlY3RfVXJpIiwidmFsdWUiOiIiLCJlbmFibGVkIjp0cnVlLCJ0eXBlIjoidGV4dCIsInNlc3Npb25WYWx1ZSI6IiIsInNlc3Npb25JbmRleCI6NH0seyJrZXkiOiJyZWZyZXNoX3Rva2VuIiwidmFsdWUiOiIiLCJlbmFibGVkIjp0cnVlLCJ0eXBlIjoidGV4dCIsInNlc3Npb25WYWx1ZSI6IiIsInNlc3Npb25JbmRleCI6NX0seyJrZXkiOiJ0b2tlbiIsInZhbHVlIjoiIiwiZW5hYmxlZCI6dHJ1ZSwidHlwZSI6InRleHQiLCJzZXNzaW9uVmFsdWUiOiIiLCJzZXNzaW9uSW5kZXgiOjZ9XQ==)\n\n\nDo you want to contact us with any further questions or remarks regarding the Loket RESTful API? Please send an email to api@loket.nl, and we will get back to you.\n\n\n## Environments\nThe Loket.nl API has two different environments.\nThe first environment is the \"acceptance\" environment which is used during development and returns test data.\nThe second environment is the production environment which is to be used exclusively by approved applications.\nBoth environments have their own URLs.\n* The acceptance environment can be accessed at https://api.loket-acc.nl/v2/ \n* The production environment can be accessed at https://api.loket.nl/v2/\n\n## OpenAPI documentation\nThe endpoints are defined using the [OpenAPI 3.0 specification](https://github.com/OAI/OpenAPI-Specification),\nan industry-wide recognized standard for describing REST API's.\n\n__Please note:__ the endpoint documentation in this portal is not designed to be fully compatible with any automatic code generation tools.\n\n## Change policy\nOver the course of time the API, and policies regarding the API can and will change. These changes are subject to the following guidelines.\n\n\nThe following states hold true for the change policy for this API.\n\n* Loket.nl may sometimes introduce changes to the API and policies without advance notice. \n* Loket.nl will try to inform users of any (breaking) change in advance.\n* Loket.nl will not be liable to you or any third party for such modifications or any adverse effects resulting from such modifications.\n* Loket.nl will try to avoid breaking changes as much as possible.\n\n## Notification periods\nIn regard to changes Loket.nl will strive to adhere to the following notification periods per type of change.\nDue to our versioning strategy at resource level this API has the possibility to run multiple versions of the same resource at one time.\nThis allows for a window in which both the old and new version are available.\nAllowing for a gradual move to the new version. \n\n| Type of change | Notification period | Support period old version |\n|------------------|---------------|---------------|\n| Non breaking change | 2 weeks | no new version |\n| Breaking change | 2 weeks | 6 months |\n| Critical | Due to the nature of these changes we might not be able to follow the normal procedure for change managment | depends on the severity of the issue | \n\n\nWe define a __non breaking__ change as follows. Any change to the API that does not cause failures in the applications that consume that API.\n * Introducing a new optional field to an existing resource\n * Introducing a new endpoint\n * Introducing a new operation (GET/PUT/POST/PATCH/DELETE)\n * Introducing a new optional parameter to an endpoint\n * Introducing a new version for a resource\n\nWe define a __breaking change__ as follows. any change to an API that could potentially cause failures in the applications that consume that API.\n * Changing an existing JSON element (name, datatype, pattern, min/max length etc)\n * Removing a JSON element, endpoint, operation or parameter\n * Introducing a required JSON element\n * Introducing a required parameter to an endpoint\n * Passing the `obsoleteDate` of a version for a resource\n\n## Versioning\nThe Loket API uses two types of versioning. API versioning and resource versioning. \n\n\n__API versioning__\n\nAPI versioning is done via the path where after the domain URL (api.loket.nl) the path starts with the API version. The current version of the API is V2.\nThe API version is expected to change rarely as resource versioning is available to tackle most issues that need versioning.\n\n\n__Resource versioning__\n\nEvery __JSON__ resource in the API is versioned via the Accept header.\nAllowing users of the API to influence what version is returned by setting the __mandatory__ accept header.\nThe Accept header of request should have a value like `application/json;version=2018-01-01`. \nHere, the second part of the header is used to refer to a specific version of the resource (2018-01-01).\nWhen calling the API it is possible to supply other dates rather than the exact resources version(s). \nThe businesslogic will select the version that is ON or BEFORE the given date.\n\n\n__For example:__ let's say there are two versions of a resource.\nThese are 2018-01-01 and 2018-09-01. When calling the API you supply `application/json;version=2018-08-01`,\nin that case the API will use the version 2018-01-01 as its the nearest version in the past. \n\n\nA response returns what `resourceVersion` was used and the 'obsoleteDate' of that version (in most cases this is NULL).\nThe `obsoleteDate` indicates when the resources version will no longer be available via the API.\nWith the introduction of a new version of a resource the `obsoleteDate` for the old version will be set to 6 months after the introduction of the new resource. \nAllowing consumers of the resource 6 months to incorporate the change. Failure to do so will likely lead to failure in the implementation.\n\nIn this developer portal you can find the service contracts for each, active, version of a resource.\nIf, only if, there are multiple versions of a resource you can select the corresponding schema at that resource.\n\n## Changelog\nThe changelog for this API can be found [here](/Changelog).\n\nWe strongly advise every user ofthe Loket REST API the subscribe to the email feed. Please check out the link on the changelog page.\n\n\n## Legal notices\nYour use and access to the API is expressly conditioned on your compliance with the policies and restrictions related to the API. \nIf Loket.nl believes that you have or attempted to violate any term, condition, or the spirit of these policies or agreements, your right to access and use the API may be temporarily or permanently revoked. \n\n# Authentication\nAuthorization in the Loket API is based on the industry-standard OAuth 2.0 protocol. For general information on OAuth 2.0 we kindly refer to the publicly-available documentation, https://oauth.net/2/ \n\n\nAn authorized user is required to call the Loket API.\n\n__Note:__ This is an SSL-only API.\n\n__Note:__ Only TLS 1.2 is supported.\n\n| Environment | TokenUrl | \n| -------------------- | -------------------------------- | \n| Acceptance | https://oauth.loket-acc.nl/token |\n| Production | https://oauth.loket.nl/token | \n\nThe following OAuth 2.0 flows are supported\n\n* Authorization Code flow (standard)\n* Refresh Token flow (extension on the Authorization Code Flow)\n* SSO flow (single sign-on)\n* Password flow\n\n## Authorization code flow\nFor most clients only the authorization_code (and thus refresh_token) will be supported. \nPassword grant type is not available for an external client.\n\nPlease click the link below to see documentation on implementing the authorization code flow by external clients.\n\n__[Documentation on implementing the OAuth 2.0 authorization code flow](./OauthCode)__\n\n## Refresh token flow\nAfter the authorization code flow yields a refresh token the refresh_token grant can be used to obtain an access/bearer token.\nThe expire time of the access/bearer is also returned in the response please take this into account.\nWith the refresh token flow the two factor step will be skipped.\n\n_Refresh token request example:_\n```\nPOST /token \ngrant_type=refresh_token&refresh_token={RefreshToken123}&client_Id={Client123}&client_secret={Secret123}\n```\n\n_Refresh token response example:_\n```json\n{\n \"access_token\": \"JESJDhMBy0NPTM9SiXmYAzW45clOiQ5wSyDq3VWluguGNoKym4WPSiJoTDx67TQ\",\n \"token_type\": \"bearer\",\n \"expires_in\": 3599,\n \"refresh_token\": \"nGJtF6j6SeQbHAg\",\n \"two_factor_state\": \"None\"\n}\n```\n## SSO flow\nThe SSO (single sign-on) flow is based on OAuth 2.0 and requires the authorization flow to be completed.\n\n__For more information see:__ [Documentation on OAuth 2.0 SSO flow (for allowed clients)](./OauthSSO)\n\n\n__Please note:__ Among other things, it is possible to set up an SSO flow with both Loket en Werknemerloket.\n\n\n## Password flow\nThe password flow is typically NOT enabled for external clients. Only by exception will the password flow be enabled for security (and practical) reasons.\n\n_Password token request examples:_\n\n```\nPOST /token \ngrant_type=password&username={UserName123}&password={Password123}&client_Id={Client123}&client_secret={Secret123}\n```\nWhether client_secret is required is dependent on the configuration of the client.\n\n# Authorization\nIn this section we explain how the API authorization service determines if a request is authorized or not.\n\n## The authorization entities\n\n| Entity | Description |\n| ----|----|\n| Client | Loket.nl used the client as an additional authorisation entity. By linking clients to activities clients can only perform those activities they are linked to. |\n| User | Is linked to a client (by performing the authorization code flow) and to a set of rechten (configuration in loket.nl)|\n| Module (product) | Enables certain functionality for the provider/employer. Modules can be enabled and disabled on both provider and employer level.|\n| Role | Influences if certain \"rechten\" are available to the users with said role. It can also influence the scope of the data returned. For example: the API will deny an \"afdelings manager\" access to employee's that are not in the \"afdeling\" (department) that user is manager of|\n| Activity | Every action in the API has its own activity. Using the Open API 3.0 standard these activity names are incorporated in the documentation using the `operationId` and in most cases are named in the description of an endpoint.|\n| Rights (rechten) | Represent a group of activities.|\n\n## The authorization process\nThis flow assumes that both user and client are correctly configured and have access to the API. \n\n1. Does the client have access to the activity?\n2. Does the user have access to the activity (through \"recht\")?\n3. Does the role have access to the activity (through \"recht\")?\n4. Does the provider/employer have the required module enabled for the activity?\n5. Does the user have access to the specified entity/ID?\n\nIf the answer to all the questions above is yes then the request is authorized otherwise the request is denied with a HTTP status code 403 (Forbidden).\nSee the simplified authorization flow in the figure below.\n\n__Side note:__ users are linked to rechten and clients are linked to activities. This leaves room for discrepancies.\nWhere a client cannot perform the activity because the client is not authorized to call that activity even though the user does have the \"recht\" granting access to the activity.\n\n\n\n## Which users can use the API\nIn almost all use-cases a Loket user should meet the following requirements to successfully setup an integration with that user.\n\n* The user must be a normal Loket user (so NOT a webservice user)\n* The user must be active (not blocked)\n* The user must have access to an employer \n * For provider users this is done by assigning the user to the appropriate Team(s)\n * For employer users this is done by creating a user for or linking the user to the appropriate employer(s)\n* The user must have all appropriate rights\n * For provider users this is done by assigning appropriate rights via Team (or alternatively, directly to the user)\n * For employer users this is done by assigning appropriate rights to the user on employer level\n\n\nHow to setup an integration is described in the [Authentication](../#section/Authentication) section.\n\n\n__Side notes:__ \n* A user can have access to multiple employers with different rights per employer.\n* Please note that users set up to use the SOAP webservices (webservicegebruikers) are in no way suited to perform calls to the RESTful API, these require entirely different user set-ups.\n* User management on production is typically done by the provider (i.e. the accountant) and sometimes the employer. This is NOT something Loket.nl itself can do.\n\n# Data\n\n## Data types\nThe Loket.nl API accepts and returns JSON.\nComform the [OpenAPI 3.0 specification](https://github.com/OAI/OpenAPI-Specification) the following data types are supported:\n* string\n* number (point is used to separate the integer part from the fractional part of a number)\n* integer (from OpenAPI)\n* object\n* array\n* boolean\n\nFor most of these types, further specifications can be found in the `format` and `pattern` specifications in the service contract. \nFor example a `format: date` added to a string field indicates a valid date must be supplied.\n\n## Metadata\nFields of the type 'metadata' are fields for which the possible values can be acquired via the metadata endpoint of the resource.\n\nThe metedata can be obtained by appending /metadata to the current endpoint.\nUsing the GET verb the endpoint will return a JSON output with \"all\" the metadata for the given resource.\nIn some cases multiple requests are needed to obtain all the metadata required, an exmple is given below.\nTypically different metadata endpoints are availalbe for the POST and the PUT endpoint.\n\n\nIf metadata endpoints are avaible for a given endpoint/resource is mentioned in the description of that endpoint.\n\n### Example response\n```json\n{[\n {\n \"field\": \"gender\"\n options: [\n {\n \"key\": 1,\n \"value\":\"Man\"\n }\n {\n \"key\": 2,\n \"value\":\"Vrouw\"\n }\n ]\n },\n {\n \"field\": \"country\"\n options: [\n {\n \"isoCode\":\"NL\",\n \"key\": 530,\n \"value\":\"Nederland\"\n }\n {\n \"isoCode\":\"BE\",\n \"key\": 540,\n \"value\":\"België\"\n }\n ]\n }\n\n]}\n\n```\n\n\n### Example urls\n\n__Acquiring metadata for a POST Wage__\n```\n/v2/providers/employers/employees/employments/{employmentId}/wages/metadata\n```\n\n\n__Acquiring metadata for a PUT employee__\n```\n/v2/providers/employers/employees/{employeeId}/metadata\n```\n\n__Multiple requests to get all the metadata__\n\nIn some cases there are metadata fields dependant on the selected value off another metadata field.\nSuch is the case when adding a new concept employee. This is done in the employer context while several of the metadata fields are dependant on the payrollAdministration context.\n\n\n__For example:__\n\n__Request 1__, first of a normal metadata request is performed. The response for this request will contain a list of payrolladministration for the given employer.\n```\n/v2/providers/employers/b869ded6-0659-4d8d-9a8a-f9e22425ec9c/jobapplicant/metadata\n```\n\n__Request 2__, when a payrolladministration is selected perform a second request to acquire the payrolladministration specific metadata.\n```\n/v2/providers/employers/jobapplicant/metadata/payrolladministration/54369214-14a1-41ab-892a-ea8438e34d6f\n```\n\n__Request 3__, if a `payScale` is selected perform a third request to acquire the `payGrade` for that `payScale`.\n```\n/v2/providers/employers/jobapplicant/metadata/salaryScaleType/54369214-14a1-41ab-892a-ea8438e34d6f\n```\n\n### Types of metadata\nWe diferentiate between two types of metadata.\n\n1. Generic metadata field. The possible values for these fields are the same for every object no matter the provider, employer or employee etc. \nExamples are: country, gender and nationality.\n2. Context specific metadata field. Examples of contexts are employer, payroll administration, provider and Loket.nl.\nIn most cases the possible values for these field are resources in themselves and can be managed via the API. \nIf a metadata field is context specific the context is given in the description of the field. \nExamples are: function, department and leaveType.\n\n\n__Note:__ some context specific metadata field can have multiple contexts. \n\nFor example: it is possible to define an export set in the provider context. \nMaking that export set available for all payroll administrations linked to the provider. \nIt is also possible to add an export set in the payroll administration context. That export set is only available to that payroll administration.\nWhen requesting the metadata of export set the user will be presented with a combined list of the provider and payroll administration export sets.\n\n## Default values\nMany fields in the API have a default value. \nIn order to assist our API users to adhere to these defaults when creating a record (POST) we provide `/defaults` endpoints.\n\n* An object returned by the `defaults`endpoint resembles a fully expanded GET-object of that resource. The only case when a part of the object is NOT fully expanded is for a metaData-object that does not have a default value (for example '\"gender\":NULL'). \n * Whether an object within the resource is of the type metaData is indicated in the service contracts of that resource.\n* Context is determined by the GUID given in the Path. Examples are employer, payroll administration, employee and employment.\n* A scope is sometimes required to determine the defaults values. A scope could be a date by which Loket.nl can determine what default was active on that date. \n The scope can be set by supplying additional paraments in the request. If a scope is required but none is given the currently active or last know value is returned.\n* The fields with no default will be set to null (even if the field is normally non-nullable).\n* Because the GET-object is returned the readonly fields are also returned.\n\n\n\n__An example endpoint would be:__\n\n```\n/v2/providers/employers/employees/employments/{employmentId}/payrollperioddata/defaults\n```\n\n__resulting in the following output:__\n\n```json\n{\n \"payrollPeriod\": null,\n \"shift\": {\n \"shiftNumber\": 1\n },\n \"payslipType\": {\n \"key\": 2\n },\n \"payslipText\": null,\n \"distributionUnit\": {\n \"key\": \"b14acd0d-75d7-4fc8-8b22-4a3924585cab\"\n },\n \"costCenter\": {\n \"key\": 2\n },\n \"costUnit\": {\n \"key\": 2\n },\n \"payrollComponents\": []\n}\n```\n\n__Note: Defaults endpoints are not yet generically available. If a Defaults endpoint exists this will be explicitly stated at that specific resource.__\n\n## Date chains\nFor most of the resources with a startDate and endDate a chain is maintained. Chain meaning that no records can overlap in time.\nLoket.nl has two types of chains.\n\n\n1) __Broken chain:__ It is posible for gaps te exist between the records. It is also posible to add new records in between or before existing records aslong as no overlap occures.\n\n2) __Linked chain:__ No gaps between records are allowed. Its only posible to add new records to the end of the chain resulting in the closing of the reviouse record with the start date -1 as end date.\n\n__Note:__ Chains are sometimes maintained with an additional context. For example, For `benefits and deductions` the broken chain is maintained per `payrollComponent`. \nIt is possible to have multiple active records for different `payrollComponent` never two active records for the same `payrollComponent`. \n\n## Custom export\nFor some GET (list) endpoints the API supports exporting (part of) the output JSON as a XML/CSV file. This is done by setting the `X-ReportInput` and `Accept` header.\n\nThe `Accept` header supports the following 2 options:\n* CSV (text/csv;version=yyyy-MM-dd)\n* Excel (application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;version=yyyy-MM-dd)\n\n\nThe `X-ReportInput` is a custom header that requires a JSON object with the following structure as input.\n\nThe filename without extension for the report 'FileNameWithoutExtension'\ndelimiter --> The delimiter to be used. If not set \",\" is used\nArray of objects 'fields' with 2 fields:\n1. fieldName --> A Xpath reference to the field to be included in the export\n2. reportColumnName --> The column name for the field\n3. format --> Allows only for date formatting. e.g. dd-MM-yyyy for csv or dd-mm-yyyy for Excel (Excel only usses lowercase)\n 3.1 For CSV: see https://learn.microsoft.com/en-us/dotnet/standard/base-types/custom-date-and-time-format-strings\n 3.2 For Excel: https://support.microsoft.com/en-us/office/number-format-codes-5026bbd6-04bc-48cd-bf33-80f18b4eae68\n\n__Example `X-ReportInput`:__\n```json\n{\n\"fileNameWithoutExtension\":\"MyExport\",\n\"delimiter\": \";\",\n\"fields\":\n [\n {\n \"fieldName\": \"startDate\",\n \"reportColumnName\": \"In dienst datum\",\n \"format\": \"dd-MM-yyyy\"\n },\n {\n \"fieldName\": \"personalDetails.firstName\",\n \"reportColumnName\": \"First Name\"\n },\n {\n \"fieldName\": \"personalDetails.lastName\",\n \"reportColumnName\": \"Last Name\"\n }\n ]\n}\n```\n__Example request:__\n```CURL\ncurl \n--location \n--request GET 'https://api.loket.nl/v2/providers/employers/155c8440-8ff6-4776-98db-5d2243a073e3/employees?orderby=employeeNumber' \\\n--header 'Content-Type: application/json' \\\n--header 'Accept: text/csv;version=2020-08-18' \\\n--header 'X-ReportInput: {\"FileNameWithoutExtension\":\"MyExport\",\"Fields\":[{\"fieldName\":\"personalDetails.initials\",\"reportColumnName\":\"Initials\"},{\"fieldName\":\"personalDetails.firstName\",\"reportColumnName\":\"First name\"},{\"fieldName\":\"personalDetails.lastName\",\"reportColumnName\":\"Last name\"}]}' \\--header 'Authorization: Bearer ZKoiC_g_NfYA3v0' \\\n```\n\n\n# Request\nA request to the Loket.nl API consists of several components.\nEach of these components are discussed in this section.\n\n## Base URL\nThe API can be accessed at [https://api.loket.nl](https://api.loket.nl).\n The version of the API is specified in the URL. The current version of the Loket.nl API is version 2. To access version 2 of the API, one simply appends `v2` to the base URL. The full base URL of the API is therefore [https://api.loket.nl/v2](https://api.loket.nl/v2).\n\n## Endpoints\nThe endpoints defined in the OpenAPI definition of the Loket.nl API are appended to the base URL. For example, the endpoint `/providers/employers/{employerId}/employees` can be accessed at [https://api.loket.nl/v2/providers/employers/{employerId}/employees](https://api.loket.nl/v2/providers/employers/{employerId}/employees).\n\n## Path parameters\n\nMost endpoints require path parameter(s) in order to specify the context of the request. For example, the endpoint `/providers/employers/{employerId}/employees` contains the `employerId` path parameter. A path parameter is a unique identifier that identifies a specific resource, in this case an employer.\n\n## Pagination\n\nThe API supports two query parameters to control the pagination of the results: `pageNumber` and `pageSize`. Both of these query parameters only apply to endpoints that return lists of entities.\n\nThe `pageNumber` query parameter specifies which page of the collection to return. By default `pageNumber` is set to 1 which returns the first page of the collection. Note: the pageNumber refers to the page (with a given number of entities), NOT to a specific entity within a page!\n\nThe `pageSize` query parameter influences the number of entities per page. By default `pageSize` is set to 250. Note that this default may change in the future. It is not recommended to depend on this default when developing for the Loket.nl API.\n\nExamples:\n\n* ```?pageNumber=2``` to return the second page\n* ```?pageSize=2``` to set the page size to two\n\n## Filtering\n\nThe API supports output filtering via the querystring parameter `filter`.\n\nFiltering is possible on all fields of the following datatypes:\n\n* string\n* integer\n* boolean\n* date-time\n* decimals\n\nThe following operators are available:\n\n| Operator | Description | Example |\n| -------------------- | --------------------- | ------------------------------- |\n| Comparison Operators | | |\n| eq | Equal | `city eq 'Redmond'` |\n| ne | Not equal | `city ne 'London'` |\n| lk | Like | `city lk 'Lond'` |\n| gt | Greater than | `price gt 20` |\n| ge | Greater than or equal | `price ge 10` |\n| lt | Less than | `price lt 20` |\n| le | Less than or equal | `price le 100` |\n| Logical Operators | | |\n| and | Logical and | `price le 200 and price gt 3.5` |\n| or | Logical or | `price le 3.5 or price gt 200` |\n\nBoth field names and values are case insensitive. It is possible to filter on nested fields by adding the parent object before the field with a '.' to separate them.\nDo remember to URL encode the filter parameters.\n\n### Examples\n\nAll employments with a cancellation periode in months (the value 4 corresponds to months time unit).\n\n```\n\n/v2/providers/employers/{{employerId}}/employees/employments?filter=cancellationPeriodTimeUnit.key eq 4\n\n```\n\nAll employments with no endDate.s\n\n```\n\n/v2/providers/employers/{{employerId}}/employees/employments?filter=enddate eq null\n\n```\n\n\nAll employments with an end date less or equal to 2017-01-01\n\n```\n\n/v2/providers/employers/{{employerId}}/employees/employments?filter=enddate le '2017-01-01'\n\n```\n\nAll employees with a employee number greater or equal 1 and less or equal 5\n\n```\n\n/v2/providers/employers/{{employerId}}/employees?filter=employeeNumber ge 1 and employeeNumber le 5\n\n```\n\n## Ordering\n\nAll Loket.nl API resources support ordering of the elements in the response on a specific field. \nAll fields can be used in ordering. \nThe list can be ordered in ascending or descending order, with ascending being the default one. Ordering on multiple fields is also by using a ',' as a separator.\n\n### Examples\n\nOrder employers by company name ascending\n\n```\n\n/v2/providers/employers?orderBy=companyName\n\n```\n\nOrder employers by company name descending\n\n```\n\n/v2/providers/employers?orderBy=-companyName\n\n```\n\nOrder employers by company name descending then by house number ascending\n\n```\n\n/v2/providers/employers?orderBy=-companyName,address.houseNumber\n\n```\n\n## Headers\n\nIn order to access the endpoints of the Loket.nl API, at least two request headers need to be set. \n\n\n__1)__ the `Authorization` header is required in order to authorize the API call. \nThe value of this header is the word Bearer followed by a space and the access token acquired from the `/token` endpoint. \nFor example, if the acquired access token is `AbCdEf123456`, the value of the `Authorization` headers would be:\n\n```\nAuthorization: Bearer v69uloc3wcEFLePw2unot0FfAJfBocrvSwsrCo75JLUG7aE54zqSUnU\n```\n\n__2)__ The second header that is required for proper usage of the API, is the `Accept` header.\nThis header is used for the resource versioning feature and is therefore crucial for making sure the response remains the same when new resource versions are introduced.\nThe value of the `Accept` header differs per endpoint is defined in the OpenAPI documentation of the endpoints.\n\n```\nAccept: application/json;version=2018-01-01\n```\n\n# Response\n\nIn addition to the responses defined in the OpenAPI documentation, the Loket.nl API also provides additional fields that give more information about\nthe response and the entities requested. This section will explain the full response given by the Loket.nl API by examining the example response below.\n\n\nExample 400 response\n\n\n```json\n\n{\n \"version\": {\n \"obsoleteDate\": null,\n \"versionNumber\": \"2018-01-01,\n },\n \"messages\": [\n {\n \"code\": 83,\n \"id\": null,\n \"type\": \"BrokenBusinessRule\",\n \"description\": \"[field] has an invalid length\",\n \"properties\": []\n }\n ],\n \"_embedded\": []\n}\n\n```\n\n\nExample 200 response\n\n```json\n\n {\n \"totalSize\": 1,\n \"pageSize\": 250,\n \"totalPages\": 1,\n \"currentPage\": 1,\n \"version\": {\n \"obsoleteDate\": null,\n \"resourceVersion\": \"2018-01-01\"\n },\n \"messages\": [],\n \"content\": {\n \"id\": \"2b4c119c-527c-4cbb-a5b2-f3a11e4b76cx\",\n ...\n }\n }\n\n```\n\n## Paging\n* `totalSize` has an integer value indicating the total number of entities irrespective of the page size.\n\n* `pageSize` has an integer value indicating the maximum number of entities returned per page. The page size can be influenced by setting the `pageSize` query parameter. See the section Query Parameters for more information.\n\n* `totalPages` has an integer value indicating the number of pages the requested collection holds given the specific pagesize.\n\n* `currentPage` has an integer value indicating the current page number. The current page number can be influenced by setting the `pageNumber` query parameter. See the section Query Parameters for more information.\n\n## Version\nThe `version` object provides information regarding the resource version of the entity requested.\n\n * `obsoleteDate` contains the date of discontinuation for the requested resource version. The value of this field can be `null` indicating that the requested resource version is not planned to be obsoleted at the time of the request.\n\n * `resourceVersion` shows the version of the requested entity. The resource version can be influenced by setting the `Accept` header.\n\n## Messages\nThe `messages` field contains a list of message objects related to the request made. Any warnings and errors will be communicated in this list of messages\n\n * `type` has a string value indicating the type of message. At this time the Loket.nl API supports five types of messages: `BrokenBusinessRule`, `Warning`, `Exception` and `NotFound` .\n \n * `description` has a string value that describes the message that has occurred.\n\n * `code` is an identifying code for the message. Please note that this code may change in the future. See the documentation portal for possible message codes for an endpoint.\n\n * `id` relates the message to a specific entity in the reponse list. For example, in cases where a warning occurs for one of the entities in a list, the value of this field can be used to identify to which entity the warning applies. Currently implemented for endpoints where a multi-patch is performed (multiple actions are performed within one call) for example updating the status of one or more leaveRequests. \n \n * `properties` an array that can contain additional information regarding the message. Currently not yet fully implemented.\n\n* `_embedded` contains the list of entities as defined for each endpoint in the OpenAPI documentation. Please refer to that documentation for the contents of the `_embedded` field for each endpoint. For endpoints that return only one entity (detail endpoints) the `_embedded` field is replaced with a `content` field. The content of this field can also be found in the documentation for each endpoint.\n\n## Headers\n* `Expires` header is returned with every response to indicate how long a response can be cached\n* `Content-Disposition` header is used in case of downloads to provide a file name\n\n## HTTP status codes\n\nThe Loket.nl API supports the following http status codes.\n\n| Code | Is returned when |\n|------------------|---------------|\n| 200 | The request to GET, PUT, PATCH or DELETE and object was recived and processed succesfully. The response might still contain messages of the type warning. |\n| 201 | The request to insert (POST) a new object was recived and processed succesfully. The response might still contain messages of the type warning.|\n| 400 | The request was received but could not be processed. The reason(s) will be given in the response. The content type of the response may be text/plain for API-level error messages, such as when trying to call the API without SSL otherwise the content will be application/json. |\n| 401 | The bearer token provided in the authorization header is invalid. Do not retry the request until a new (valid) bearer token is acquired. |\n| 403 | The user is not authorized to access the resource. The reason will be given in the response. Do not retry the request until the, configuration, issue is resolved. |\n| 404 | The resource requested was not found/does not exist. |\n| 50* | A unforseen error occurred. Please check the request if everything seems te be in order on your side contact the support team. Provide as much information as possible to resolve the issue. |\n\nNote: for a limited number of endpoint a so-called multi-patch may be performed (multiple actions within one call). In that case the status code will be 200 if at least on of the actions succeeds, if other any action(s) in that call fail(s) a message will be returned including the given id of that entity.\n\n## Caching\nThe API uses the `Expires` header to indicate how long the item can be reused from the local cache.\nIn most cases caching is not allowed for resources.\nExceptions excist, such as pictures like the employer logo and the employee photo, in these cases the cache duration is mentioned in the description of the resource.\n","title":"Loket.nl API","version":"V2","x-apisguru-categories":["enterprise"],"x-logo":{"url":"https://developer.loket-acc.nl/logo.png"},"x-origin":[{"format":"openapi","url":"https://developer.loket.nl/swagger.json","version":"3.0"}],"x-providerName":"loket.nl"},"tags":[{"description":"NL: Ziekmelding. Absences due to either sickness/illness or absence due to, for example, maternity or organ donation (in Dutch 'vangnet').\n\nPlease note: when adding or updating an Absence or AbsenceProgress there will be no additional 'Melding' created in Loket.nl . This legacy mechanism in the older Loket GUI will NOT be included in the newer version of Loket.nl \n","name":"Absence"},{"description":"NL: Ziekteverloop. Absences due to either sickness/illness or absence due to, for example, maternity or organ donation (in Dutch 'vangnet'). One Absence contains one or more AbsenceProgress, indicating the degree of occupational disability over time of the absence.\n\nPlease note: when adding or updating an Absence or AbsenceProgress there will be no additional 'Melding' created in Loket.nl . This legacy mechanism in the older Loket GUI will NOT be included in the newer version of Loket.nl \n","name":"Absence Progress"},{"description":"NL: Contact historie. History of all contacts with the employee","name":"Contact history"},{"description":"NL: Verlof. Leave entries both addition and subtraction","name":"Leave"},{"description":"NL: Verlof aanvraag. Leave request for a certain type of leave. The types of leave can be managed at the employer level","name":"Leave request"},{"description":"NL: Verlof balans. Leave balances for all leave types known for the employment. The types of leave can be managed ath the employer level","name":"Leave balance"},{"description":"NL: Verlof regeling. Leave policies is used to set rules/ regulations for allocating leave numbers. Based on a leave policy leave can be generated automatically","name":"Leave policy"},{"description":"NL: Verlof regeling op providerniveau. Leave policies is used to set rules/ regulations for allocating leave numbers. Based on a leave policy leave can be generated automatically","name":"Provider leave policy"},{"description":"These endpoints allow the user to link leave policies and employments to one and other. If an employment is linked to leave policy, than the employment will get leave (verlofopbouw) based on the regulations when these are applied. The may a many-to-many relationship.","name":"Leave policy and employment links"},{"description":"These endpoints allow the user edit leave for multiple employments.","name":"Collective leave"},{"description":"NL: Administratie. Retrieve information about all administrations, both payroll administrations and non-payroll administrations.","name":"Administration"},{"description":"NL: Salarisverwerkende administratie. Manage a payroll administration. A Payroll administration is the link to the payrolling configuration","name":"Payroll administration"},{"description":"NL: Overzicht met de status -en mogelijke acties voor een periode.","name":"Payroll administration process overview"},{"description":"NL: Overzichten administratie. Download available reports on payroll administration level","name":"Payroll administration reports"},{"description":"NL: Exportset/componentset. Pre-defined sets of payroll components. Useful when working with large list of components","name":"Payroll component set"},{"description":"Calendar endpoints. Please note that filtering or ordering using the query string parameters may give somewhat unexpected results in some cases where an employment has been part of more than one department during the given period.","name":"Calendar"},{"description":"NL: Endpoints waarmee inzicht in de status van collective acties kan worden verkregen.","name":"Collective action"},{"description":"NL: Persoon. Manage an employee","name":"Employee"},{"description":"NL: Contactpersoon. Contact person of an employee","name":"Contact"},{"description":"NL: WAO/WIA. In case of occupational disabilities these can be manged here","name":"Occupational disability"},{"description":"Allows an employee the submit a change of address","name":"Change address request"},{"description":"Allows an employee the submit a change of contactinformation","name":"Change contactinformation request"},{"description":"NL: Werkgever. Manage an employer","name":"Employer"},{"description":"NL: Autorisaties (toegestane activities). Acquire the autorizations the user has for the given provider or employer","name":"Authorizations"},{"description":"NL: Concept Werknemer. Manage concept employees. In integrations with different applications it is sometimes necessary to use concept employee to create new employments within loket.nl. This is due to the fact that most systems don’t have all the fields required to create a new employment in loket.nl. Because for employee the validations are disabled. Allowing for the creation of a concept employee with only a subset of the fields that are required when creating a employment. At a later point the concept employee can be \"promoted\" to employee/employment using the Loket.nl interface. Please note that when a concept employee is promoted to an actual employee, the GUID of the employee will be identical to the concept employee from which it was created.","name":"Concept employee"},{"description":"NL: Signalen. Manage the notifications for a employer. Notifications are most commonly send by the system to inform the user of a certain event.","name":"Notification"},{"description":"NL: Mededelingen. Manage the announcements for a employer. Announcements are most commonly send by the system to inform the user changes in the CAO.","name":"Announcement"},{"description":"NL: Werkgever HR dashboard. Go to the Qlik employer dashboard","name":"Employer dashboard"},{"description":"Acquire a token to call the Data New Business (DNB) API","name":"Data New Business"},{"description":"NL: Functies. Manage the functions for the employer","name":"Functions"},{"description":"NL: Afdelingen. Manage the departments for the employer","name":"Departments"},{"description":"Manage the workflow triggers for the employer. Workflow triggers are triggers that trigger a workflow. With this resource you can manage which trigger will trigger what workflow.","name":"Workflow trigger mapping"},{"description":"NL: Eigen feestdagen. Manage the custom holidays for the employer.","name":"Custom holiday"},{"description":"NL: Nationale feestdagen. Manage the national holidays for the employer.","name":"National holiday"},{"description":"NL: Factureerbare items. Manage billable items for the employer","name":"Billable item"},{"description":"NL: Preboarding trajecten. ","name":"Preboarding trajectory"},{"description":"NL: Dienstverband. Manage an employment","name":"Employment"},{"description":"NL: Organisatorische Eenheid/ WerknemerFunctie. Manage the organizational entity for an employment, this includes but is not limited to department and function. <br/> <br/>For Organizational Entity records, so called 'linked chain' business logic applies. This means that the records for that payroll component may NOT overlap each other, based on startDate and endDate of each record, AND because it is a linked chain is not allowed to have 'gaps' between separate records. This also means that if an existing record in the chain is not closed and a subsequent record is created than Loket will automatically set the endDate for the already existing record (and vice versa when deleting a record).\n","name":"Organizational entity"},{"description":"NL: Variabele gegevens. Payroll period data (e.g. hours worked or specific bonus) relates to a single payroll period.\n\nThere are also several other payroll related resources that work with start and end dates allowing these resources to span multiple payroll periods. We refer to those resources as payroll data, however THIS endpoint allows the user to determine only the value of specific payroll components for a specific payroll period (variabele gegevens, vs vaste gegevens). The payroll components that may be used as payroll period data (f.e. example component 1 relates to the normal hours worked in that period) are specific for the payroll administration to be used, even though there are some overall generic consistencies.","name":"Payroll period data"},{"description":"NL: Toeslagen. Payroll component data for part of, one or multiple payroll period(s). If the same `payrollComponent.Key` is also present in the `payroll period data` for a payroll period then, depending on the configuration in `payroll period data` the two values will either be 1) added up; or 2) payroll period data will overwrite the BenefitsAndDeduction for the given payroll period. Only certain payroll components are usable as a Benefit and Deduction, the corresponding categories are listed in payrollComponent.category in this resource. <br/> <br/>Per payroll component a so called 'broken chain' business logic applies. This means that the records for that payroll component may NOT overlap each other, based on startDate and endDate of each record. Also, if an existing record in the chain is not closed and a subsequent record is created than Loket will automatically set the endDate for the already existing record.\n","name":"Benefits and deductions"},{"description":"NL: Beloning. Manage the wage of an employment <br/> <br/>For Wage records, so called 'linked chain' business logic applies. This means that the records for that payroll component may NOT overlap each other, based on startDate and endDate of each record, AND because it is a linked chain is not allowed to have 'gaps' between separate records. This also means that if an existing record in the chain is not closed and a subsequent record is created than Loket will automatically set the endDate for the already existing record (and vice versa when deleting a record).\n","name":"Wage"},{"description":"NL: Werktijd/ Arbeidstijd. Manage the working hours of an employment <br/> <br/>For WorkingHours records, so called 'linked chain' business logic applies. This means that the records for that payroll component may NOT overlap each other, based on startDate and endDate of each record, AND because it is a linked chain is not allowed to have 'gaps' between separate records. This also means that if an existing record in the chain is not closed and a subsequent record is created than Loket will automatically set the endDate for the already existing record (and vice versa when deleting a record).\n","name":"Working hours"},{"description":"NL: Loonstroken/loonresultaten werknemer. Download the payslip(s) for an employment","name":"Payslip"},{"description":"NL: Jaaropgave. Download the year-end statement(s) for an employment","name":"Year-end statement"},{"description":"NL: Jaaropgave. Download the year-end statement(s) for the employments of a payroll administration","name":"Year-end statement at administration level"},{"description":"NL: Excasso (i.e. SEPA, IBAN). Manage the payment information. To what (SEPA country) IBAN is the wage/salary to be payed to. NOTEL by far the largest part of outgoing payments will be based on the information in these SEPA payment information records (i.e. this resource). Other resources may contain further payment specifics.","name":"Payment information"},{"description":"NL: Excasso afgesplitst van netto. This entity indicates, if applicable, the bank account(s) (i.e. IBAN's) where a given amount of the net salary for this employment will be paid to.\n \n\nNormally, the IBAN for the payment of net wage will be set by the PaymentInformation(SEPA) record. However, this entity allows to take a part of the net salary (a fixed amount) and set this to a different IBAN (for that part of the payment). For example, when a person wants to have part of his earnings to his regular banking account and part of his earnings to his savings account.\n","name":"Payment information separate payments"},{"description":"NL: Excasso Buitenland. Manage the payment information for non-SEPA payments. Mostly useful for performing foreign payments in case no SEPA/IBAN information is available.","name":"Payment information non-SEPA"},{"description":"NL: Fiscaal / Fiscale gegevens. Manage the fiscal property settings for an employment.","name":"Fiscal properties"},{"description":"NL: Werknemer auto fiscaal. Registration of company car for fiscal (tax-related) purposes","name":"Fiscal company car"},{"description":"NL: Werknemer auto. Registration of company car for HRM purposes","name":"Company car"},{"description":"NL: Diversen salarisverwerking. A collection of a divers set of payroll, wagetax and pension variables.","name":"Other payroll variables"},{"name":"RDW services"},{"description":"NL: Het opvragen van basis bedrijfsinformatie bij de kamer van koophandel.","name":"Chamber of commerce"},{"description":"NL: Fonds. The funds the employment partakes in","name":"Employment funds"},{"description":"NL: Abp Fonds. The abp funds the employment partakes in","name":"Abp funds"},{"description":"NL: FondsGrondslag. The base used in the calculation of the employment fund contribution","name":"Base for employment fund calculation"},{"description":"NL: Grondslag. The base used in certain calculation. Like the base amount to c