Hyperproof APIs enable programmatic access to your organization’s compliance data. Using these endpoints, your application can authenticate on behalf of a user to query, create, and update Hyperproof objects such as controls, labels, and uploaded proof. This allows for automated synchronization with external systems or custom workflows that extend Hyperproof’s core functionality.
Supported APIs
| Controls | Policies | Scope Assignments |
| Custom Apps | Policy Versions | Scopes |
| Custom Fields | Programs | Task Statuses |
| External Contacts | Proof | Tasks |
| Groups | Questionnaires | Test Results |
| Issues | Risks | Users |
| Labels | Roles | Vendors |
Because all API requests are executed on behalf of an authenticated Hyperproof user, each request must include valid authentication credentials. This article explains how to obtain and use these credentials when interacting with the Hyperproof API.
Every HTTP request made to Hyperproof APIs must be authenticated by Hyperproof. Hyperproof uses OAuth 2.0 as the primary means for request authentication.
OAuth 2.0 allows applications to obtain access to objects in Hyperproof such as controls, labels, issues, proof, custom fields, etc.
The following sections provide an overview of the OAuth protocol and how it's used with the Hyperproof API.
The OAuth protocol defines four specific roles. These roles are actively involved in the process of the authentication flow with Hyperproof APIs:
- Resource owner - The resource owner is an active Hyperproof user who can either authorize or decline a client from accessing information in a Hyperproof organization.
- Authorization server - The authorization server is responsible for authenticating the user and allowing them to consent to API access. The authorization server also provides access tokens and refresh tokens.
- Resource server - The resource server is the server that hosts the resource. If your app integrates with the Hyperproof API to obtain data that resides in a Hyperproof organization, the Hyperproof API server is considered the resource server.
- Client - The client is the app that requests access to the user’s information. If your app makes access requests to the Hyperproof API, your app is considered to be the client.
Note: In this article, you'll notice the terms "Client" and "app" are used interchangeably. Both of these terms refer to the app that needs to integrate with the Hyperproof API.
Hyperproof APIs supports client credentials.
The benefits of the client credentials flow are:
- Is intended for a specific Hyperproof organization, or
- Runs as a machine-to-machine integration (e.g. a CLI tool, background service, or backend process).
It generates an access token, which must be included in the authorization header of your API requests.
For more information, refer to OAuth client credentials flow.
All API requests must be made over HTTPS.
The base URL for the request is https://api.hyperproof.app/v1/. The complete URL varies depending on the resource being accessed.
For example, to list all of the controls in an organization, you must make an HTTP GET request to this URL: https://api.hyperproof.app/v1/controls. For this API to succeed, your app must have the control.read scope.
The access token retrieved through the OAuth 2.0 authorization code flow or the client credentials flow must be included in each request using the authorization header:
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2ZXIiOiIxLjAiLCJpc3...