You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This repository contains the API specification for [eInnsyn](https://einnsyn.no)'s API. The API is written in [TypeSpec](https://typespec.io), with an auto-generated OpenAPI version in the [openapi](openapi)-folder.
3
+
This repository contains the API specification for [eInnsyn](https://einnsyn.no)'s API. The API is written in [TypeSpec](https://typespec.io), and the generated OpenAPI document is available at [openapi/einnsyn.openapi.yml](openapi/einnsyn.openapi.yml).
4
4
5
-
The [typespec](typespec)-folder contains the following files:
5
+
The main files in the [typespec](typespec)-folder are:
6
6
7
+
-[einnsyn.tsp](typespec/einnsyn.tsp): Entry point for the API, including service metadata and authentication.
8
+
-[einnsyn.exceptions.tsp](typespec/einnsyn.exceptions.tsp): Shared exception and error response definitions.
7
9
-[einnsyn.arkiv.models.tsp](typespec/einnsyn.arkiv.models.tsp): Model definition for archive data, mostly Noark 5 with some extensions for meetings.
8
10
-[einnsyn.arkiv.operations.tsp](typespec/einnsyn.arkiv.operations.tsp): Endpoints for archive models.
9
11
-[einnsyn.queryparameters.tsp](typespec/einnsyn.queryparameters.tsp): Base models for query parameters.
@@ -13,99 +15,126 @@ The [typespec](typespec)-folder contains the following files:
13
15
14
16
## Authentication
15
17
16
-
The eInnsyn API uses API keys to authenticate requests. The keys are long-lived, and should be handled carefully. All API keys are prefixed with `secret_`.
18
+
The eInnsyn API uses API keys to authenticate requests. To send an authenticated request, include the API key in the `API-KEY` header:
17
19
18
-
To send an authenticated request, the API key should be sent in the `X-EIN-API-KEY` header:
Most routable resources expose standard CRUDendpoints:
27
27
28
28
-`GET /{entityName}`: Get a paginated list of objects
29
29
-`GET /{entityName}/{id}`: Get an object
30
30
-`PATCH /{entityName}/{id}`: Update an object
31
31
-`DELETE /{entityName}/{id}`: Delete an object
32
32
33
-
Objects that do not require a parent object (primarily arkiv) can be added directly at the root level using `POST /{entityName}`. However, objects that require a parent must be added through the parent object, for example: `POST /arkiv/ar_.../arkivdel`.
33
+
Resources that do not require a parent object can usually be added directly at the root level using `POST /{entityName}`. Resources that require a parent are added through the parent resource, for example `POST /arkiv/{id}/arkivdel`.
34
+
35
+
The API also includes task-specific endpoints such as `/search`, `/statistics`, and `/me`.
36
+
37
+
## Pagination
38
+
39
+
List endpoints use cursor-based pagination. You can control page size with `limit` (between 1 and 100, default 25), use `startingAfter` to fetch the next page, and `endingBefore` to paginate backwards. List responses contain an `items` array and may include `next` and `previous` URLs:
If you pass `ids` or `externalIds`, the other list parameters are ignored.
34
60
35
61
## IDs
36
62
37
-
All objects in eInnsyn will get an auto-generated `eInnsynId`. An eInnsynId is a Base32encoded UUID, with a prefix to indicate the type of resource. In the API specification, all entities has an extension annotation describing it's ID prefix.
63
+
All objects in eInnsyn get an auto-generated `eInnsynId`. An `eInnsynId` is a Base32-encoded UUID with a prefix that indicates the type of resource. In the API specification, each entity has an extension annotation describing its ID prefix.
38
64
39
65
Example annotation for the Journalpost entity: `@extension("x-idPrefix", "jp")`.
40
66
41
67
Example journalpost ID: `jp_01jh532p3ve6haq7n53xgpqayh`
42
68
43
69
In addition, all Noark5 objects must have a globally unique systemId assigned by the publisher. This identifier can be used interchangeably with the eInnsynId in the API.
44
70
71
+
## Read-only and write-only fields
72
+
73
+
Some fields are only available during certain lifecycle stages. In the TypeSpec source, this is expressed with `@visibility(...)`.
74
+
75
+
- Read-only fields are returned by `GET` requests, but are not meant to be sent when creating or updating resources.
76
+
- Write-only fields can be sent when creating or updating resources, but are omitted from `GET` responses.
77
+
78
+
For example, `Saksmappe.saksnummer` and `Saksmappe.administrativEnhetObjekt` are read-only, while `Saksmappe.journalpost` is write-only. Because of that, `journalpost` is not returned by `GET /saksmappe/{id}` and cannot be expanded there. To read the journalposts for a case, use `GET /saksmappe/{id}/journalpost` instead.
79
+
45
80
## Expanding responses
46
81
47
-
We use a concept called "expandable fields", inspired by Stripe's API ([Expanding Responses](https://docs.stripe.com/api/expanding_objects)). Throughout the API, all references to entity objects are either an ID, or the actual object. By default, all nested objects in a `GET` response are sent as an ID. For `POST` and `PATCH` requests, all new objects are returned. If you need to access nested objects, you can use the `expand` query parameter:
82
+
We use a concept called "expandable fields", inspired by Stripe's API ([Expanding Responses](https://docs.stripe.com/api/expanding_objects)). Throughout the API, references to entity objects are either an ID or the expanded object. On endpoints that support `expand`, nested objects in a `GET` response are sent as IDs by default. If you need nested objects, you can use the `expand` query parameter:
0 commit comments