A RESTful API that supports read/write/delete/execute operations for a ClientTrack database. 

Calls to Client Track API are broken into categories:

• Generic
  • CRQL (ClientTrack REST Query Language) - SQL-like queries. Returns an array of results.
  • CTObjects - Named after the table name they refer to. Similar to CRUD operations for get, insert and update.
• Non-Generic - RESTful endpoints to manage resources (e.g. clients, enrollments, files, etc.

• A customer and/or third party integration partner has developers that will design API requests against the ClientTrack API 
• An integration use case needs to be triggered by an external application
• An integration partner needs limited access to a specific subset of data (like a ClientTrack User has limited access in the UI) based on ClientTrack's security model 

• Check to see if a client exists in ClientTrack using a name, email, and SSN
• Get a list of records filtered or sorted by any of the fields in the applicable table(s)
• Create a record or set of records in ClientTrack when something happens in an external app
• Execute a stored procedure in ClientTrack when something happens in an external app and access the outputs

• Integrations R&D Team Manages API Keys for CT API Users
  • Customers that want to test the CT API must contact their Client Success or Sales partner at Eccovia and provide information about the use case(s) to the INT R&D team to create correctly-scoped API keys Microsoft Forms

ClientTrack Form Designer plug-ins that enable designers to connect ClientTrack with external APIs.

• The integrating application has an API that supports HTTP requests 
• An integration use case needs to be triggered by a ClientTrack User taking some action such as
  • saving a record
  • clicking a button
  • navigating to a form
• An integration use case requires that an API request incorporates:
  • A ClientTrack User's input(s)/selection(s) 
  • Data from the ClientTrack database that could be pulled onto a ClientTrack form (either visible or hidden to end users)

• A ClientTrack form needs to gather and post data to an API when a user saves a new record (e.g. consent, encounter, visit, diagnosis, service, referral, case note, etc).
• A ClientTrack form needs to get information about a client from a third-party application (e.g. check their eligibility status with an insurance provider or retrieve their medical history)

• Multiple API Plug-in elements could be used in combination to support a multi-step process (e.g. an initial API request can be used to retrieve a list of results, and the ClientTrack User can then select a subset of those results to be used in a subsequent API request)
• Use cases requiring the transfer of a significant number of records or requiring a complex query of the database may be better suited for a different integration approach. In general, if it might be difficult to gather the information on the ClientTrack form with the other Form Design tools, it might be difficult to incorporate that data into an outbound API request with the API plug-ins

ClientTrack Users can create a cloud storage container via the ClientTrack UI to make .csv, .zip, and .xml files that they export from ClientTrack available to an external app via HTTP requests. When enabled, exporting a file in ClientTrack triggers a webhook to a configurable listener URL so that an external app can be notified when a new file is available. 

Microsoft Power Automate or other apps capable of sending/receiving HTTP requests can be used to facilitate file transfer integrations or other more complex integration use cases that are triggered by a ClientTrack file export.

ClientTrack User Containers: 

• The data set needing to be transferred or leveraged for an integration use case can be exported from ClientTrack as a .csv, .zip, or .xml file using ClientTrack's existing data export features
  • ‘Baseline’ exports using 'baselined’ SQL stored procedure(s) (e.g. HMIS CSV export) 
  • Custom exports using custom SQL stored procedure(s) created via ClientTrack's Query Designer or Data Explorer tools (or manually)

Microsoft Power Automate

• An integration use case necessitates an intermediary app for triggering, transforming, connecting, authenticating, etc., and the MPA capabilities will suffice in lieu of professional development services (either from Eccovia's integration R&D team or another third party)
• The customer has resources that are willing to learn and experiment with Microsoft Power Automate 

• Automate the transfer of the HUD HMIS Zip File to an SFTP folder owned by an external data warehouse
• Automate the transfer of a custom .csv file (based on a custom ClientTrack query) to an external app when an export occurs
• Send an email to a given stakeholder when an export occurs and the name of the file contains a certain key word

• Use this feature in combination with a scheduled asynchronous task to automate a recurring transfer of a file exported from ClientTrack

ClientTrack's Async Task Worker can chain a database task in a source ClientTrack environment to a database task in a destination ClientTrack environment. ClientTrack database tasks may include SQL stored procedures that export or import csv files, so chaining the tasks accross ClientTrack environments can facilitate intra-ClientTrack integrations.

• The ClientTrack to ClientTrack integration use case involves data sets that can be exported and imported using
  •  ‘baselined’ SQL stored procedures 
  • custom SQL stored procedures

• Export a HUD Zip file from a source ClientTrack environment and automatically import the file into a destination ClientTrack environment using existing 'baselined' stored procedures
• Export a custom csv file from a source ClientTrack environment and automatically import the file into a destination ClientTrack environment using custom SQL stored procedures. 

Custom stored procedures to be used for export can be generated using ClientTrack's Data Explorer and Query Designer features, but import stored procedures must be written manually