Learn everything about how API Consumer can use our Developper Portal.

Even without extensive technical skills, the Dev Portal is designed to be intuitive and accessible. 
Partners can easily access APIs and documentation.

As API Consumer, my permissions are:

  • can see Public API documentation in the Catalog,
  • can access Overview and Info page linked to the API documentation,
  • can request access to the full documentation of Private APIs

The requests are managed (approved, rejected, or revoked) by the Owners of the API card (and by Site administrators).

How can I use the Developper Portal?

Journey of API Consumer

BNPP CARDIF APIs are all protected using an authentication and authorisation framework called OAuth2. This security framework requires an Authorization token (or access_token) to be provided with the request.

Getting an API key should be very fast. You need to:

  • Register on our portal with a username and an email access
  • Create an app and upload a certificate to get an API key and secret (How to upload a certificate?)
  • From this app, subscribe to one API
  • Receive a confirmation mail that your app has been approved

Try APIs via the Portal UI Try APIs programatically

API CONSUMER ONBOARDING PROCESS

Consumers can be customers, prospects, or partners depending on the API.
Adding new consumers on an Internet facing API MUST follow the following guidelines.

Overall process is the following:

StepAPI Consumer actionsAPI Provider actions
Register to the portalRequest access to the API Provider(no action)
For Private APIs, request access to the API documentationSelf-serviceApproves the Doc Access request (for private APIs)
Creates a consumer appSelf-serviceApproves the API Access request
Test the API in Sandbox via Client ID/SecretSelf-service(no action)
Upload X.509 client certificateSelf-serviceApproves the X.509 client certificate
Creates a consumer app with the client CertificateSelf-serviceApproves the API Access request following the cases above
Test the API in Sandbox via mTLSRequest access to the API Providera) Checks that the consumer is entitled to access the sandbox API (recommended), including contract and clear terms & conditions on security guidelines (see below)
b) Checks the identity of the third party and its certificate
c) Request adding a new Root CA (if required) to API Platform team
d) Approves the API access request
Test the API in production via mTLSRequest access to the API Providera) Checks that the consumer is entitled to access the prod API (mandatory), iincluding contract and clear terms & conditions on security guidelines (see below)
b) Checks the identity of the third party via "contre appel"
c) Request adding a new Root CA (if required) to API Platform team
d) Approves the API access request

REGISTER TO THE PORTAL

Unlogged users have limited permissions.

  1. User registers
    1. User register by requesting a user account creation to the API Provider  
    2. User must use a business email (cannot use gmail, yahoo, or other public emails)
    3. User is automatically approved
  2. Logged users have more permissions

FOR PRIVATE APIS, REQUEST ACCESS TO THE API DOCUMENTATION

  1. Consumer request access to the documentation via the Info tab
  2. An email is automatically sent to the API Owners (the list of email is configurable)
  3. The API owner can approve / refuse the doc access request
  4. An email is automatically sent to the API consumer
  5. Consumer can access the doc (if approved)
  6. Daily email on all API Access Request for each API owner (in progress)

TEST THE API IN SANDBOX VIA CLIENT ID/SECRET

  1. Consumer create a consumer App and request access the Sandbox API via the Dev portal
  2. An email is automatically sent to the API owners (the list of email is configurable)
  3. the API Owner can approve/refuse the API access request
  4. An email is automatically sent to the API consumer
  5. Consumer can test the API (if approved)
  6. Daily email on all API Access Request for each API owner (in progress)

Get more details

 

TEST THE API IN SANDBOX VIA CERTIFICATE

In the OpenAPI Spec, each <Service> team MUST include a clear description of the URL for preproduction using mTLS and associated contacts to get access to it.

  1. Consumer creates an application with the approved certificate and provide all necessary information to access the required environment
  2. <Service> Support team checks that the consumer is entitled to access the environment:
    • provided the required business and technical information for his registration (recommended)
    • went through the required process (KYC, contract signature,...)
  3. <Service> Support team checks the identity of third-party requesting access to the API :
    • Checks that the root CA is an audited EV CA
    • Checks that the certificate has
      • " Key Usage" that includes "Digital Signature"
      • "Extended Key Usage" that includes Client Authentication
  4. <Service> Support team requests adding the CA (if not yet registered)
    • If the CA is not part of this list (<link to add>), the <Service Support> asks API Team to add the CA
    • The API team adds the CA to the platform (after double-checking that the CA is EV)
  5. <Service> Support team approves the application for that consumer (identified by his client id)
    • The customer is notified via email with the application name to use
  6. Consumer can test the API via mTLS
    • Open the application name provided in the developer portal
    • Gets the client id/secret to use when calling the api with the client certificate.
       

TEST THE API IN PRODUCTION VIA CERTIFICATE

In the OpenAPI Spec, each <Service> team include a clear description of the URL for production using mTLS and associated contacts to get access to it

  1. Consumer creates an application with the approved certificate and provide all necessary information to access the required environment
  2. <Service> Support team checks that the consumer is entitled to access the environment:
    • provided the required business and technical information for his registration (mandatory)
    • went through the required process (KYC, contract signature,...)
  3. <Service> Support team checks the identity of third-party requesting access to the API :
    • Checks that the root CA is an audited EV CA
    • Checks that the certificate has
      • " Key Usage" that includes "Digital Signature"
      • "Extended Key Usage" that includes Client Authentication
    • checks the identity of the third party by doing an outbound call from BNPP ("contre-appel"), using the telephone number in the contract, to confirm that he provided a certificate with this <subject> and this <issuer> (goal is to avoid third-party pretending to be a customer, prospect or partner).
  4. <Service> Support team requests adding the CA (if not yet registered)
    • If the CA is not part of this list (<link to add>), the <Service Support> asks API Team to add the CA by creating a ServiceNow Ticket
    • The API team adds the CA to the platform (after double-checking that the CA is EV)
  5. <Service> Support team approves the application for that consumer (identified by his client id)
    • The customer is notified via email with the application name to use
  6. Consumer can test the API via mTLS
    • Open the application name provided in the developer portal
    • Gets the client id/secret to use when calling the api with the client certificate.
       

SECURITY GUIDELINES TO PROVIDE TO THE CUSTOMER IN THE REGISTRATION PROCESS

BNPP Paribas requires each Client to implement the following security procedures:

  • Must use a Certificate aligned with customer functional and security needs to communicate with BNP Paribas APIs
  • Should use a Certificate dedicated to external authentication to partner APIs
  • Must use a Certificate directly issued by one of the audited EV CA in the following list: https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport
  • Must use a Certificate with
    • “Key Usage” that includes Digital Signature,
    • “Extended Key Usage” that includes Client Authentication
  • When the client certificate is revoked,
    • The customer must send a notification of revoked certificate to email <API Provider Support Team Email > which will be managed by BNP Paribas  within 5 working days
  • When a new CA is used (change of CA or expiration of CA), the customer must:
    • Inform BNP Paribas to email <API Provider Support Team Email > at minimum 5 working days before the actual change and provide new certificate
    • There’s a potential risk of interruption of services if the change is not notified on time.

LIST OF CERTIFICATION AUTHORITIES ACCEPTED BY BNP PARIBAS

  • 2014-2029 BNPP Applications
  • 2014-2044 BNPP Root
  • Entrust Root Certification Authority - G2
  • Entrust Root Certification Authority
  • Entrust Certification Authority - L1K
  • Entrust Certification Authority - L1M
  • DigiCert High Assurance EV Root CA
  • DigiCert SHA2 Extended Validation Server CA