Person Register Monitoring

In order to receive webhook events for the event type Person Registry Sweden, you need a webhook monitoring list (bundle) created by Roaring. As soon as you have a bundle in place you may update it by its id, i.e. upload a list of personal numbers to monitor. Please read more about webhook monitoring lists in our guide

There is one sandbox endpoint for updating a bundle. Id and entities don't matter, you may choose freely, the endpoint is there only to provide means to verify the file upload and the format.

Common use-cases:

• Manage monitoring lists for person registry Sweden

Apply for Production Data

This API requires permission. You apply for this through your account. Access Developer, Webhooks, Event types.

The accepted media types are:

• text/csv
• application/json

Every time the Swedish population register (SPAR) reports a change for a person on one of your monitoring lists, you receive a webhook event of type Person Registry Sweden (personRegistrySe, version 1.0). Changes are delivered in batches as SPAR reports them, so several events usually arrive together.

How these events differ from other Roaring webhooks

• Full snapshot, no diff. The event contains the person's complete current record in object. Unlike most other event types, there are no newAttributes or previousAttributes. To find out what changed, compare with the previous event you stored for the same keyMap.personalNumber.
• changeType is always UPDATE, including when a person dies, emigrates or is otherwise deregistered. Deregistration is signalled inside object, see Deregistration below.
• Current data only. No validity periods (dateFrom / dateTo) and no history.
• The event has its own model, described below. It is not the response model of the Population Register 2.0 API, and field names differ. For example, the API's deRegistrationReasonCode is deRegistrationReason in the event.

Event structure

{
  "changeType": "UPDATE",
  "requestType": "payload",
  "countryCodes": ["se"],
  "keyMap": { "personalNumber": "194812161596" },
  "messageId": "6b1f3c2e-8d4a-4f7e-9c21-3a5e7d0b9f14",
  "type": "personRegistrySe",
  "version": "1.0",
  "timestamp": 1790726400,
  "object": { "...": "see Person below" }
}

Person (object)

Fields without a value are left out. Dates are yyyy-MM-dd unless noted.

Details

Address

Relation

Deregistration

A person is deregistered when object.details[].deRegistrationReason is present. changeType is still UPDATE.

"object": {
  "details": [ { "deRegistrationReason": "UV", "...": "..." } ]
}

• No deregistration date is delivered. SPAR doesn't include it in monitoring deliveries. Use nationalRegistryChangeDate as the date of the change, or deceasedDate for deaths.
• Deceased (AV): deceasedDate is set. If the person was found dead, encounteredDeadDate is also set and deceasedDate may be incomplete (e.g. 2026-08-00). Don't parse deceasedDate as a strict ISO date.
• Emigrated (UV): usually address.foreignAddress holds the address abroad, and nationalRegistrationAddress typically only keeps the last county and municipality codes.
• Changed personal number (GN, GS): personalNumberChangedTo holds the new number. Add it to your monitoring list to keep following the person.

Deregistration reason codes

These are the codes used by SPAR, the same as in the Population Register 2.0 API.

Secrecy-marked persons

When a person becomes secrecy marked (sekretessmarkering), the event only contains:

"object": { "personalNumber": "199105012380", "secrecyMarked": true, "secrecyChangeDate": "2026-09-29" }

Any previously stored information about the person should be removed in compliance with local laws.

Sample events

Complete example events are available under Event types: open Person Register Monitoring and choose Sample objects.

Status Values:

• APPROVED- Bundle has been processed by SPAR.
• INCORRECT - Validation of bundle has failed on our end. Please contact us if you come across this status.
• MISSING - Something has gone wrong on our end. Please contact us if you come across this status.
• PENDING - Bundle is being processed by SPAR.
• SENT_IN - Bundle sent in to SPAR.

Status values when updating monitoring list

1. On update expect status PENDING or SENT_IN if the file is great in size.
2. Run list monitoring list every other minute until other status than PENDING or SENT_IN.
3. If status is APPROVED the job is completed.
4. Else if status is INCORRECT or MISSING, take appropriate measures according to status values.