Creates a new Verification and return a JSON object representing the newly created Verification.
Request-Sync HeaderVerifications are generally processed asynchronously: they will be created and returned in the response body without any reports. Truework will then send a webhook when the request has finished processing, and the reports can be retrieved. However, Instant verifications (those which are created without a target company) can also be executed synchronously by using the Request-Sync header. When processing synchronously, Truework will attempt to process the verification during the initial POST request. If successful, the 201 response will include a reports key, which will contain the requested data.
This header can take one of the following values. If the header is not defined, the request will default to asynchronous execution.
It is recommended to set a timeout on synchronous requests, to account for potential latency when calling our partners. Synchronous requests generally take only a few seconds to complete, but in rare cases they may take longer.
Synchronous execution is only valid for requests that do not include a target company. Other requests that pass this header will return a 400 response.
Request parameters allow you to configure how you use Truework by selecting only the verification methods and features you need. If the request_parameters field is left blank, the default
behavior is:
If target.company is included:
automated_underwriting_system_eligibility to not-requiredemployer_filter to target-employerIf target.company is omitted:
automated_underwriting_system_eligibility to not-requiredemployer_filter to all-employers or previous-employersA header that defines if a request should be executed synchronously. sync can only return completed or canceled verification responses, not pending. async will return only pending.
Comma-separated names of fields to include in the response. If omitted, all fields are included
A valid purpose is required for Truework to process the verification request.
Throughout the API, this is signified by the permissible_purpose field.
The verification request use case describes the type of product the verification request is originating from. If omitted, the verifier type in account settings will be used as a default
A single level key-value JSON object that can be used to store custom data on the verification request; keys and values must be strings
The originating party that requested the verification via a reseller. reseller_originating_party is required for for companies that resell data provided by Truework.
The details for the cancellation; only present when state is canceled
A single level key-value JSON object that can be used to store custom data on the verification request; keys and values must be strings
A valid purpose is required for Truework to process the verification request.
Throughout the API, this is signified by the permissible_purpose field.
The originating party that requested the verification via a reseller. reseller_originating_party is required for for companies that resell data provided by Truework.
The state helps convey where the verification request is in the Truework process. It will be returned in the JSON objects returned from this endpoint.
The initial state of all Schemas is pending-approval, and will switch to processing once Truework begins to process the request. However, it may switch back to pending-approval if it is pending approval by the target.
The states completed, canceled, invalid are all terminal states of a Verification. A Report is only available when it is in the completed state. A Verification will enter the state canceled when either Truework or an API user cancels the request. The invalid state indicates that there are issues with the data e.g. we could not locate the employee at a given employer, or could not find the employer itself.
We use data from thousands of verification requests to estimate the duration between creation and completion of a request. For a provided company, upper_bound and lower_bound are the time estimates (in hours) that this particular request will take to be fully processed by Truework. May be an empty if an estimate does not exist for the verification request.
The verification request use case describes the type of product the verification request is originating from. If omitted, the verifier type in account settings will be used as a default
Bearer tokens conform to the RFC6750 spec.
Production API keys (secret keys) are prefixed with tw_sk_ and sandbox keys are prefixed with tw_sk_test_. If your secret key is published, you should rotate your API keys.
Truework.JS publishable keys are prefixed with tw_pk_ and tw_pk_test respectively.
Examples
Authorization: Bearer tw_sk_test_e508eb797edb95ade85284bcb54dd49ed45db1betoken field, input only the token itself, omitting Bearer .For JSON requests, the signature of the request, see: https://www.truework.com/docs/verifications-signatures