Hint Health API

Hint API Developer Hub

HintOS integrations is our answer to healthcare’s longstanding dependence on insufficient all-in-one systems. It is ‘best-of-breed” technology that allows provider organizations to instantly snap together a dream team of industry-leading applications. The result? Complete, fully integrated solutions that function seamlessly together.

We invite you to become a part this ecosystem of integration solutions.


Hint's API is RESTful, and returns JSON. It fully powers our front-end apps, which means we're hitting the same endpoints that you will be.

There are two types of resources you can access through the Hint API.

The Partner Resources

The Partner resources are things that let you manage settings and view information related to your Partner account. This includes basic details like name and logo (which every Practice sees when browsing integrations in our application) to webhook request history, which can help you debug issues.

The official list of Partner resources are Partner, WebhookRequest, Integration, and OAuth.

To use the Partner resources you'll need to authenticate with your Partner API key.

See the Hint Connect Process for details on receiving that API key.

The Provider Resources

The Provider resources are anything under the '/provider' namespace. This is how you'll access and modify all the data related to a single practice who has enabled your integration.

To use the Provider endpoint you'll need to authenticate using a different access_token for each practice as the API key.

See InstantOn (via OAuth) for an easy way to allow Hint Practices to enable your integration.

See our API Reference for endpoint details, and example responses.

API May Change!

We will do our best to keep this API stable, and to give reasonable lead time on any breaking changes. However, routes/responses may change unexpectedly, and nothing has been frozen!

PUT and PATCH are treated the same.

Anywhere you see a "PATCH" method in these docs, our API will also support "PUT". From an HTTP semantics standpoint, since we do not expect (nor want) you to send us the entire new version of the object you wish to change, it is preferred to use PATCH. However, if for technical reasons this is not possible, then a PUT is also acceptable, and it will be treated the same as a PATCH request.

Updated 2 years ago

What's Next

Making Requests


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.