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
Submission: On May 29 via automatic, source certstream-suspicious — Scanned from DE
Form analysis
0 forms found in the DOMText 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