Getting Started

Register for an Account


Once you register for an account, you'll receive an Activate Account email and be prompted to create a password. Then, as a signed-in account owner, you’ll be able to:

  • Create apps and invite collaborators to join
  • Access API Reference Documentation
  • Get Access Tokens for Sandbox Testing
  • Promote your applications

NOTE: If you’re planning (or even considering) to “Go Live,” contact us to discuss our access and integration requirements so we can help get the process started and keep you moving along at your pace.

Create an App


  • To Create an App, Sign In then you’ll land on your Dashboard.
  • Click Create New Application and name it.
  • Select the API Product(s) you want to include in your app.
  • Your app will have its very own App Page where you can manage everything from a centralized location.

Experiment in Sandbox


  • Once you’ve created your app and added API Product(s), then you can access Sandbox Credentials.
  • On the app page, you can either use the Auto-Generated Access Token or Manually Generate one using the Client ID and Client Secret with the product’s scope.
  • Call the API(s) using the Access Token in the sandbox environment.

Promote to Test


  • When you’re ready to promote your app to the Test environment, click Promote to Test on the App Page.
  • Your request and app details will be sent to the Product Owner teams for review. Typically, approval is less than 48 hours.
  • As soon as one or more API Products are approved, you’ll be notified via email and Test Credentials will be available on the app page.
  • You have the flexibility to invite collaborators and manage Whitelist IPs at any point - until you Go Live.

Go Live


  • Once you’ve fully tested your app, just click Promote to Live.
  • Our team will review your app one more time.
  • Once approved, new Production credentials will be available in the Live tab of your app page.
  • Then, validate your integration and call the API.
API Reference

To access an API Reference, navigate to its API Product Page and select the API Reference Tab next to Overview.

Security Standards

Authentication and Authorization


Equifax uses OAuth 2.0, an industry-standard protocol that allows us to grant permission for access to our products and services without sharing of unique credentials with a third party. The protocol defines a process that allows limited access to resources hosted by web-based services accessed over HTTP. Tokens assigned to authenticated clients are required to access all protected resources.

OAuth 2.0 Grant Type


The type of access called “OAuth 2.0 grant type” used for Equifax APIs is client credentials – here the username and password are not required. Rather, you obtain the Access Token by providing only the client_id, client_secret, and the scope.

Setting up OAuth 2.0 requires getting credentials, requesting an Access Token, and accessing protected resources:

Client ID and Client Secret


When you Create a New App, Equifax will assign a Client ID and Client Secret per environment for the API Product you would like to access. You can manage each App’s credentials on its App Page. Our Authorization server authenticates your application by verifying the supplied Client ID and Client Secret, so please keep these credentials safe.

Access Token


You will need to make a POST call to the token endpoint of the Authorization Server to generate an Access Token. Credentials and other parameters will need to be passed depending on the Authorization Server supported by your subscribed APIs.

Use the table below for parameters required to generate an access token.

Parameter Name Parameter Type
client_id Request body, form-urlencoded.
client_secret Request body, form-urlencoded.
grant_type Request body, form-urlencoded.

Currently we only support client_credentials grant type.
scope Request body, form-urlencoded.

 

 

 

 

 

 

 

 

 

These tokens are mapped to your credentials and determine your authorization to call your subscribed APIs. To call APIs in an environment, you must obtain a token from that environment.

Access protected resources:
All requests you make to Equifax APIs must contain a valid Access Token. Requests with invalid tokens will be denied access to the resource with the API, returning HTTP 401 status code.

The table below provides parameters used to supply access tokens to the API.

PARAMETER NAME PARAMETER TYPE
Authorization Http header

 

 

 

 

Environments

We support multiple environments for all our APIs to help you:

  • Innovate without constraints.
  • Develop production ready applications.
  • Meet compliance needs.

Access requirements


You need to have an approved set of API credentials (Client ID and Client Secret) for an environment to access it. This can be done by subscribing to an environment specific product.

NOTE: The Base URLs listed for each of the environments below are API endpoints, not web endpoints.

Sandbox


  • Base URL: https://api.sandbox.equifax.com
  • Monetization: You don’t incur any cost for testing the API in Sandbox.
  • Usage constraints: Currently there are no constraints.

Test


  • Base URL: https://api.uat.equifax.com
  • Monetization: You don’t incur any cost for testing the API in our UAT / Test Environment.
  • Usage constraints: There are no usage constraints applied to our test APIs.

Live


  • Base URL: https://api.equifax.com
  • Additional security: Apart from valid API credentials, production APIs can only be accessed from whitelisted IP Addresses.
  • Monetization: This varies per API product. Please contact your Equifax sales representative.
  • Usage constraints: Please contact your Equifax sales representative.
Versioning

Equifax supports explicit versioning of API contracts. We use the major version numbering scheme, which involves easily detectable patterns such as V1 or V2 in path segments to distinguish URIs by their version. For example, POST https://api.equifax.com/namespace/v1/resource.

Backward incompatible changes to API contracts results in the release of a new version. While we track backward compatible changes, these changes do not change existing API contracts. Instead, they result in new interfaces or modify internal implementation of an API to provide new behavior without impacting old behavior.

As a consumer of our APIs, you should write your application expecting the following changes might occur without notification:

  • Addition of a new optional parameter to the URI.
  • Addition of new optional data elements to the request body.
  • APIs may return “redirection” http response code (301, 302) instead of the documented code for a method.
  • Addition of fields in the response bodies.
  • Rate limits applied to an API may change dynamically and may result in the API returning http status code 429.
  • APIs or their parameters/fields may be immediately deprecated for security reasons. Otherwise, we will give you reasonable notice of deprecations.