Last modified: Jul 4, 2024

Solution

About Authorization

The typical scenario is that some event will be triggered, or data will be read, updated, or created by a digital or analog service. A service owner owns this service and has defined some business rules for who is allowed to use the service. This service needs to control who can access and modify data. Altinn Authorization provides the capability to verify and enforce this. User scenario Users and organizations get rights to access a service from defined rules and policies. »

Authorization

Find out more Read more about Altinn Authorization About Altinn Authorization About Altinn Authorization What do you get? Get started Create your first resource Create your first resource »

Altinn 3 Correspondence

About Altinn CorrespondenceWhat is Altinn 3 Correspondence? What do you get?Main features of Altinn Correspondence Getting Started with Altinn CorrespondenceTutorials for how to get started with Altinn 3 Correspondence, for service owners, senders and recipients How-to-guidesHow-to-guides for Altinn 3 Correspondence ConceptsExplanation of concepts related to Altinn 3 Correspondence Reference documentationReference documentation for Altinn 3 Correspondence News and plansNews and plans for development of Altinn 3 Correspondence. »

Events

API Public API The following API controllers are defined: AppController : publishes (store and forward) and retrieve app events EventsController : publishes (store and forward) and retrieve generic events SubscriptionController : creates, retrieves, validates and deletes event subscriptions Private API The API controllers listed below are exclusively for use within the Notification solution: StorageController : saves incoming events to persistent storage (database) InboundController : pushes events to events-inbound queue OutboundController : identify and authorize event subscribers and push event and subscriber details to events-outbound queue WebhookReceiverController : provides end point to support automated testing of subscriptions Database Events data is persisted in a PostgreSQL database. »

Getting started with Altinn Broker Transition Solution

ServiceOwners In order to use the Broker Transition solution in Altinn 2 to create, upload and retrieve file metadata, a service owner must complete the following steps. Have an existing Altinn 2 Broker Service. Have or create a corresponding Altinn 3 Broker Resource. See how to get started with Altinn Broker here. Request a transition setup from the Altinn 2 Service to the Altinn 3 Resource. Determine the date for when this should go live. »

Notifications

API Public API The following API controllers are defined: OrdersController: API for retrieving one or more orders with or without processing details and notification summaries EmailNotificationsOrdersController: API for placing new email notification order requests EmailNotificationsController: API for retrieving email notifications related to a single order SmsNotificationsOrdersController: API for placing new sms notification order requests SmsNotificationsController: API for retrieving sms notifications related to a single order Internal API The API controllers listed below are exclusively for use within in the Altinn organization: »

Technical Overview

About The Altinn 3 Broker Transition service bridge is an internal component in Altinn 2 that transfers Broker requests from Altinn 2 to Altinn 3 for a given request, based on the ServiceCode/ServiceEditionCode combination of the request. This is an implementation of the soft shift solution described here. Technical overview Altinn 2 allows end users in Altinn 2 to make BrokerService requests for specific Broker Services that will be transferred to Altinn 3 instead of being stored in Altinn 2. »

Usage

These pages describe the difference in usage between existing Altinn 2 Broker Service and Altinn 3 Broker Transition operations. Usage RestDifference in Rest operation usage between Altinn 2 and Altinn 3 transitioned services. Usage SOAPDifference in SOAP operation usage between Altinn 2 and Altinn 3 transitioned services. »

Usage Rest

Difference in usage between existing Altinn 2 Rest Operations and Altinn 2 Rest operations that have been transition to Altinn 3. For standard usage of Altinn 2 Rest operations, see [Altinn Docs (norwegian only)] (https://altinn.github.io/docs/api/rest/formidling/) For all Altinn 3 transitioned services, Receipts will be pseudo-receipts generated from the Altinn 3 file metadata. This means all receipts returned will be pseudo-receipts, and all receiptIds will be 0. If your use case requires receipt usage, please submit a feature request. »

Usage SOAP

Difference in usage between existing Altinn 2 SOAP Operations and Altinn 3 SOAP operations that have been transition to Altinn 3. SOAP operations for Altinn 2 Broker Service are spread over 3 endpoints. For most requests there will be no functional difference between Altinn 2 and Altinn 3 requests. Service Endpoint Description BrokerService Service WS Handles metadata requests. Service Basic Service EC BrokerService Streamed Streamed WS Handles file data requests. Streamed Basic Streamed EC Receipt Receipt WS Handles receipt requests. »