Accurate Background APIv3 Completely New Version


Release of completely new version

In May of 2016 Accurate Background released a complete overhaul of their popular API for performing a variety of background checks.  I’ve been using the prior API for almost a year, and while it was powerful, it did seem a little rough around the edges in places. I’m pleased to report that the new API, called APIv3, is an enormous improvement on an already solid API product.   The new APIv3 uses a different design paradigm, follows standard RESTful conventions, and maybe best of all, has a completely new, free and automated account signup process.  You can sign up for a test account online and immediately receive access to a developer dashboard with the API credentials you need to start making calls. The documentation is complete, online, interactive and available to everyone on the web.


History of the prior  Background Check API

The prior version of the Accurate Background API was termed version 2, though the documentation (available only as a PDF) listed it as version 1.5.  That API was HTTPS based, but it didn’t have a completely consistent format for the URLs used, making it harder to develop for.  The different HTTP calls had differing requirements for providing parameters in the URL, as Form encoded parameters, and sometimes required JSON blocks to be passed in the call.   The error messages were not particularly useful, and so implementing the API – like most APIs – required a considerable amount of trial and error with attendant head-scratching.   The new APIv3 is so standards compliant and consistent that it can be tested in minutes with common off-the-shelf API tools like Postman.


What service does this API provide?

Essentially, the Accurate Background APIv3 is a tool to enable the trust economy, the sharing economy and the gig economy.  Apps like ridesharing or delivery or home services involve getting people together, to provide services to one another and to share their personal resources.  This requires a high level of trust on both sides of the transaction.  An app signing someone up to provide a service needs to know whether that person is qualified to provide the service, for instance, has a driver’s license or some other professional certification.  Background checks can also be used to look for other indicators of trustworthiness. For instance, your app could check to see if someone is on the global terror watch list, on the US sex offender registry or has one or more criminal convictions.


What can I check?

The Accurate Background APIv3 provides all those background searches and more. Here’s a quick table of the most useful (and interesting!) checks:

MVR Motor Vehicle Report- does the candidate have speeding tickets, revoked license, etc?
SON National Sex Offender Registry – self explanatory
TERB Global Terror Watch list – Looks at hundreds of sources globally such as OFAC, OIG, GSA, Most Wanted, Interpol, and the list goes on and on
FED-CR Federal Criminal District Court Search – Searches for criminal cases tried at the federal court level.  It is recommended you search each district where the applicant has lived as provided by the MOV search.
F/M County Court Criminal Search.  You will need one in each county where an applicant has lived, that data is provided by the associate MOV search.
MOV SSN Trace, discovers all the recent addresses for a Candidate


Fraud and Abuse Control Information system – a database for health care providers who have run afoul of government agencies like the GSA, OIG, etc.
OFAC Office of Foreign Asset Control – Searches the US Dept. of Treasury for sanctions violations and other violations of national security policy
FED-BK Search the Federal Bankruptcy databases
DL5 and DL7 Drug screens! The Candidate has to go pee in a cup at a medical facility near them.

In the AB APIv3 these checks are combined into simpler packages to make ordering easy.  There are also other searches, including employment and education verification available. Check the docs in the nav section “Customizing Orders/US Searches for a complete list.


What can I do with it?

Any app that matches people with personal services has a use for background checks.  One set of common App use cases are ride sharing and delivery like Uber, Lyft, DoorDash and HelloFresh, where drivers contract to deliver goods and services. These companies need a simple API to verify that the folks signing up on the app have a valid driver’s license and meet other risk-reduction criteria.   If your app matches unused personal property with folks who have a need, like AirBnB, car sharing apps, bike sharing apps, book sharing or any other form of property sharing, that app may need a way to establish a higher degree of trust between the owner and the renter of the property.  Dating Apps benefit from greater trust between participants.  Employment apps can verify criminal history, level of education and prior employment.  Babysitters and other folks providing in-home services might need an automated screening on a periodic basis.

As the sharing/trust economy grows and matures I’m confident that new and innovative uses for this information will continue to show up in new mobile and social apps.

New Feature Set

OK, now let’s move along to an exploration of the actual APIv3.

Very RESTful

The APIv3 is very RESTful, which means it hews closely to a specific standard for how HTTP APIs should work. See the Wikipedia article for a complete description, but I’ll do a basic recap here.

Resource Oriented

The APIv3 establishes a set of resources, which live at specific URLs.  URL stands for Universal Resource Locator.  The AB APIv3 has a very simple set of just three resources.  The corresponding URLs are here: A candidate to run checks on. Create once, and reuse as often as you want. An order to place one or more background searches, or check the results of the searches.


More detailed results of the background check. Not really needed in most cases, since the Order resource itself rolls up the results of the background checks.

When you make an HTTPS API call to one of those resources, you specify the HTTP ACTION to tell the API whether you want to create, update, or retrieve that resource.

When you want to create a resource you use the HTTP POST.

When you want to update the resource you use HTTP PUT.

When you want to read a resource, you use HTTP GET.



When a resource is created (with a POST) that resource is assigned a resource ID, which is returned to you in the response to the API call.  You can then use that ID to read or update the resource in the future.

For example, to create a candidate I would make a POST HTTPS call to

With some parameters describing the candidate (more on that below) and I would get back a candidate ID which would look like this:





When I want to retrieve that candidate, I would make an HTTP GET call to the candidate resource, and include the id in the URL like this:



Easy to test with Postman

A tool like Postman makes the process of learning and testing the AB APIv3 really easy.

Find Postman here:

For the remainder of this posting I’ll use Postman to demonstrate how to test the AB APIv3.

Let’s show how to get credentials and start testing.


Basic Auth and setting your credentials

All you need to place APIv3 calls are the HTTP basic authentication values.  When you sign up for a free account online at  you are immediately given access to the developer dashboard, which shows your credentials.


In Postman, click on the ‘Authorization’ tab, and set the Type of authorization to ‘Basic Auth’. You can then copy and paste the credentials.  Put the ‘Client ID’ into the ‘Username’ field, and use the ‘Client Secret’ for the Basic Auth password.


You are now ready to use Postman to test the API.

Reading the response

In all cases (the APIv3 is very consistent) the results of an API call are a JSON formatted HTTP result.  This makes the result very easy to read, understand and to parse.

Here is a complete example of a candidate resource response:

"resource": "CANDIDATE",
"id": "572d035feae5744796707a88",
"created": "2016-05-06T20:49:35Z",
"updated": "2016-05-06T21:30:00Z",
"revision": "12",
"firstName": "Bugs",
"lastName": "Bunny",
"middleName": null,
"dateOfBirth": "1940-06-06",
"ssn": "123556666",
"email": "",
"phone": "1234445566",
"address": "4000 Warner Boulevard",
"city": "Burbank",
"region": "CA",
"country": "US",
"postalCode": "98117",
"governmentId": {
"country": null,
"type": null,
"number": null
"aliases": [],
"educations": [],
"prevEmployed": null,
"employments": [],
"licenses": [],
"convicted": null,
"convictions": [],
"references": []

The resource responses always start with a description of what type of resource it is, the ID of that specific resource, and the creation and modification dates.

The revision parameter tells you how many times that candidate has been updated.

Sending Parameters

When you read a resource with a GET you don’t need to send any parameters in the body of the API call – the only important parameter is the resource ID, which goes in the URL.  But when you are creating or updating a resource you do need to provide parameters to populate the resource.  For instance, when creating a candidate you will need to provide the first name, last name, phone number, email address, and government id (SSN in the U.S.).  You can do this in all cases by passing in form-encoded parameters in the body of the HTTP call.  This is exactly the same as if an HTTP form POSTed to the API; the content type is application/x-www-form-urlencoded and the parameters are sent as key/value pairs.

Your API testing tool or development environment will put together the actual HTTP call for you, all you need to know is that there are key/value pairs for the parameters, and the correct content-type, which is ‘x-www-form-urlencoded’.

In compound parameter names, like firstName, the first letter is lower case.  The API is case sensitive.

POSTing in parameters as easy as typing the parameter names and values.  Here’s a screen shot:


For a candidate, the minimum parameters required to run a basic search are:

firstName Yes, the first name
lastName Last name. Middle names are optional.
email Useful for the ‘Interactive’ workflow, where the candidate fills in the rest of the information via a web form link sent to that email
address Current candidate living address
region This is ‘State’ in the US
country ‘US’ in the US, UK, etc.
dateOfBirth Helpful to disambiguate people with similar names – Don’t have this? Keep reading as there are other ways to gather this.
ssn Needed for many comprehensive background checks where you are strategically searching based on a person’s address history – Don’t have this? Keep reading as there are other ways to gather this.


Candidates are persistent

Candidate resources are persistent within the AB APIv3.  This means that you can reuse candidates easily, either to run additional checks on the same person over time, or perhaps to run the same checks on a periodic basis, for example to confirm that the candidate Motor Vehicle Registration is still clean.  You can also use the APIv3 to find your candidates.  If you issue a GET to the candidate resource without a candidate ID, you’ll see all your candidates returned.  If you issue a GET to the candidate resource with any combination of firstName, lastName, dateOfBirth or ssn and you’ll receive only those candidates back which match your criteria.


Two ways to collect or pass candidate data

In many cases you may not have all the candidate information (date of birth, ssn, etc) required to run the searches you want.  The AB APIv3 has you covered.  You can create a candidate with only a firstName, lastName and email, and then when you place an order (with POST to the order resource) you can specify the ‘Interactive’ workflow.  This will place the order, and send an email to the candidate with a link to fill in the required information.  When the candidate completes the data entry your order will pick back up and perform the background checks.  If you already have all the information required to place an order for the background check, and you have the candidate’s consent to do it, you can use the ‘Express’ workflow.


Store more data on the Candidate

Because the candidate resource is persistent, it’s a great place to store more information as you generate it.  (because there are no fees for creating or managing candidates, you could also use the AB APIv3 as a form of free and secure CRM tool!)  You can add aliases, conviction information, additional forms of identification and more to a candidate record.  Check the documentation for complete details.


Pass in a JSON body to create candidates

Creating a candidate is pretty simple in the most common cases, but you can imagine that if you wanted to create a really complex candidate with a lot of education entries, aliases, etc, you would end up with a complicated set of parameters.  In these cases is might be easier to POST in a completed JSON object to describe the candidate you want to enter.  The AB APIv3 supports this (for candidate and order creation, but not modification).  In Postman, you change the body from ‘x-www-form-urlencoded’ to ‘raw’, and change the content-type to ‘JSON application/json’.  Then paste in a JSON object that matches the format and layout of that returned by a GET to the candidate resource, but without the ID, creation, modification and revision.


Orders are Persistent

Order resources are persistent as well.  When you place an order it has a ‘status’ set to ‘PENDING’, meaning that it is processing.   When processing is complete, which could take anywhere from a few seconds to a few days, the status changes to ‘COMPLETE’.  In this version of the API you’ll need to check back on your orders by issuing a GET to the order resource to check the status.  I have it on good authority that subsequent versions of the APIv3 will have a callback functionality which will notify you when orders complete.


Order with pre-built packages or customize

The Accurate Background APIv3 has a wide range of background searches it can run, but it’s often easier (at least for testing) to use one of the prebuilt packages of background searches.  There are three packages available (plus an empty package for building your own searches), listed and explained in the table below.


PKG_BASIC Does a national criminal search in the U.S. Returns any past convictions if included in the database. This search completes very quickly, so it’s good for automated systems however it can have gaps in the information so it is recommended you conduct this alongside a county criminal search (F/M).
PKG_STANDARD Does a search on criminal convictions included in the national database, but also looks up the location where the candidate lives and runs a county criminal records search in that jurisdiction as well.  It also checks the global terror watch list.
PKG_PRO Like the PKG_STANDARD, but runs an SSN trace to find out everywhere the candidate has lived in the last seven years, and checks criminal records in those jurisdictions as well.
PKG_EMPTY You use this package to ‘roll your own’.  For instance, if you just need to check drivers, you could start with the PKG_EMPTY and add MVR, Global Terror, and National Criminal Database.

The process for adding your own custom searches to the empty package is a little tricky, because the packages go into an array called ‘’additionalProductTypes” on the order resource.

If you are using form-encoded params in Postman, then the parameter names look like this:


and so in Postman that might look like this:

Note that the array enumerator increments for each new product you add.  In this example, I get an error message back because I have not entered a driver’s license for my Bugs Bunny candidate, so the API cannot run a Motor Vehicle Report on him.  The error message nicely describes the problem and tells me exactly which parameter I need to add on my candidate.

Checking an Order

Depending on what sorts of checks you included in the order, it may complete immediately or it might take several days.  Many county criminal court systems don’t have automated systems which can be searched, and so those checks might require an actual visit from a human being, which obviously is going to take a few days to complete.  You’ll know when the order is complete by checking the ‘status’ field in the response to a GET on an order.

For instance, if I do a GET to this URL:

I see this snippet included (with much more information) in the response.

"completed": "2016-05-06T21:25:13Z",
"candidateInfoComplete": true,
"supportReferenceId": "Y3156519",
"status": "COMPLETE",
"result": "NEEDS REVIEW",
"reports": [
"base64encodedHTML": "/report/572d0bb7f1b9a4602bc83a0a"


The   “status”: “COMPLETE” indicates that the background check completed, and the “result”: “NEEDS REVIEW” indicates that some flags were found in the checks.  To be compliant with US regulations, the AB APIv3 can’t say that someone ‘failed’ a background check, it can only indicate that the search turned up some results that someone should check out further.

A search that comes back complete without finding any red flags looks like this:


"completed": "2016-05-06T21:13:50Z",
"candidateInfoComplete": true,
"supportReferenceId": "Y4043279",
"status": "COMPLETE",

The ‘supportReference’ field shows an order ticket number that can be used to look up the results if you need to contact Accurate Background for some reason.

So, let’s say that the order comes back ‘NEEDS REVIEW’.  How do you know which search in the background check had the red flags, and what findings those flags were based on?  With a little more digging in the order resource results you can find out.

The ‘products’ array in the result shows each of the constituent searches that was performed.  For example, in this order:

"products": [
"id": 46300177,
"productType": "NCRIM",
"status": "COMPLETE",
"result": "NOT APPLICABLE",
"flag": false
"id": 94473809,
"productType": "F/M",
"status": "COMPLETE",
"result": "NO RECORD FOUND",
"flag": false

There was a National Criminal search and a County Criminal search, and the result of each was either “NOT APPLICABLE” or “NO RECORD FOUND” to indicate that no criminal records were discovered.

In this much longer order result for a PKG_PRO:

"completed": "2016-05-06T21:25:13Z",
"candidateInfoComplete": true,
"supportReferenceId": "Y3156519",
"status": "COMPLETE",
"result": "NEEDS REVIEW",
"reports": [
"base64encodedHTML": "/report/572d0bb7f1b9a4602bc83a0a"
"additionalProductTypes": null,
"products": [
"id": 120414137,
"productType": "NCRIM",
"status": "COMPLETE",
"result": "NOT APPLICABLE",
"flag": false
"id": 59053106,
"productType": "MOV",
"status": "COMPLETE",
"result": "NOT APPLICABLE",
"flag": false
"id": 86249016,
"productType": "TERB",
"status": "COMPLETE",
"result": "RECORD FOUND",
"flag": true
"id": 49895801,
"productType": "F/M",
"status": "COMPLETE",
"result": "RECORD FOUND",
"flag": true

We can see that the order as a whole received a result of ‘NEEDS REVIEW”, and when we look at the individual search products we see a “RECORD FOUND” for the terror watch-list (TERB) and for a county criminal search.  Don’t loan that guy a car, or a plane.


Even more report details

What if you want to see even more detail? The API results are designed to be simplified to make it easier to evaluate the background check, but in some cases you may want to see the underlying background check report in more detail.  You can retrieve a human readable HTML formatted report with the report resource.   In the example above, note the “reports’ array:

"reports": [
"base64encodedHTML": "/report/572d0bb7f1b9a4602bc83a0a"

If you do a GET to that resource (the full URL would be ) you will receive a long text string, which you can base64 decode and store as an HTML file.

The response to that API call (with the report string truncated) looks like this:


"id": "573626147114b8175a783fb5",
"resource": "REPORT",
"created": "2016-05-13T19:21:14Z",
"supportReferenceId": "Y8069013",
"reportFormat": "HTML",
"report": "PCEtLSANCiAgQ3Jl…. Realllllly long string here…….++"

The decoded, saved HTML file looks like this:



The Accurate Background APIv3 is a huge improvement over the previous version in terms of consistency, ease of implementation, standards compliance and general simplicity.  Using standard HTTPS and basic auth for security and standard REST resource behaviors makes it easy to test and develop for. Being able to get a free test account online with no other intermediary is very developer friendly and forward thinking, particularly compared to Checkr, where you now need to talk to a salesperson who ‘reviews’ your application before you get account credentials.

There are currently no SDK type libraries published for different languages or dev environments, but I suppose that’s a task for the developer community.  The docs are complete and do have examples in curl and ruby, though examples in node.js, php, or java would be welcome.

Going from test to production is pretty easy, and uses an online document signing solution (DocVerify) to collect company information.  Billing is done via credit card through the developer portal, and is done on a pay-as-you-go basis, charging for the production background checks you order.  There are no charges for any API calls in the test environment.

I give this API a big thumbs up, and am looking forward to see additional features and functionality as Accurate Background rolls out enhancements to the APIv3!


The Hunt for the Best Background Check API

Intro and explanation
I’m an API designer, developer and evangelist, so I’ve had many opportunities over the last fifteen years to make great use of publicly accessible APIs that make my life easier, but until now I’ve never had a need to run background checks.  When a client asked for help building tools to manage hiring, I jumped at the chance to find the best background check API.

I had a hunch that with the rise of the sharing economy there would be new API-driven services available that did much of the heavy lifting in employment screening and contractor screening, and that I could try out for free.

So I did some Google research into the world of background checks and employment tools, which also led me to a greater appreciation of the distinctions and challenges that such APIs face, and a greater understanding of the regulatory issues that surround employment background checks in general (criminal records, motor vehicle records, drug testing and verifications).

I have compiled the results of my research into the API driven background check services in the hope that this article provides some assistance to other developers. I will continue to update this blog as updates in the industry are announced.

API comparison Chart- smaller
Why would I need background checks in my app?
The general purpose of most employment screening services is to assist hiring managers in selecting candidates for employment, managing the federal and other hiring required paperwork, and communicating with the candidates going through the employment process.  These same functions are just as relevant (and maybe more important) for API driven tools and processes.

Developers who build sharing economy tools often need to evaluate individuals who will work with their platform to deliver or share products and services.  Likewise, the users of these tools want to know they can trust the people they interact with through the service. They want to know that the services offered are provided by people who are safe.

Background check companies can help, by providing access to public records you can use to validate information already directly provided by a candidate or applicant, and by searching for red flags that might indicate a reason to review the candidate more closely.

Background check companies generally have access to government databases like the terrorist watch list, federal criminal records, and the local criminal records generally located in County courthouses.  Access to a candidate’s permanent criminal record can be an important factor in hiring in some situations, although this is sensitive information and must be handled carefully to safeguard the civil rights of the candidate.

Background check companies usually offer access to motor vehicle records, which are critical for ride sharing and other driving related services.

Background check companies can also help with verification of the qualifications a candidate provides to a prospective employer, through employment verification and education verification services.  These verification services can help you confirm where a candidate has worked in the past, what education they completed, and which professional licenses and certifications they have actually attained.

Many background check companies also provide an interface into drug testing services, which may be required for certain classes of employees and contractors, such as drivers.

Finally, once you have approved a candidate for hiring or federal contract employment, you’ll need to complete a federal I-9 form to verify that the individual is eligible for employment in the U.S.  Many background check companies can also assist with this part of the process.
Compliance and regulatory requirements
It’s worth noting that while most background check services provide information about a candidate’s past, it is up to you to make a determination regarding whether they are suitable for your purpose.  If you do uncover information that you think makes the candidate unsuitable, there are federal requirements (generally called the FCRA) for how you communicate that to the candidate, and most background check services can help you with that communication, too.   The Fair Credit Reporting Act is a powerful consumer protection enacted in 1970, which was originally intended to regulate the use of financial credit reporting. It has since been expanded to apply to background checks generally, and the use of background checks in employment verification specifically.  It is important to not only understand the federal requirements, but check that any states or countries you operate in don’t have their own guidelines on the use of background check information.
Permissible use and candidate approval
The FCRA requires prior approval by the candidate before checks are run, and also lays out the permissible uses of background checks, which for our purposes generally includes any employment or contractor decision.  You are also allowed to run background checks when there is a ‘legitimate business need’  in a business transaction initiated by the consumer, and when you need to review a consumer account to confirm that the consumer continues to meet the terms of service, for instance, that a driving record continues to meet your standards.

The FCRA requires the entity making decisions on the basis of the background check information to get prior approval to run the checks from the candidate, and also to share the results and the basis for any determination made using the results [See A Summary of Your Rights Under the Fair Credit Reporting Act].  You’ll want to use a background check company that handles this for you, to reduce the compliance risk and general hassle.
Background Check APIs are asynchronous
I was surprised in my research to find that background checks can take some time to complete.  As an API developer, I expect API calls to generally return a result immediately, and this is just not possible in the case of some background checks which may take as long as a week to complete.  You’ll need to factor in the asynchronous nature of background checking into the design of your application or service.  Most of the solutions I reviewed used a callback notification system to communicate when an API initiated background check returned a final result.
My application
In my case, I needed to build a tool to streamline the background check process for new and current employees and contractors at a client company. I wanted the process to be as efficient as possible, with as much processing automated as possible.  I wanted to be able to load candidates into a queue which would manage the background check process, with automated collection of the candidate consent and the candidate personal data required to run the checks.

I needed pre-hiring checks to qualify candidates by making sure that the information they reported on employment, education and certifications was accurate.

I needed to ability to initiate drug tests.

I also wanted the API system to provide a basic automated scoring for the candidate based on the information returned by the background checks. This decision would update the queue and move the candidate into the final hiring phase.  There in the final hiring phase I needed the API to provide the Federal I-9 help.

Throughout the process, I wanted the API to manage compliance with the FCRA and to take care of communication with the candidates.
What background check services are out there?
I began with some Google searching to locate a number of companies I could evaluate.  I quickly found and dismissed a number of scammy looking companies that promised free, anonymous checks without regulatory compliance, or required tricky looking credit card subscription fees before showing me any features.

I found the following list of more serious contenders:

Accurate Background

Based on the marketing materials available on the company web sites, I identified the competitive factors that the companies used to differentiate themselves, which are captured in the following chart. While all the companies offered criminal record searches, not all offered I-9 support, drug tests, international checks and help with FCRA compliance.

*It should be noted that SterlingBackcheck recently acquired TalentWise. It is yet to be seen what impact this will have on their background check
My specific criteria
I then devised a set of test criteria by which I would evaluate each of the firms, based on the information publicly available. I have described these tests in the following table:

Criteria Explanation
API driven So I can build into our internal HR and Client tools
Reputable, Established Because I am investing in a future with them
Understands Compliance I want the tool to address FCRA issues
Public API docs The API documentation should be easily accessible
Free Testing Account Developers need to test!
Clear, Obvious Pricing I don’t want to have to talk to a sales person
Flexible Reports I want to be able to choose what I want in the report
Candidate Input I want the candidate to do the data entry
Thorough Checks I want high quality checks of all known addresses

First cut: does the company post pricing
I made my first evaluation on the basis of clear pricing, because it seems like a proxy for the kind of transparency I was looking for in a development partner.  For each company I reviewed the publicly accessible information on the web, and any documents describing pricing that I could find linked on the web.

I could not find posted pricing for FirstAdvantage, HireRight, Talentwise, Sterling Backcheck or Jumio.

Company Has Posted Pricing?
Accurate Background Yes Yes
Checkr Yes
FirstAdvantage No
GoodHire Yes
HireRight No
Jumio No
OnFido Yes
Sterling BackCheck No
Talentwise No

Second cut: Does the company offer public API documentation and a free test account?
I next looked at each company to determine whether they had a public API with posted documentation and a clear way to request a test account.  From my research I understand that some of the companies without a public API do have a private API for large partner integrations, but I didn’t want to engage with a drawn out business development process simply in order to gain access to the API.  I just wanted to see the docs, and try out the API.  The following table is very similar to the table of results for posted pricing, with the exception that while did have posted pricing, that company did not have a public API.   None of FirstAdvantage, HireRight, Talentwise, Sterling BackCheck or Jumio posted either pricing or API documentation, which removed them from my further consideration.

Company Has Posted API Docs?
Accurate Background Yes No
Checkr Yes
FirstAdvantage No
GoodHire Yes
HireRight No
Jumio No
OnFido Yes
Sterling BackCheck No
Talentwise No

Evaluating the remaining companies
After limiting the competition to only companies that provided both transparent public pricing and an API with documentation I could read, I was left with just four companies; Checkr, Accurate Background, OnFido and Goodhire.  They each seemed like much more modern and developer friendly companies than those that did not make the cut.

Next I needed to establish a set of criteria, some of which would be subjective, to rank the developer experience, ease of testing API calls, and the quality of the results.
Final testing and criteria
For the final round of testing and evaluation I established a plan to get test credentials from each API provider, and do a basic test implementation using simple curl commands to test the calls and receive results. I then ranked the competitors on the following factors:

  • Ease of getting API test credentials
  • Quality of the documentation
  • Ease of sending test API calls with curl
  • Flexibility of report packages
  • Compliance help built in
  • Employee interactive mode built in

The Winner: img-thingAccurate Background  img-thing
Implementing all four background check APIs, even in a simple and trivial curl manner, taught me a great deal about background check APIs in general and was generally an invaluable way to gain experience.

Each of the tools had significant strengths.  OnFido offers a simpler ‘a la carte’ interface to order just individual components of a background check, while Checkr has only two pre-configured ‘packages’, forcing developers to choose between just ‘standard’ and ‘pro’.   The Accurate Background test account came with no less than 30 preconfigured packages from which to choose, demonstrating the greater depth of the AB offering.

Accurate Background had preconfigured packages for employment and education screening, as well as post-hire I-9 management, which no other competitor offered.

Checkr’s API was the simplest of the four tested, but that came at a cost in breadth of capability and compliance. Checkr’s API didn’t provide the ability for the candidate themselves to approve the background check or enter their personal information.

Accurate Background API allowed me to either collect and pass in all the candidate PII directly, or to use a workflow where the candidate receives an email and enters that information themselves, which was the route I planned to use in my application.  GoodHire had only one choice, the candidate interactive input.

Neither OnFido nor Checkr offered the FCRA required tools for communicating with the candidates when an employment decision is reached.  The FCRA requires that if a candidate is rejected that they receive a communication describing the check they failed and providing a mechanism to contest the decision and correct the background check data.  Only Accurate Background included this process (called ‘Scoring’) in the available API flows.

Accurate Background had good coverage in the US, UK, Canada and India, as well as products globally, and a great background check FAQ which explains compliance, pricing, product information and more.

The open API revolution has certainly come to the background check industry, with four solid contenders offering open API access to a wide range of background checks including criminal, motor vehicle, and education and employment verification.  While these API services are not cheap ($20 and up based on what checks are run) they are powerful, and provide access to great information you can use to make better hiring decisions.   The Accurate Background Pricing is located here. I think we’ll see much more of this technology integrated into applications, sharing services, social networks, dating sites and any other service where individuals need to trust each other.

Kudos to Accurate Background for putting together this API and giving developers access to a powerful platform.

You can check out the Accurate Background API documentation yourself online here: API 2.0 Reference Guide.