Healthie's API & SDKs

Healthie is an API-first company and our API product is the same that our own front-end developers use to build our web and mobile apps. Here is an overview of our features available through the API.

Our API is an available add-on for members on our Enterprise Plan. 

Healthie offers a closed API that enables you to tap into the back-end of the HIPAA and SOC 2-compliant software platform. You can request API docs here: https://www.gethealthie.com/api-overview

IN THIS ARTICLE:

About Healthie's API

When you access Healthie's API, you get all features included in Healthie, and Healthie's API documentation offers support for our entire feature suite. Moreover, you get the same exact API, feature set, documentation, and updates that Healthie's team uses internally to build the front-end product. As a result, there are no feature gaps between Healthie's UI and the API. 
Facts about Healthie's API:
  • Healthie's API processes tens of millions of requests a month, across hundreds of thousands of active users.
  • Healthie's API is backwards compatible. As Healthie updates the API and platform, your API access is automatically updated. 
  • Healthie's API utilizes GraphQL. Healthie is built on Ruby / Postgres, React, React Native, Swift, Java. 
  • It is possible to have one webhook hitting multiple endpoints if needed. 

Security and Privacy

Here is some information on Healthie's Security and Privacy

Getting Started with Our API

How Organizations use Healthie's API

Healthie's Organizations have leveraged Healthie's API to build member experiences, build tooling for providers, and much more. You can use Healthie fully headless leveraging the API, and/or leverage components of Healthie's UI alongside your own build. 

You can leverage the API to build in the language of your choice. 

We see customers use the API to do everything from:

  • Develop custom front-end interface for providers and/or clients leveraging Healthie's back-end functionality (e.g., build out your own member experience leveraging our API / SDKs)
  • Access data across the platform to establish custom dashboards and connect with your data warehouse
  • Add automations to tie features of Healthie together for your clinical workflows
  • Create custom onboarding / intake experiences for prospective clients, leveraging intake flow fields and connections to calendar, for example for provider matchmaking
  • Leveraging our existing integrations, or build your own integrations, to weave Healthie into your tech-stack
  • Some organizations will use Healthie's API adjacent to the web white-label and mobile white-label to further customize the experience for clients 
  • and much more

API Best Practices

Here are some best practices / typical use cases for prioritizing a build with Healthie's API

Notes: 

QAs and SLAs

As a developer-first technology company, maintaining a high-quality, functional API experience is incredibly important to us. Given that we use the same API that we offer to our customers, there is an inherent level of quality that exists in the API, as it is naturally battle tested. 

We have historically maintained an uptime of 99.99% and our Enterprise Plan includes an SLA. 

Sandbox (Staging) environment

We can provision a Sandbox (Staging) environment as part of working with the API. This is distinct from your Production account. Here are some best practices & differences between the two environments: 

  • Sandbox (Staging): 
    • This is a great testing environment, where you will have nearly all of the capabilities of Healthie. You can, for example, create fake provider and client accounts, test experiences like onboarding and package creation. 
    • Protected Health Information (PHI), i.e., actual patient data, is not allowed in any form in the Sandbox (Staging) environment. Data put into the Sandbox (Staging) environment via the API or UI must be fake, which means that no HIPAA identifiers for PHI may be included (for a full list, see the '"Safe Harbor" method' at https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html). If you have a use case where you need to test PHI data in a production-like environment, please contact hello@gethealthie.com
    • Some integrations are not available in your sandbox account (e.g., Zoom, Outlook, iCal syncs)
    • Google Calendar can be used on Sandbox, but Healthie has to pre-approve the account prior to your using it. 
    • Dosespot E-Rx can be tested in Sandbox
    • Sandbox is less resourced than Production, so you may see higher latency taking some actions in Sandbox
  • Production: Your actual, live Healthie account. You would want to take actions like build out forms and finalize settings in your Production environment. 

Sandbox (Staging) and Production are two independent environments, and data / settings cannot transfer from Staging to Production. Learn more about generating API Keys and Webhooks in your Sandbox account here.

SDKs

In addition to our GraphQL API, we also provide React SDKs to make it easier for developers to work with our API within their existing frontend applications and accelerate the development process.

Our SDKs provide a set of pre-built components and functions that can be integrated into your application, allowing you to access the functionality of Healthie's API with minimal setup and configuration. However, it is important to note that while the SDKs provide a simplified way to interact with our API, the developer is still responsible for providing the scaffolding and overall structure of the application.

It's worth to mention that these SDKs are designed to work with our GraphQL API only, and it is recommended to have a basic understanding of our API before using them.

Currently Healthie provides SDKs for the following capabilities (and we continue to roll out additional SDKs, which we add to this list):

API FAQs

Are there any rate limits or quotas on API calls, and how are they enforced?

We have adjusted our API rate limits to the following: 

  • Maximum of 100 sign-ins per minute 
  • Maximum of 250 RPS (requests per second)*

*If leveraging your own API database, we will continue to support rate limiting at 1000 RPS. 

Learn more here: https://docs.gethealthie.com/docs/#rate-limits


Are there any data limitations we should be aware of when integrating (e.g., field lengths, special characters, data formats)?

No, there are no data limitations you should be aware of when you are integrating with the Healthie platform.


Are there any IP allowlisting or API key rotation policies we should be aware of?

No, there are no IP allowlisting or API key rotation policies you should be aware of. For security purposes for incoming Webhooks, you may want to allowlist Healthie’s IP address.

Learn more here: https://docs.gethealthie.com/docs/#webhooks


What are the average response times for API requests, and how do they scale with increased load?

It is hard to provide an exact relevant average as the complexity of a GraphQL query depends on how it is written by Healthie's API consumer. Healthie's average response time overall is around 300-500 ms. This response time can vary a lot based on the type of query you are making, and what you are including in your query. Healthie processes over a billion requests a month so a specific API user should not expect response times to change with load.


How does the API handle large volumes of concurrent requests?

Healthie handles large volumes of concurrent requests daily - 400 million API calls per month. Please click here for more details on the number of API calls per month.


How is data consistency managed, especially in real-time or near-real-time integrations? In other words, are updates immediate or eventual?

Most integrations are immediate updates. A handful of integrations are cached.


Are there webhooks or other mechanisms to receive real-time updates for events within Healthie?

Webhooks are available to receive real-time updates for events within Healthie.

Learn more here: https://docs.gethealthie.com/docs/#webhooks


Are there logs or debugging tools available to help troubleshoot issues during integration?

If you’re making a request and getting errors, Healthie's Solutions Engineering team can review issues on our end and provide you with more details. Healthie's team has access to the logs and reviews if necessary.


Are there any specific compliance considerations we need to take into account when integrating?

To use the API, no, there are no specific compliance considerations that you need to take into account.


What security measures are in place to protect data accessed through the API?

API keys can only be used to access data that they have access to. 


What level of technical support can we expect during the integration process?

With the purchase of Healthie’s APIs, you will have access to 5 hours of technical support each month with a dedicated Solutions Engineer.


Are there any resources or communities (e.g., developer forums, technical blogs) available to assist with integration challenges?

No, there are not any resources or communities (e.g. developer forums, technical blogs) available to assist through Healthie at this time.


How are breaking changes communicated and managed?

Breaking changes are communicated and managed using the following best practices: https://docs.gethealthie.com/docs/#deprecation-policy


What is the high-level process of embedding Healthie UI into our own UI? Is it through iframes? Both web and mobile?

You can embed links on websites for calendars and packages through Healthie or by using Healthie’s API to grab/send data, and create your own frontend.

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.