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.



To use the Bisnode Consumer Intelligence, you need a client ID and a secret. Bisnode uses OAuth2 for authentication. More information here.

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.

Technical documentation
Please check our technical documentation for our API here.


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)


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.


Match 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.


Monitor Changes Over Time

This process ensures you always have correct data on connected customers

Run periodically, set up by the integrator to support the business needs. Get changes from Bisnode, providing a since-date indicating when last update was queried. If helpful, analyze the updates to identify what properties that has been updated. Update the customer data with the updates. Remember the since-date received in the response, to be used in the next iteration.


Add one or more customers to your subscription list to monitor for changes over time. See endpoint reference for editList.

Download changes

Download changes related to your monitored customers since last time. Default data or specific dataSlices can be provided. See endpoint reference for getChangedItems.


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.

Detailed information about request and response parameters per country can be found in the document BCI Request and Response Parameters. Other local difference that needs to be considered are listed below.


Data source lacks information about:

  • Date of Birth
  • Year of Birth
  • Gender

The search response are lacking streetNumber and postalCode, that information is retrieved through download request (get by GEDI/memento).

Data source lacks information about:

  • Date of Birth

Monitoring finnish data

Access to monitoring individuals requires a signed contract between the customer and the Finnish government PRC (Population Register Center).

Since this service is provided by Finnish authorities (only supplier of this service) it has some differences in behavior:

  1. Match existing customers to get GEDIs.
  2. “ADD” GEDI + firstName*, familyName*, streetAddress* & postalCode* to editList endpoint (sourceCountry=FI)
    1. The submitted information will be forwarded to PRC (population register central) for monitoring.
    2. It will be match and added to monitoring list
  3. The first delivery in getChanges will be the full PRC record, it make take some time for PRC to perform the match and initial delivery.
  4. Future deliveries will be changed properties only and not full person objects**.
  5. Changes can only be stored during a period of 30 days. It is therefore important that you subscribe to changes on a higher frequency than that.

*Mandatory for Finland

**Note that we will never deliver full BCI person objects from Finnish monitoring. The first delivery will return a PRC record (firstName, familyName, streetAddress, postalCode, city), future changes will return changed properties only.


Sweden is the only country in which Legal ID (Swedish personal identity number) can be used as a request parameter during Search and Match. Legal ID will always guarantee the highest hit rate.


Search services is not available on Austrian data


Search service is not available on German data.

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

Information about request- and response parameters can be found in the document "BCI Request and Response Parameters".

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
  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


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.

Test our API