Overview
The Bisnode RiskGuardian Credit Information Person API contains individuals’ risk and credit information. The available data varies between countries due to local legislation and data sources. This data can help you do more reliable business when financial assessments of private individuals are necessary.
At the moment, Danish and Swedish data is available but shortly we will add Finnish and Norwegian data.
Authentication
To use the Credit Information B2C REST API - v1, you need a client ID and a secret. Bisnode uses OAuth2 for authentication. More information here.
Get started
You'll need 3 things to get started.
- Bisnode ID (contact api-support@bisnode.com for one if you don't have it yet)
- Sandbox API Key (you need to be logged in with your Bisnode ID to get it)
- Subscribe to the API (you need to be logged in with your Bisnode ID to subscribe)
Key Features
Person data available through an API
Provides you with high quality risk and credit data.
- High quality credit information for profitable decisions
- Avoid credit losses by doing business with the right customers
- Get stable customers that you know can pay on time
- Get new insights by combining your own customer data with Bisnode consumer data
Documentation
How to use the API
This guide is intended to help you get going with your integration against the Bisnode Credit Information B2C 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-bisnode@bisnode.com
Search Denmark
Consumer search lets you search for a person by entering the national identification number (CPR-number) or name and date of birth. The response contains name, address, date of birth and “personId”.
Credit information Denmark
If you already have done a consumer search, you have retrieved a “personId”. Please use the personId as input, and not the CPR-number.
If you like to do verification and credit check in the same request and know the person’s CPR-number (“nationalIdentificationNumber”), you can use that as an input.
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.
How to test
Test data available in sandbox:
Country | National Identification Number | First name | Last name | c/o name | Address | Postal code | Town | Payment remark | Payment remarks | Description | Status |
DK | 101851001 | Hans | Hansen | Boulevarden 12 | 6800 | Varde | yes | 3 | Active | ||
DK | 506941008 | Susan Holm | Svensson | Boulevarden 101 A 1 0002 | 6800 | Varde | yes | 1 | Active | ||
DK | 712614382 | Karin | Henriksen | Industrivænget 2 st th | 9000 | Aalborg | yes | 1 | Active | ||
DK | 707614285 | Jens | Mortensen | Boulevarden 101 1 mf | 6800 | Varde | no | 0 | Active (guardian) | ||
DK | 1312814362 | Janne | Mortensen | Industrivænget 2 st tv | 9000 | Aalborg | yes | 1 | Active | ||
DK | 705614857 | Tage | Olsen | Larsen | Boulevarden 14 | 6800 | Varde | yes | 1 | Active | |
DK | 709614290 | Grethe | Roland | Industrivænget 10 st tv | 9000 | Aalborg | no | 0 | Active | ||
DK | 709614096 | Bettina | Christiansen | Svinget 17 | 9000 | Aalborg | no | 0 | Active | ||
DK | 708614815 | n/a | n/a | Name- and address protected | |||||||
DK | 702614074 | Tove | Andreasen | n/a | n/a | The person is missing (70) | |||||
DK | 301811004 | Erik | Jensen | n/a | n/a | Person has left the country (80) | |||||
DK | 703614116 | Jytte | Henningsen | n/a | n/a | Person is deceased (90) | |||||
DK | 308811018 | Pia | Hansen | n/a | n/a | Without permanent address in Denmark (03) | |||||
DK | 707614293 | Lars | Henriksen | Svinget 50 | 9000 | Aalborg | yes | 1 | IdentityStop | ||
DK | 701614046 | Hanne Frederikke Sofie | Larsen | Boulevarden 14 | 6800 | Varde | no | 0 | IdentityStop | ||
DK | 1301814026 | Karina | Larsen | Boulevarden 14 | 6800 | Varde | yes | 2 | IdentityStop | ||
DK | 709614401 | Ove | Brammer | Pr Caroline Amlg 2 | 9000 | Aalborg | no | 0 | IdentityStop | ||
SE | 4502198429 | Testperson Ann Kim | Walker | Rörejvägen | 16993 | Solna | no | 0 | Zero Income, low credit worthines | Legal incapacity | |
SE | 3310109123 | Testperson Ture | Tvättare | c/o Borg | Rosenborgsgatan 4 | 16993 | Solna | yes | 1 | Sole proprietorship, previous inquieries, Dept balance, Historical address | Active |
SE | 9807152393 | Test Arbat | Haard | Rosenborgsgatan 4 | 16993 | Solna | n/a | n/a | The subject is blocked for report | Blocked for report | |
SE | 7502199255 | Testperson Lena | Magnusson | Rosenborgsgatan 4 | 16993 | Solna | yes | 7 | Has payment remarks, has current debt balance, no realestates | Active | |
SE | 7309069289 | Personuppgift Skyddad | Åter Avsändare | Protected identity, good Credit Worthines, is married | Name- and address protected | ||||||
SE | 4401127495 | Testperson Lars Anders | Johansen | c/o Ståhl | Box 16993 Produtv Bengtsbo | 16993 | Solna | no | 0 | High credit worhtiness, c/o adress, box adress | Active |
SE | 6703143435 | Testperson Stig | Skoogh | Box 12345 | 16993 | Solna | yes | 3 | Personal bankruptcy | Active | |
SE | 8801102388 | Testperson Per | Olsson | Rosenborgsgatan 4 | 16993 | Solna | no | 0 | High score, low income, has taxed real estate | Active | |
SE | 9009012395 | Testperson Ulf | Testsson | Rosenborgsgatan 4 | 16993 | Solna | no | 0 | High score, medium income, has taxed real estate | Active | |
SE | 7502199255 | Testperson Lena | Magnusson | Rosenborgsgatan 4 | 16993 | Solna | no | 0 | High income, historical dept balance | Active | |
SE | 6607113146 | Testperson Matilda | Testsson | Poste Restante Gpo | 16993 | Solna | no | 0 | Good credit worhtiness, high score, poste restande adress | Active |
Authentication
Authentication using OAuth2
Bisnode's newest 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=credit_data_persons. 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=credit_data_persons' \ -u "$CLIENT_ID:$CLIENT_SECRET" \ https://login.bisnode.com/as/token.oauth2
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 company
curl -X POST \ -H "Authorization: Bearer eyJhb...seAtPCCQ" \
-H 'Content-Type: application/json' \
-d '{"nationalIdentificationNumber": "234324234"}' \ https://api.bisnode.com/credit-data-persons/v1/persons/dk
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() save_to_cache(token) make_api_call(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