Bisnode Consumer Intelligence in 2 minutes

With Bisnode Consumer Intelligence you can:
  • Validate consumer information in real-time
  • Make sure all your customer data is always updated and correct
  • Create a single customer view across all systems and platforms with unique personal ID:s 
  • Identify your customers and keep their information updated in your business systems even when data is stored in different systems that previously could not exchange data
  • Get new insights by combining your own customer data with Bisnode analyzed consumer data
  • Get access to extensive European consumer data through an API directly in your business systems through Bisnode
  • Ensure compliance of your customer data management to GDPR
Consumer data available through an API

Bisnode Consumer Intelligence provides you with access to unique Bisnode Consumer data. Integration with our API will ensure updated European customer data in all your business systems. That creates an opportunity to improve your sales process and customer experience throughout the customer journey. By combining our analyzed data with your existing customer data you can increase your understanding of your customers and the relevance in your communication at each stage of customer journey.


Making GDPR compliancy easier

By integrating Bisnode Consumer Intelligence, you will have better control over your customer records which will help you comply with many of the obligations of GDPR. Our unique ID implemented in all business systems enables you to get a 360 view of your customer and also to link all data about a customer to ease GDPR compliancy.


Key Features

Consumer Onboarding

Consumer Onboarding integrated into your business systems makes it possible to find and validate consumer data in real time.
Through Consumer Onboarding we can automatically find and autofill customer data to simplify registering process for your customer, which provides a better customer experience in online purchase or in shops.


Consumer Monitoring

With Consumer Monitoring you can monitor your customer database on several parameters and directly get information on any change in data or status. For example, you can monitor individuals, entire customer databases or only customers with changes since last check.

With Consumer Monitoring you get Bisnode’s a unique personal ID for each validated customer, which you use as a key to retrieve the information you need when you need it.


Refer to Docs for more details


How to use the API

This guide is intended to help you get going with your integration against the Bisnode Consumer Intelligence API. It serves as a complement to the  Endpoint Reference  and aims to bring a high level understanding of the key concepts of the platform. 

For questions and support, please contact Bisnode at api-support@bisnode.com


Unique identifier

A key concept in Bisnode Consumer Intelligence is the Generic Entity Data Identifier (GEDI) referred to as unique ID below. It is designed to be a unique, persistent identifier of entities within Bisnode.

To use any of the consumer data management functionality provided by this API, a step referred to as Connect is required. In practice this means obtaining a GEDI - for the persons of interest. Using the GEDI you can then download the available information for that person and continually receive updates as they occur.

There are three methods available to find the right GEDI for a Person: "Search“ (searchPersons), “Verify” (matchPersons) and "Match“ (matchPersons)


Onboarding - Verify consumer data in real-time


Search for a consumer via an integrated Point of Sales system, app or webpage Data such as "phone number", "first name, family name and date of birth" or “social security number (SE)” can be used as input. See endpoint reference for searchPersons.


Synchronouosly identify existing customer databases and offline-registered customers to get the keys to connect to Bisnode’s services and data streams. See endpoint reference for matchPersons.


Download consumer data related to an identified person using the provided GEDI (unique persistent identifier). Default data or specific dataSlices can be provided. See endpoint reference for getPerson.


Monitoring - Download changes over time

Get changes from Bisnode, providing a since-date indicating when last update was queried or a cursor for last downloaded change.

This process ensures you always have correct data on connected customers.


To enable monitoring step one is to identify all customers, add them to the monitoring list and then download changes.
  1. 1. Add ”clientReferenceId” + legal id/name and address to portfolio - [PUT] /portfolio/{portfolioId}/record/{clientReferenceId}
  2. 2. Get by ”clientReferenceId” to get status and gedi if successfully matched - [GET] /portfolio/{portfolioId}/record/{clientReferenceId}
  3. 3. Download the current version of a person by ”get-by-gedi” - [GET] /person/gedi/{gedi}
  4. 4. Add gedi to monitoring list - [POST] /list/default
  5. 5. Download changes since a given date or latest cursor - [GET] /list/default/changes.


To remove a customer from monitoring
  1. 1. REMOVE gedi from monitoring list - [POST] /list/default
  2. 2. DELETE ”clientReferenceId” from protfolio and external source - [DELETE/portfolio/{portfolioId}/record/{clientReferenceId}


Local Differences

The Bisnode Consumer Intelligence API aims at providing unified consumer data regardless of market. However, due to contractual and legislative reasons, a few market specific limitations need to be considered.



Data source (Teledata) lacks information about:

  • Date of Birth
  • Year of Birth

Search services is not available on Austrian data


Phone number and year of birth are not a part of default response, but can be added through the parameter dataSlice, reach out to your contact person at Bisnode for more information.


Search services is not available on Belgian data.

The match service will not return any Belgian person information in the response but match-codes for validation of the input per field will be.


 Available data output per country




  Available input

Denmark - Bisnode   Bisnode consumer data.   firstName, familyName, streetAddress, postalCode, city, phoneNumber
Denmark - Official data   Danish official data from "Det Centrale Personregister".   legalId*, firstName, familyName, streetAddress, postalCode, city, dateOfBirth
Finland - Bisnode   Bisnode Consumer data.   firstName, familyName, streetAddress, postalCode, city, dateOfBirth, phoneNumber
Finland - Official data   Finnish official data from "Digital and population data services agency", the user needs a permit from Finnish authorities.   legalId*, firstName, familyName, streetAddress, postalCode, city, dateOfBirth
Norway - Bisnode   Bisnode Consumer data.    firstName, familyName, streetAddress, postalCode, city, dateOfBirth, phoneNumber
Norway - Official data   Norwegian official data from "Det sentrale folkeregister", the user needs a permit from Norwegian authorities.   legalId*, firstName, familyName, streetAddress, postalCode, city, dateOfBirth
Sweden - Bisnode   Bisnode Consumer data.    legalId, firstName, familyName, streetAddress, postalCode, city, dateOfBirth
Sweden - Official data   Swedish official data from "Statens person- och adressregister", the user needs a permit from Swedish authorities.     legalId
Austria - Bisnode   Bisnode Consumer data.   firstName, familyName, streetAddress, postalCode, city
Switzerland - Bisnode   Bisnode Consumer data.   firstName, familyName, streetAddress, postalCode, city
Germany - Bisnode   Bisnode Consumer data.   firstName, familyName, streetAddress, postalCode, city, yearOfBirth
Belgium - Bisnode   Bisnode Consumer data.   firstName, familyName, streetAddress, postalCode, city, dateOfBirth


*legalId is restricted to certain industries such as Bank & insurance.


  Person   gedi (string) Y Y Y Y Y Y Y Y
  legalId (inline_model_3) Y N N Y N N N N
  protectedIdentity (boolean) Y N Y N N N N N
  firstNames (Array[string]) Y Y Y Y N Y Y Y
  preferredFirstName (string) Y N N N N N N N
  additionalName (string) Y Y Y Y Y Y Y Y
  familyName (string) Y Y Y Y N Y Y Y
  honorificPrefix (string) N N N N N Y Y Y
  gender (string) Y Y Y Y N Y N N
  dateOfBirth (string) Y Y N Y N Y Y N
  yearOfBirth (number) Y Y N Y N Y Y N
  deceased (boolean) Y Y Y Y N TBD TBD N
  dateOfDeath (string) Y Y N Y N TBD TBD N
  communicationLanguageScript (string) Y Y N Y N Y Y N
  directMarketingRestriction (boolean) Y Y Y N N N N N
  deregistered (boolean) Y Y Y Y N TBD TBD N
  charityMarketingRestriction (boolean) N Y N N N N N N
  Telephone   type (string) Y Y Y N N Y Y N
  number (string) Y Y Y Y N Y Y N
  telemarketingRestriction (boolean) Y Y Y N N TBD TBD N
  Address   type (string) Y Y N Y N Y Y Y
  subType (string) Y N N N N N N N
  careOf (string) Y Y Y Y N Y Y Y
  streetName (string) Y Y Y Y N Y Y Y
  streetNumber (string) Y Y Y Y N Y Y Y
  entrance (string) Y Y Y Y N Y Y Y
  apartment (string) Y Y Y Y N Y Y Y
  floor (string) Y Y Y Y N Y Y Y
  postOfficeBox (string) Y Y Y Y N Y Y Y
  postalCode (string) Y Y Y Y N Y Y Y
  city (string) Y Y Y Y N Y Y Y
  country (string) Y Y Y Y N Y Y Y
  formattedAddress (Array[string]) Y Y Y Y N N Y N
  Additional   lastModified Y Y Y Y Y Y Y Y
  sourceList N N N Y N N N N


Sandbox environment

Our Sandbox environment contains faked but realisitc data for testing purposes. We have 1000 persons whereof 100 persons are updated every night for testing Monitoring (https://api.bisnode.com/cia-public-api-test/v2/list/default/changes)

These are the type of changes to expect:

  • protected (true/false)
  • deceased (true/false)
  • change of address 
  • change of name
  • deregistered (true/false)

URL: https://api.bisnode.com/cia-public-api-test/v2/
Token URL: https://login.bisnode.com/as/token.oauth2?grant_type=client_credentials&scope=bci-test

For a list of the test objects contact api-support@bisnode.com


Changes and versioning

API version is provided in the base of the requested URL in the form of "v1", "v2" etc. Only major version numbers are used.

API versions are raised only on breaking (i.e. backwards incompatible) changes in the API. Fields may be added but will never be removed during an API version lifecycle. When developing your application, take care to ensure that your application is able to handle additional fields.




Authentication using OAuth2

Bisnode's latest APIs use OAuth2 for authentication. For all API requests, you need to supply an access token in order to authenticate yourself. To obtain such an access token you need to submit your CLIENT_ID and CLIENT_SECRET to Bisnode's authentication endpoint at https://login.bisnode.com/as/token.oauth2. The access token is then passed along in the Authorization header to all API requests. Follow the instructions below to learn how to do this.


Get and Use the Access Token

Step 1. Get the Access Token

To get an access token you need to make a POST request to https://login.bisnode.com/as/token.oauth2 using the following HTTP header: Content-Type: application/x-www-form-urlencoded and the following request body: grant_type=client_credentials&scope=bci The request must be authenticated using HTTP Basic authentication and your CLIENT_ID and CLIENT_SECRET.

Example in cURL
curl -X POST \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -d 'grant_type=client_credentials&scope=bci' \
Example response
  "access_token": "eyJhb....seAtPCCQ",
  "token_type": "Bearer",
  "expires_in": 7199
Step 2. Use the Access Token

Supply your access token with all requests to the API using the HTTP Authorization header: Authorization: Bearer <your access token here> You should reuse the access token for multiple calls to the API. See the next section on recommended usage.

Example in cURL - search for person
curl -X GET \
     -H "Authorization: Bearer eyJhb...seAtPCCQ" \
     https://api.bisnode.com/consumerintelligence/person/v2/?firstName=Sven&familyName=Svensson&streetAddress=Vasagatan 9&sourceCountry=SE

Reusing the Access Token

After you have fetched an access token you should save it and use it for subsequent calls to the API. There is no limit on the number of calls it can be used for, but it will expire after a certain time.

We recommend that you use the expires_in field to determine when to request a new access token. It specifies the number of seconds the token will be valid for. Because of possible delays in network communication as well as delays between checking the timestamp and transmitting the actual API request, it is a good idea to request a new token a few seconds before it is about to expire. This minimizes the risk of accidentally using an expired token.

The following pseudo code illustrates how to use the authentication endpoint together with the API.

function make_authorized_api_request():
    token = get_cached_access_token()
    if token == null or is_soon_to_be_expired(token):
        token = get_new_access_token()

function get_new_access_token():
    token = get_token_from_auth_endpoint()
    token.expiration_timestamp = now().add_seconds(token.expires_in)
    return token

function is_soon_to_be_expired(token):
    # Add time margin to avoid token expiring during call
    if now().add_seconds(60) >= token.expiration_timestamp:
        return true
    return false


API Console

Production Endpoints

Production URLs:

Get Access

Please find the complete reference of the API below. In future releases it will also be possible to try the API out directly from your browser.