Every major change on a document is recorded as an event (hendelse). For monitoring a portfolio of document, events should be used in stead of polling for status on each document. Event monitoring is available in beta and production using the webservice HendelseWs (currently in version 6).

Environment	URL endpoint	WSDL

Environment	URL endpoint	WSDL
Beta	https://beta.etinglysing.no/ws/v6/hendelse	https://beta.etinglysing.no/ws/v6/hendelse?wsdl
Production	https://www.etinglysing.no/ws/v6/hendelse	https://www.etinglysing.no/ws/v6/hendelse?wsdl

How to list events

Both listHendelser and listHendelserMedStatus returns a list of events from a given starting point. listHendelserMedStatus will also return the current status of the document (same as calling the getStatus method, see documentation). Both services offers the following parameters to get the intended events:

Request/input parameters

Parameter	Purpose	Description

Parameter	Purpose	Description
fraHendelsesId	Set the starting point required	Will return events with eventId greater than or equal to this value.
maxAntall	Limit the number of events required	Maximum number of events to return.
statuser	Filter events	Only fetch events for this list of document statuses. See below for example statuses.
typer	Filter events	Only fetch events for these event types. See below for example event types
kilde	Filter events	Some customers use both the webservice and GUI in Etinglysing. `kilde` allows you to fetch events for documents created through the webservice (`INTEGRASJON`), the GUI (`NETTLESER`) or both (`ALLE`). If omitted, events from both sources will be returned.
fraTidspunkt	Set the starting point	Only retrieve events having created timestamp newer or equal to this. ISO timestamp format. Example value `2021-11-16T16:22:09.321+01:00`.

Response:

Field	Description

Field	Description
id	EventId
type	Event type (see below for examples)
dokumentId	DocumentId in Etinglysing
eksternEierId	Document owner departmentId May be null
nyStatus	New status
gammelStatus	Old status. May be null
beskrivelse	Status description in Norwegian
opprettet	Event created timestamp
eksterntOpprettetDokument	True if document is created by using the DocumentWS webservice.
dokumentRef	The document reference at the event time
oppdragsId	Assignment ID that the document may be assigned to May be null
dokumentType	The type of document.

Event types

All events are related to a document by dokumentId

type	Description

type	Description
STATUSOVERGANG	Document has changed status: gammelStatus - (nullable) is the old status nyStatus - the new status See https://ambita.atlassian.net/wiki/spaces/DOC/pages/3260219401 for a list of document statuses
DOKUMENT_OPPRETTET	Document has been created
DOKUMENT_FJERNET	Tinglysing failed. This is a legacy event type that can be ignored. You will get the same information with an event of type `STATUSOVERGANG` where `nyStatus` equals `TINGLYSING_FEILET`.
MELDING	Information messages regarding document generation and validation.
SENT_NOTIFICATION	Generated when a reminder email is sent to a customer that should electronically sign a document in Ambita’s signing service (www.esignering.no).

Initial request

When establishing a background job that polls for events on documents, you can do an initial request specifying a start timestamp, like:

<v6:listHendelser>
    <fraHendelsesId>0</fraHendelsesId>
    <maxAntall>50</maxAntall>
    <fraTidspunkt>2023-01-01T00:00:01</fraTidspunkt>
</v6:listHendelser>

Assuming events exists, a response can look like:

<ns2:listHendelserResponse xmlns:ns2="https://ws.etinglysing.no/hendelse/v6">
    <return>
      <id>966177</id>
      <type>STATUSOVERGANG</type>
      <dokumentId>15767382</dokumentId>
      <eksternEierId/>
      <nyStatus>TINGLYST</nyStatus>
      <gammelStatus>UNDER_TINGLYSING</gammelStatus>
      <beskrivelse>Endret status fra "Under tinglysing" til "Tinglyst"</beskrivelse>
      <opprettet>2023-03-01T14:02:24.715+01:00</opprettet>
      <eksterntOpprettetDokument>false</eksterntOpprettetDokument>
      <dokumentRef>jsk_ne_rolf</dokumentRef>
      <dokumentType>FOELGEBREV</dokumentType>
    </return>
    <return>
      <id>967156</id>
      <type>DOKUMENT_OPPRETTET</type>
      <dokumentId>15775644</dokumentId>
      <eksternEierId/>
      <nyStatus>OPPRETTET</nyStatus>
      <beskrivelse>Dokument opprettet</beskrivelse>
      <opprettet>2023-03-20T11:58:09.186+01:00</opprettet>
      <eksterntOpprettetDokument>false</eksterntOpprettetDokument>
      <dokumentRef>ref</dokumentRef>
      <dokumentType>PANTEDOKUMENT</dokumentType>
    </return>
    <return>
      <id>967157</id>
      <type>DOKUMENT_FJERNET</type>
      <dokumentId>15775644</dokumentId>
      <eksternEierId/>
      <nyStatus>FJERNET_FRA_TINGLYSING</nyStatus>
      <beskrivelse>Dokument fjernet</beskrivelse>
      <opprettet>2023-03-20T11:58:15.563+01:00</opprettet>
      <eksterntOpprettetDokument>false</eksterntOpprettetDokument>
      <dokumentRef>ref</dokumentRef>
      <dokumentType>PANTEDOKUMENT</dokumentType>
    </return>
</ns2:listHendelserResponse>

Note that the events are sorted in ascending order of the id (numeric value). When processing a list of retrieved events, keep track of the last (highest) event id as this should be the input to the next poll for events.

Polling for events

Most integrators are only interested in some status stanges regarding their documents. Given that you have done an initial request to obtain an event id, the following requests can look like

<v6:listHendelser>
    <fraHendelsesId>967157</fraHendelsesId>
    <maxAntall>50</maxAntall>
    <typer>STATUSOVERGANG</typer>
</v6:listHendelser>

The above request will retrieve a maximum of 50 events starting from (and including) the event with id given in the element fraHendelsesId. To not get the last event repeated as the first event in the next call, you can use fraHendelsesId=<lastID>+1.

Only fetch relevant status changes

If you only send documents directly to Tinglysing, you can chose to only get events for the final two document statuses TINGLYST and TINGLYSING_FEILET. The list of events can be filtered by adding one or more document statuses in the reqeust:

If you have implemented collaboration with brokers and are sending mortgage documents to brokers, you will need to fetch events MOTTATT_AV_MEGLER and SAMHANDLING_FEILET as well.

Getting current document status with events

We also offer the webservice method listHendelserMedStatus that in addition to the event will give you the current (latest) document status. You will still get one event for every status change and all of them will have the (same) current status of the document. Using this service method in addition to filtering on document statuses, you may not need to call getStatus on the document after it is tinglyst or tinglysing failed.

Both listHendelserMedStatus and listHendelser use the same input parameters/filters and mechanism for getting events from an ID or timestamp. For listHendelserMedStatus the response is of course expanded with the additional document status.

An example showing one document that is tinglyst and one that failed tinglysing:

Documentation

Monitoring events