Getting Started

TazAPI Advanced is a new collection of RESTful APIs built on the TazWorks platform. The TazWorks platform is a powerful software solution that offers many background check services. The API is purpose-built to enable integrations with Consumer Reporting Agencies (CRA), Applicant Tracking Systems (ATS), and other enterprise software systems. The API allows users to place background checks and manage customers/clients.

The following resources have been provided to learn and use the API:

  • Development Guide (this document) describes how to the API to leverage the TazWorks platform
  • TazAPI Advanced Reference Documentation describes specific details about each API endpoint, including the JSON request and response
  • Console provides an environment to test the API and manage live API applications

TazAPI version 1.0 (XML) continues to be maintained, and can be found here.

We strongly recommend all new integrations and applications use TazAPI Advanced due to its expanded capability.


Registration

The TazAPI Console is used to configure and manage the API. Registration is required to access the sandbox and live API environments. The console allows you to manage your own API configurations, authentication tokens, and more.

After signing up for sandbox access you will configure, develop, and test your API application. After the development and testing process, you will be able to promote your application to production (live) status where TazWorks API Support Specialists will review and assess your application for production readiness. Upon approval, your API application will be able to access live CRA data.

If you have not already done so, we highly recommend establishing a business relationship with a CRA on the TazWorks platform during your investigative / development process.


Authentication

TazAPI Advanced requires specific authentication and authorization. The API uses HTTPS (TLS 1.2). A valid token must be included in the Authorization header with each API request. Authorization uses the Bearer schema. IP address whitelisting is also required and enforced.

It is important to understand the relationship between API tokens, applications, and CRAs. Read the Concepts section for a detailed description.


Concepts

API Applications

In order to access and use the API, you must first create an API application in the API Console. An API application is a managed software integration between a 3rd party system and the TazWorks Platform. You may create one or more applications.

When creating an API application you can do the following:
  • Choose which APIs to use
  • Configure Webhook subscriptions
  • Configure IP address whitelist
  • Manage API authentication tokens
  • Register CRAs to use the application

CRA Data Access Control

The TazWorks Platform serves many CRAs and data vendors. Access to CRA or vendor data is strictly controlled and monitored. To protect the end customer, CRAs control which API applications can access data through a registration and approval process. For instance, through the API application, a CRA might restrict API calls to a single client's data, or a single product.


APIs

Order

The most common use of the API is for Orders. When given access to the Order API, you will be able to:

  • Create, update, and delete Applicants
  • Retrieve a list clients that you'd like to place orders for
  • Retrieve client products that you'd like to order
  • Place orders with applicant data and client products
  • Retrieve order statuses and results
  • Retrieve search statuses and results

Client

For those who need more control over the client structure and hierarchy via API, the Client API is for you.

  • Create clients
  • Update clients
  • Delete clients
  • Manage client hierarchies
  • Manage client preferences

CRA

Coming in a future release of the API.


How To

The most common use for the API will be to submit orders. In the API, orders and applicants can be edited separately. This allows you to enter partial applicant information without being required to submit an order at the same time. Once you have all the applicant information you need, you can submit the order. You can also submit additional orders for that same applicant, adding new information to the applicant if the new searches will require it.

Create an Applicant

Before submitting an order, you will create an applicant. You can add professional licenses, references, education and employment information about the applicant. You can specify addresses and any aliases they have used. The information you decide to provide should be determined by the type of searches you want to perform. For example, an employment verification search will need employment information. If you submit an order and the system is missing information, the API will tell you what information is needed. Add the missing information to the applicant and submit the order again. The information required for a search will also be affected by the CRA preferences for required fields. The API will prompt you for any required information.

Because an applicant is stored separately from an order, you can provide more information than will be required for a specific search. This may help if you intend to submit further searches in the future for that applicant.

Use the Applicant endpoints to create and populate information for an applicant.

Choose Client Product

Client Products are needed before submitting an order. The client product defines which searches will be included in an order and whether or not the order can use QuickApp. You can get a list of a client's existing client products or choose to make new client products.

  • Use the All Base Products endpoint to see the available CRA products that can be used in making a client product.
  • Use the Search Fields endpoint to see what information will be required for a particular client product.
  • See all Client Product endpoints.

Submit an Order

Once you have an applicant and a client product, you can submit an order. The type of information you include when submitting an order will depend on the type of searches which are included in the client product and the preferences for orderering that are associated with the client. For example, your client might require that you provide an authorization form or certify that you have permissible purpose to submit the order. An Occupational Health search may require additional collection site information. The Submit Order documentation gives you detailed information on these additional pieces of information and how to include them.

You can retrieve information about orders, add and retrieve attachments to orders, and send out QuickApp notifications to applicants. For tenant type orders you can choose to group co-applicants together and notify them once the order has been set-up.

Use the Orders endpoints to perform actions related to orders.


Usage Limits

Each API application instance must operate within the defined usage limits. An application instance is a CRA registered and approved API application that is in use. By default, each application instance has throttling limits and monthly usage limits, as follows:

  • 5 requests per second, with a burst throttle limit of 10 requests per second
  • 20,000 requests per day

If these limits are exceeded, an HTTP 429 response code will be returned with a JSON-formatted response.

A request may be submitted for an increase should these limits prove insufficient for high-load API application instances. Contact an API Support Specialist with your request.


API Maintenance

The API will occasionally be unavailable for maintenance. The maintenance hours will be 10pm-1am Mountain time. The maintenance window could be for the entire 3 hour window, but average downtime is about 30 minutes. If the API is unavailable, you will receive a 503 http response with an appropriate JSON-formatted response body.

It is your responsibility to build a retry mechanism with exponential back-off into your software design to account for maintenance windows.