Events

Learn about how Dialogporten integrates with Altinn Events

Introduction

Events refer to technical application events generated by Dialogporten (or the service provider) and published through the Event component in Altinn. Events can be consumed by authorized parties and the service provider, according to the authorization rules defined by the service provider.

How Dialogporten utlizes events

Dialogporten will automatically publish events of predefined types for all changes in Dialogporten, including the creation and updates performed on the dialog and its transmissions and activities. The authorization policy associated with the main service resource governs who are allowed to consume these events on behalf of the organization/citizen “owning” the dialog.

Dialogporten will also produce events whenever a dialog (or a dialog change) is first seen, ie. when a single dialog’s details is retrieved from the API (seen events are not emitted as a result of requests to the search/list API).

All events refer to the dialog the event is related to, and some events will contain additional metadata which allows end-user systems and service provider systems to build business logic associated with a particular state change or activity performed on a dialog.

How service providers and end-user system providers can utilize events

Altinn Events supports (and strongly encourages) the use of “subscriptions” when consuming events, which uses a webhook/push-based approach of distributing event notifications.

One of the main advantages of utilizing events this way is to be able to react to new/changed information without the need for frequent and constant “polling”, which is making repeated requests to endpoint at a (typically very short) interval to check if changes has occured. On the other hand, using webhooks eliminates this wasteful approach by “reversing the API”; Dialogporten/events will instead notify any authorized subscribers as soon as a change occurs.

Sse cases include:

End-user systems monitoring if new dialogs of a particular type are created
End-user systems monitoring if updates to an existing dialog are made by the service provider
Service owner acting on the user having seen a dialog or opened a dialog in order to determine the need for sending reminders
A second service owner, granted access to consume events associated with a particular service process reaching an end state, uses these events as a trigger to initiate a related business process pro-actively without user interaction.

Read more