Overview
CI in 2 minutes
With CI 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 analyzed consumer data
- Get access to extensive European consumer data through an API directly in your business systems
- Ensure compliance of your customer data management to GDPR
CI provides you with access to unique 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 easierBy integrating CI, 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.
AuthenticationTo use CI, you need a client ID and a secret. OAuth2 is used for authentication. For Sandbox authentication see more under Sandbox details.
Key use cases
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.
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 a unique personal ID for each validated customer, which you use as a key to retrieve the information you need when you need it.
How to use the API
This guide is intended to help you get going with your integration against the CI 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 through your local customer service or here.
Unique identifier
A key concept in CI is the Generic Entity Data Identifier (GEDI) referred to as unique ID below. It is designed to be a unique, persistent identifier of entities.
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
Search
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” can be used as input. See endpoint reference for searchPersons.
Match
Synchronously identify existing customer databases and offline-registered customers to get the keys to connect to CI services and data streams. See endpoint reference for matchPersons.
Get
Get 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
Get changes from CI, 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, then add them to the monitoring list and then get changes.
The first change available in the list will be from the date a person is added to the list.
The very first call against changes, use since to get the first changes. After that use the cursor, next as parameter to get the next page of changes. Then again use the latest cursor returned in the latest response. Iterate until page return "hasMoreEntities": false. Save last cursor until next iteration of fetching changes.
Sandbox environment
Our Sandbox environment contains faked but realistic data for testing purposes. This data may be updated or removed over time, ask for the latest version of available sandbox data.
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
A list of the test objects can be fetched from the demo application; https://www.dnb.com/en-gb/ci-demo/ Here you also can test our Onbarding and Monitoring use cases
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)
Documentation
Local Differences
The 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 received upon request.
Please see official source data matrix, for all available data in each nordic country via the official source. CI mapping official data
Available input by source
|
Country |
Description |
Available input |
|
Denmark - Marketing data |
Marketing consumer data. |
firstName, familyName, streetAddress, postalCode, city, phoneNumber |
|
Denmark - Official data |
Danish official data from "Det Centrale Personregister", the user needs a permit from Danish authorities. |
legalId, firstName, familyName, streetAddress, postalCode, city, dateOfBirth |
|
Finland - Marketing data |
Marketing 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 - Marketing data |
Marketing 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 - Marketing data |
Marketing Consumer data. |
legalId, firstName, familyName, streetAddress, postalCode, city, dateOfBirth, phoneNumber |
|
Sweden - Official data |
Swedish official data from "Statens person- och adressregister", the user needs a permit from Swedish authorities. |
legalId |
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.