Specifications for the new OAM webserivce prepared for ESAP

With the introduction of ESAP there will be several changes to the functioning and contracts of the OAM webservice. On this page and its descendants the new API is described.

Subjects for this page:

  • ESAP introduces several new metadata and changes some of the existing. The page ESAP metadata lists all metadata.
  • ESAP requires Finanstilsynet as a collecting body to validate submissions in the same manner as is done in ESAP.
  • More strict limitations on the file-formats and the content of the attached documents. 
  • More information types has been added to the OAM obligations.
  • Introduction of a more information type specific structure for the endpoints of the API.
  • Introduction of some endpoints for delivering information
  • The implicit acceptance of a new use- and reuse declaration when submitting.
  • The old OAM contains more than what is part of ESAP phase 1, so those information types are not as revised yet.

The revised OAM API is under development according to the OpenAPI standard. It is to a high degree Work in Progress and its present state is not ready for development, but it is an early example.

This is a link to the API in our test environment: Scalar API Reference

We have started out by implementing a few of the TD submissions for Issuers. We are still operating with the working title ("ESAP API"), but when we go live this API will be the new OAM API.

Due to file-type requirements when transferring submissions to ESAP the same requirements will be upheld in the API.

All uploaded documents have to be either data-extractable or machine-readable. Data-extractable means that it is possible to automatically extract meaningful text from the document that is readable by humans. Machine-readable means formats structured so that software applications can easily identify, recognise and extract specific data, including individual statements of fact, and the internal structure of that data (essentially ESEF format in ESAP phase 1). 

Submissions are subjected to two passes of validations - one immediately and one after initial processing and just before registration. All validations have to be passed for submissions to be registered correctly. Failure to pass the first series of validations is reported immediately in the return result from the API, failure in the second pass is reported as a notification and can be read through one of the service endpoints.

Most validations are done in the first pass and are of the following types:

  • Valid formats of data
  • Valid type of submission for this type of company
  • The submitter is allowed to submit for the designated company
  • Valid dates according to present date
  • Numbers are within the valid limits
  • Valid identifiers

The second pass is containing validations that either requires some analyzes of the document content (e.g. data extractability) or validations ud against previous submissions (e.g. positions have to be on different dates). A submission has a state that reflects where in the process the submission is presently. 

Document types codes (PR) / 6-letter code (TD+SSR)

Regulation / Information type

NSHTPS

SSR - Net short position

ADIOSH

TD - Acquisition or disposal of an issuer’s own shares

ARIMSL

TD - Additional regulated information required to be disclosed under the laws of a Member State

 

TD - Administrative measure and sanction

ANFIRE

TD - Annual financial report

CHRGHT

TD - Changes in the rights attaching to shares or securities other than shares

HYFIRE

TD - Half year financial report

HOMEST

TD - Home Member State

INSIDE

TD - Inside information

MJSHLD

TD - Major shareholdings notification

MANRSS

TD - Management report, including sustainability statement

MANTRA

TD - Managers’ transaction

ROPAYG

TD - Payments to governments

VOTING

TD - Total number of voting rights and capital

The content of all submissions has to adhere to a declaration of possible use and re-use of the information. To avoid superfluous attributes in the API contract this declaration is implicit and the responsibility of ensuring correct entitlement to the use and re-use of information is placed on the user of the API.   

Last updated 12-04-2026