api-docs.verifytx.com Open in urlscan Pro
2606:4700:20::681a:177  Public Scan

URL: https://api-docs.verifytx.com/
Submission: On May 29 via automatic, source certstream-suspicious — Scanned from DE

Form analysis 0 forms found in the DOM

Text Content

Getting Started


VERIFYTREATMENT API


VERIFYTREATMENT WEB API IS AN INTERFACE FOR QUERYING INSURANCE INFORMATION FROM
DIFFERENT INSURANCE PROVIDERS.


AUTHORIZATION

Getting started Request Access Obtain an Authorization Grant Authorization Code
Flow
 * Step 1: Redirect to VerifyTreatment
 * Step 2: VerifyTreatment redirects back to your site
 * Step 3: Exchange the grant for a token

Client Credentials Flow Access Protected Resources Refresh Access Token


VOBS

Create VOB List VOB View VOB Update VOB Delete VOB Re-Verify VOB History
Subscriber Relations


PAYERS

List payers


FACILITIES

List facilities


GETTING STARTED WITH OAUTH 2.0

OAuth 2.0 is an industry-standard protocol for authorization that allows users
to grant limited access to their resources on one website to another website
without sharing their credentials. It provides a secure and standardized way for
applications to authenticate and authorize users.


REGISTERING APPLICATION

Before you can start using OAuth 2.0, you need to register your application with
VerifyTreatment. Please send your registration request to developer@verifytx.con
to obtain your client credentials, including a client ID and client secret.


OBTAIN AN AUTHORIZATION GRANT

OAuth 2.0 supports multiple authorization flows, each designed for different use
cases. VerifyTreatment limits 3rd party access to following flows:

 1. Authorization Code Flow: This flow is suitable for server-side applications
    that can securely store client secrets. It involves exchanging an
    authorization code for an access token.
 2. Client Credentials Flow: This flow is used by applications that need to
    access resources on behalf of themselves rather than a specific user. It
    involves directly exchanging client credentials for an access token.


AUTHORIZATION CODE FLOW

The authorization code flow is a "three-legged OAuth" configuration. It involves
three parties: the user (resource owner), the client (application), and the
server (VerifyTreatment). Initially, the user obtains an authorization grant,
which is then exchanged for an access token by the client.


STEP 1: AUTHORIZATION REQUEST

The client initiates the flow by directing the user to the authorization
endpoint. The client includes its client identifier, requested scope, local
state, and a redirection URI to which the authorization server will send the
user-agent back once access is granted (or denied).

Property Description response_type code, client_credentials client_id client
identifier provided by VerifyTreatment redirect_uri Where the user is redirected
after successful log in scope (optional) permissions you wish to request from
the user, if none are defined default scopes will be used state (optional) This
parameter is optional but highly recommended. You should store the value of the
CSRF token in the user’s session to be validated when they return.

EXAMPLE REQUEST:

GET


STEP 2: USER AUTHORIZES ACCESS

When the user clicks the link, they must first log in to VerifyTreatment, then
will be prompted to authorize or deny the client's request to access data. If
the user clicks authorize, VerifyTreatment redirects the user-agent to the
client's redirection endpoint provided earlier. The redirection URI includes an
authorization code and the client's local state.

APPROVED REQUEST:

Property Description code authorization code state the state parameter sent in
the original request. You should compare this value with the value stored in the
user’s session to ensure the authorization code obtained is in response to
requests made by this client rather than another client application.

DENIED REQUEST:

Property Description error access_denied error_description
User+denied+the+request


STEP 3: EXCHANGE THE AUTHORIZATION GRANT FOR AN ACCESS TOKEN

Once you have obtained the authorization grant, you need to exchange it for an
access token. The exact process depends on the chosen flow.

AUTHORIZATION CODE FLOW:

EXAMPLE REQUEST:

POST
Content-Type: application/json

Property Description grant_type Set to "authorization_code" code The
authorization code obtained in the previous step client_id client identifier
provided by VerifyTreatment client_secret client secret provided by
VerifyTreatment redirect_uri Must match the redirect_uri used in the
authorization request

EXAMPLE RESPONSE:

Property Description token_type bearer id User id access_token Access token
refresh_token Refresh token expires_at Access token expiration time scopes
Requested scopes


CLIENT CREDENTIALS FLOW:

EXAMPLE REQUEST:

POST
Content-Type: application/json

Property Description grant_type Set to "client_credentials" client_id client
identifier provided by VerifyTreatment client_secret client secret provided by
VerifyTreatment

EXAMPLE RESPONSE:

Property Description token_type bearer id User id access_token Access token
refresh_token Refresh token expires_at Access token expiration time scopes
Requested scopes


ACCESSING PROTECTED RESOURCES

Once you have obtained an access token, you can use it to make requests to the
API on a user’s behalf.

The access token must be sent as a Bearer token in the Authorization header of
each request. The API will return a 401 Unauthorized response if the access
token is missing or invalid.


REFRESH ACCESS TOKEN

Access tokens have a limited lifetime specified by the expires_at field. If you
attempt to use an expired token, you will receive a 401 Unauthorized response
from the API. You can refresh an access token by using the refresh_token which
is returned when the access token is generated.

EXAMPLE REQUEST:

POST
Content-Type: application/json

Property Description grant_type refresh_token refresh_token refresh_token
received from the authorization request client_id client identifier issued by
VerifyTreatment client_secret client secret issued by VerifyTreatment scope
(optional) This is optional; if not sent the original scopes will be used,
otherwise you can request a reduced set of scopes.




VOBS


CREATE / SEARCH BENEFITS

You can create a new VOB by sending a POST request to the /vobs endpoint. The
facility and payer_id fields are required to complete the configuration request.

EXAMPLE REQUEST:

POST
Content-Type: application/json

Property Description first_name first name last_name last name member_id client
member id payer_id vtx_payer_id GET /payers date_of_birth date of birth
MM/DD/YYYY , YYYY-MM-DD client_type (optional) client_type [ prospect , termed ,
client , referred , discharged ] subscriber_relation (optional) client relation
to the subscriber insurance_phone (optional) insurance company phone
client_phone (optional) client company phone ssn (optional) client ssn gender
(optional) M/F/Other, facility (optional) Facility _id/ACCOUNT_DEFAULT from GET
/facility request. If facility is included it will overwrite the accounts
default facility when submitting the insurance request


LIST ALL VOBS

EXAMPLE REQUEST:

GET
Optional Query Parameters

Property Description sort available fields to sort are:
 * first_name
 * payer_name
 * coverage
 * insurance_filter
 * facility_filter
 * client_type
 * updated_at

You can append a "-" to the field name to sort descending coverage
 * Active Coverage
 * Unavailable
 * Inactive

payer_name Payer name from GET /payers facility Facility ID from GET /facilities
client_type
 * web_lead
 * prospect
 * client
 * referred
 * discharged
 * referred
 * termed

range
 * today
 * yesterday
 * last_7
 * last_30
 * last_60
 * last_90

created_by User ID from GET /users q Free text search skip Number of vobs to
skip (defaults to 0) limit Number of vobs to return (defaults to 20)


VIEW VOB

EXAMPLE REQUEST:

GET
Fields

Property Description rev History ID from GET /vob/:id/history


UPDATE VOB

EXAMPLE REQUEST:

PUT
Fields

Property Description action save / verify client_type
 * web_lead
 * prospect
 * client
 * referred
 * discharged
 * referred
 * termed

date_of_birth xxx email xxx facility xxx first_name xxx gender xxx group_number
xxx insurance_phone xxx last_name xxx member_id xxx payer_id xxx payer_name xxx
phone xxx place_of_service xxx ssn xxx subscriber_relation xxx tag xxx


DELETE VOB

EXAMPLE REQUEST:

DELETE


RE-VERIFY VOB

EXAMPLE REQUEST:

POST
Content-Type: application/json

Property Description _id VOB ID to re-verify


HISTORY

EXAMPLE REQUEST:

GET


SUBSCRIBER RELATIONS

Property Description SR01 Self SR02 Spouse SR03 Child SR04 Other Relationship
SR05 Other Adult




PAYERS

EXAMPLE REQUEST:

GET
Query Parameters

Property Description q Search Payer limit Number of payers to return skip Number
of payers to skip




FACILITIES

EXAMPLE REQUEST:

GET
Query Parameters

Property Description q Search Payer limit Number of payers to return skip Number
of payers to skip


JOIN VERIFYTREATMENT


GET STARTED WITH VERIFYTREATMENT TODAY!

Book a demo

Contact Book a demo
Terms of service Business Associate Agreement Privacy Policy
© 2023 VerifyTreatment