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. »
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 »
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. »
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. »
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. »
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: »
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. »
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. »
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. »
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. »
