These endpoint allow you to create and manage access tokens to be used in API calls. Unlike most other endpoints, when creating an access token, these do not require an access token to be used. Instead you authenticate via another secure mechanism and in exchange you retrieve an access token.
openapi: 3.0.1
info:
title: Verifiable API Documentation Alerts Authentication API
description: "# Introduction\n\nThis document contains the official documentation for the latest version of the Verifiable API. Our solution has been built API-first. That means we first design our API's and build our own user interfaces on top of these API's afterwards. This results in a reusable API that can be used by 3rd parties to offer the exact same functionality as we can provide ourselves. Both the product and API are still subject to significant and potentially breaking changes, so please refer back to this documentation frequently. Any breaking change will be communicated ahead of time to our partners integrating with our API's.\n\n# Release Notes\n\nVerifiable customers can find [release notes](https://help.verifiable.com/hc/en-us/sections/49501536514067-Verifiable-APIs) in the Verifiable Help Center. To access the notes for the first time, go to the [Help Center](https://help.verifiable.com/hc/en-us) and click Sign up next to New to Verifiable.\n\n# Getting Started\n\nThis is a RESTful API that can be accessed using convential HTTP methods. It doesn't matter what programming language you use, there is already tooling available that can jumpstart you to access our API's. This documentation is based on OpenAPI 3.0 specifications and as such it is possible to dynamically generate a client in a language of your choice by simply loading our [specification document](https://api.discovery.verifiable.com/.well-known/openapi/vCurrent.json) in a tool such as [Swagger Codegen](https://swagger.io/tools/swagger-codegen/). It is not necessary to generate such a client and it is also possible to simply use any HTTP client to access our API. You can refer to the reference below to find the correct HTTP method, endpoint and model to use.\n\n### Environments\n\nWhen developing an integration with our API we typicially request you to use our `staging` environment for development and only start using `production` when your integration is stable and tested thoroughly. Please contact [Verifiable support](https://verifiable.com/contact) to be granted access to our environments.\n\n**Staging Base URL**\n```\nhttps://discovery-staging.verifiable.com/api\n```\n\n**Production Base URL**\n```\nhttps://discovery.verifiable.com/api\n```\n\n## Authentication\n\nMost endpoints require authentication to be used. You can authenticate to the API by passing an access token in the `Authentication` header using the `Bearer` scheme. An access token can be requested by authenticating against one of the [Authentication endpoints](/references/api/authentication).\n\n### Example using password authentication endpoint\n\n**Request:**\n\n```http\nPOST /auth/token/password HTTP/1.1\nContent-Type: application/json\nHost: https://<SERVER>\n{\n \"email\": \"john.doe@mail.com\",\n \"password\": \"secret\"\n}\n```\n\n**Response:**\n\n```http\nHTTP/1.1 200 OK\nDate: Fri, 25 Sep 2020 12:59:56 GMT\nContent-Type: application/json; charset=utf-8\n{\n \"tokenId\": \"2e5db76c-4c48-4cce-b11f-23a57ac5824c\",\n \"token\": \"MtetyFcIW...xgXXX-Z4yy\"\n}\n```\n\n### Example using access token\n\n**Request**\n\n```http\nGET /log/events HTTP/1.1\nAuthorization: Bearer <ACCESS_TOKEN>\nHost: https://<SERVER>\n```\n\nAn access token is bound to a single user in an organization. The access token should remain secret and be treated as if it were a password. We recommend you to create access tokens with a short time to live and frequently rotate them. Note that time to live requested might be lowered to a shorter duration based on your organization settings. These can be configured to enforce a suitable maximum time to live for your use-cases that facilitate users and service integrations.\n\n## Create a new provider\n\nA provider must be created and associated with license numbers, NPI numbers or other identifiers that can be used to perform lookups to fetch associated data for this provider.\n\n### Example creating a new provider\n\nTo create a new provider that can be used for license lookups:\n\n**Request:**\n\n```http\nPOST /providers HTTP/1.1\nContent-Type: application/json\nAuthorization: Bearer <ACCESS_TOKEN>\nHost: https://<SERVER>\n{\n \"firstName\": \"John\",\n \"lastName\": \"Doe\"\n}\n```\n\n**Response:**\n\n```http\nHTTP/1.1 201 Created\nDate: Fri, 25 Sep 2020 15:25:12 GMT\nContent-Type: application/json; charset=utf-8\nLocation: https://<SERVER>/providers/9706f2ea-9c1d-49f3-9a57-871159878c9c\n{\n \"firstName\": \"John\",\n \"lastName\": \"Doe\",\n \"id\": \"9706f2ea-9c1d-49f3-9a57-871159878c9c\",\n \"licenses\": []\n}\n```\n\n**Note:**\nThe `id` in the response is the `Provider id`. It can be used as a `Path Parameter` to attach licenses to this provider, using [Attach License](/references/api/licenses/attachlicense) API.\nYou will need to pass in a `licenseTypeId`, which can be obtained from the [List Simplified License Types](/references/api/licenses/listsimplifiedlicensetypes) API. For more details on providers see [Provider endpoints](/references/api/providers)\n\n## Get license types\n\nThe list of license types which are supported for license verification.\n\n### Example get license types\n\nReturns a list of all license types that are currently supported and used for license verifications.\n\n**Request**\n\n```http\nGET /licensetypes HTTP/1.1\nAuthorization: Bearer <ACCESS_TOKEN>\nHost: https://<SERVER>\n```\n\n**Response:**\n\n```http\nHTTP/1.1 200 OK\nDate: Fri, 25 Sep 2020 15:32:47 GMT\nContent-Type: application/json; charset=utf-8\n{\n \"nextOffset\": \"100\",\n \"nextCursor\": \"100\",\n \"pageSize\": 100,\n \"items\": [\n {\n \"id\": \"0059f76a-280a-377a-73e2-ddfe86f4113c\",\n \"name\": \"Medical Physician & Surgeon\",\n \"source\": {\n \"id\": \"72dcec62-a0d3-4af8-955d-07ecac8f1e4d\",\n \"name\": \"Missouri Division of ProfessionalRegistration\",\n \"state\": \"MO\",\n \"availability\": \"Available\",\n \"isDegraded\": false,\n \"url\": \"https://pr.mo.gov/licensee-search.asp\"\n }\n },\n ],\n \"sortedBy\": \"Id\",\n \"sortDirection\": \"Asc\"\n}\n```\n\n**Note:**\n`id` in response refers to `licenseTypeId`. It will be unique for each license type. Please see [List Simplified License Types](/references/api/licenses/listsimplifiedlicensetypes) for more details.\n\n## Attach a license to a provider\n\nTo perform a license verification you must attach a license to a provider. The first time you do this will automatically trigger a license verification on that provider. Once attached you can re-verify the same license without reattaching it. A provider can have more than one license attached.\n\n### Example attach license to a provider\n\n**Request:**\n\n```http\nPOST /providers/{providerId}/licenses HTTP/1.1\nContent-Type: application/json\nAuthorization: Bearer <ACCESS_TOKEN>\nHost: https://<SERVER>\n{\n \"licenseNumber\": \"123456\",\n \"licenseTypeId\": \"0059f76a-280a-377a-73e2-ddfe86f4113c\"\n}\n```\n\n**Response:**\n\n```http\nHTTP/1.1 201 Created\nDate: Fri, 25 Sep 2020 15:35:00 GMT\nContent-Type: application/json; charset=utf-8\nLocation: https://<SERVER>/providers/9706f2ea-9c1d-49f3-9a57-871159878c9c?licenseId=bfb028f0-52ca-47f4-8181-6b4c8262d29c\n{\n \"providerId\": \"9706f2ea-9c1d-49f3-9a57-871159878c9c\",\n \"licenseNumber\": \"123456\",\n \"licenseType\": {\n \"id\": \"0059f76a-280a-377a-73e2-ddfe86f4113c\",\n \"name\": \"Registered Nurse - RN\",\n \"source\": {\n \"id\": \"679b4f9a-cc3c-49e8-b560-0d0a9af47fd3”,\n \"name\": \"Missouri Division of ProfessionalRegistration\",\n \"state\": \"MO\",\n \"availability\": \"Available\",\n \"url\": \"https://pr.mo.gov/licensee-search.asp\"\n }\n }\n \"jobStatus\": \"Pending\",\n \"id\": \"b45cbeb0-873e-495b-8182-1b9a8b6d379d\"\n}\n```\n\n**Note:**\nRegister a Webhook to get notified on HTTP endpoint, this prevents the need to poll the API for completion checks. For more details on Webhooks please see [Webhooks endpoint](/references/api/webhooks) and for details on attaching a license see [Attach License endpoint](/references/api/licenses/attachlicense).\n\n## Fetch created provider\n\nReturns the data for a specific provider.\n\n### Example to fetch created provider\n\n**Request**\n\n```http\nGET /providers/{providerId} HTTP/1.1\nAuthorization: Bearer <ACCESS_TOKEN>\nHost: https://<SERVER>\n```\n\n**Response:**\n\n```http\nHTTP/1.1 200 OK\nDate: Fri, 25 Sep 2020 15:36:30 GMT\nContent-Type: application/json; charset=utf-8\n{\n \"firstName\": \"John\",\n \"lastName\": \"Doe\",\n \"id\": \"9706f2ea-9c1d-49f3-9a57-871159878c9c\",\n \"npis\": [],\n \"licenses\": [\n {\n \"providerId\": \"9706f2ea-9c1d-49f3-9a57-871159878c9c\",\n \"licenseNumber\": \"123456\",\n \"licenseType\": {\n \"id\": \"0059f76a-280a-377a-73e2-ddfe86f4113c\",\n \"name\": \"Registered Nurse - RN\",\n \"source\": {\n \"id\": \"679b4f9a-cc3c-49e8-b560-0d0a9af47fd3”,\n \"name\": \"Missouri Division of ProfessionalRegistration\",\n \"state\": \"MO\",\n \"availability\": \"Available\",\n \"url\": \"https://pr.mo.gov/licensee-search.asp\"\n }\n }\n \"jobStatus\": \"Idle\",\n \"currentVerificationStatus\": \"NeedsReview\",\n \"id\": \"b45cbeb0-873e-495b-8182-1b9a8b6d379d\"\n }\n ]\n}\n```\n\n**Note:**\nResponse contains attached licenses, NPI details for the given provider. To get details of these individual items (a particular License or an NPI), use unique identifiers in each of these categories. For more details check [Get specific license endpoint](/references/api/licenses/getlicense). Further details on providers are at [Providers endpoint](/references/api/providers).\n\n# Common Concepts\n\n## Pagination, filtering and sorting\n\nSome endpoints can return a large list of data. To allow you to efficiently iterate through this data these endpoints offer pagination, sorting and filtering. The concept will be similar for each endpoint that supports it:\n\n* Pagination, filtering and sorting parameters are provided through the query string.\n* Pagination, filtering and sorting is only supported for endpoints that return lists of data.\n* Filters is only supported for certain endpoints. You can refer to the documentation of the endpoint to find out if filtering is supported.\n* The `sortedBy` and `sortDirection` parameters can be used to specify the sorting method.\n* The `count` parameter can be used to specify the page size. Please note that the maximum and default page size can differ per endpoint.\n* (Deprecated) The `offset` parameter influences the start of the page. For the first page you can always omit this parameter. For any subsequent page you can supply the value from the `nextOffset` parameter as returned by the server.\n* The `cursor` parameter influences the start of the page. For the first page you can always omit this parameter. For any subsequent page you can supply the value from the `nextCursor` or `previousCursor` parameter as returned by the server.\n\nExample on how to make a paginated request:\n\n```http\nGET /log/events?sortDirection=Asc&sortedBy=Timestamp&count=10 HTTP/1.1\nAuthorization: Bearer <ACCESS_TOKEN>\nHost: https://<SERVER>\n```\n\nIn addition to returning a list of `items`, a paginated response will also return `nextCursor` and/or `previousCursor`. The value of this property can be used to fetch the next or previous page by passing it in the `cursor` parameter.\n\n## Error handling\n\nAll responses that do not indicate a success status code will return an error using the error model as specified by [RFC 7807](https://tools.ietf.org/html/rfc7807). The amount of details exposed by the error model varies and depends on the nature of the error. We attempt to include as much information as is necessary to be able to self-diagnose the problem that led to the error. Should this information not be enough, then we also supply a `correlationId` in the response. We kindly request you to make note of this value when contacting Verifiable support as this will help us to quickly locate more information on this error.\n\nExample error result on a malformed request:\n```json\n{\n \"type\": \"https://tools.ietf.org/html/rfc7231#section-6.5.1\",\n \"title\": \"One or more validation errors occurred.\",\n \"status\": 400,\n \"correlationId\": \"5e94110e-45a8-404c-831d-77eaeaa73ad6\",\n \"errors\": {\n \"$.firstName\": [\n \"The JSON value could not be converted to System.String. Path: $.firstName | LineNumber: 1 | BytePositionInLine: 18.\"\n ]\n }\n}\n```\n\n## Nullable properties\n\nIf an input parameter is required it is marked as such. If an input parameter is not marked as required and you do not wish or need to use it, you should omit the parameter completely in the request.\n\nFor response parameters you should always code defensively and assume that a parameter might be missing from the response. This could happen in case the parameter is not applicable (yet) or simply because the data is missing. By coding defensively and assuming that a parameter might be missing you also future proof your solution for potential future (otherwise) breaking changes.\n\n## Flexible data model\n\nIn some cases we collect data from external sources that are hard to fit in a single predefined schema. For these cases we have come up with a flexible data model that allows us to store structured data in 3 different ways:\n - Form \n - Table \n - Section\n \n### Table\n\nData that can be represented in a table structure. The keys of every element/object in the data array is expected to be the same.\n\n```json\n{\n \"type\": \"Table\",\n \"data\": [\n {\n \"Status Code\": \"CB\",\n \"Effective Date\": \"06/10/2016\",\n \"Description\": \"CANCELLED BY BOARD\"\n },\n {\n \"Status Code\": \"NA\",\n \"Effective Date\": \"06/10/2016\",\n \"Description\": \"NOT ACTIVE\"\n }\n ]\n}\n```\n\n### Section\nSections are used to represent multiple different data representations. For example, additional properties can \nhave three sections with section one being a Form, while the other two could be a table. \nAlso note there could be sections with and without heading.\n\n#### With section heading\n```json\n{\n \"type\": \"Section\",\n \"data\": {\n \"Discipline\": {\n \"type\": \"Form\",\n \"data\": {\n \"Discipline/Final Orders state\": \"ILLINOIS\",\n \"Date action was taken\": \"02/03/2020\",\n \"Against privilege to practice (PTP)\": \"N/A\"\n }\n },\n \"NPDB code\": {\n \"type\": \"Form\",\n \"data\": {\n \"NPDB code\": \"39 - LICENSE REVOCATION, SUSPENSION OR OTHER DISCIPLINARY ACTION TAKEN BY A FEDERAL, STATE OR LOCAL LICENSING AUTHORITY\"\n }\n },\n \"Actions\": {\n \"type\": \"Form\",\n \"data\": {\n \"Initial action date\": \"02/03/2020\",\n \"Effective date(s)\": \"02/03/2020 - INDEFINITE/UNSPECIFIED\",\n \"Is license automatically reinstated after the effective date(s)\": \"NOT SUPPLIED\",\n \"NPDB code\": \"1148 - DENIAL OF LICENSE RENEWAL\"\n }\n }\n }\n}\n```\n\n#### Without section heading\n```json\n{\n \"type\": \"Section\",\n \"data\": [\n {\n \"type\": \"Form\",\n \"data\": {\n \"Discipline/Final Orders state\": \"ILLINOIS\",\n \"Date action was taken\": \"02/03/2020\",\n \"Against privilege to practice (PTP)\": \"N/A\"\n }\n },\n {\n \"type\": \"Form\",\n \"data\": {\n \"NPDB code\": \"39 - LICENSE REVOCATION, SUSPENSION OR OTHER DISCIPLINARY ACTION TAKEN BY A FEDERAL, STATE OR LOCAL LICENSING AUTHORITY\"\n }\n },\n {\n \"type\": \"Form\",\n \"data\": {\n \"Initial action date\": \"02/03/2020\",\n \"Effective date(s)\": \"02/03/2020 - INDEFINITE/UNSPECIFIED\",\n \"Is license automatically reinstated after the effective date(s)\": \"NOT SUPPLIED\",\n \"NPDB code\": \"1148 - DENIAL OF LICENSE RENEWAL\"\n }\n }\n ]\n}\n```\n\n### Form\n\nA form is essentially a simple key/value collection, but it can also have nested flexible data.\n\n#### Simple form\n```json\n{\n \"type\": \"Form\",\n \"data\": {\n \"Date of Birth\": \"1958\",\n \"Registration Date\": \"06/13/2016\",\n \"Disciplinary Status\": \"CANCELLED BY BOARD\"\n }\n}\n```\n\n#### Nested form\n\n```json\n{\n \"type\": \"Form\",\n \"data\": {\n \"Date of Birth\": \"1958\",\n \"Registration Date\": \"06/13/2016\",\n \"Disciplinary Status\": \"CANCELLED BY BOARD\",\n \"Status Change\": {\n \"type\": \"Table\",\n \"data\": [\n {\n \"Status Code\": \"CB\",\n \"Effective Date\": \"06/10/2016\",\n \"Description\": \"CANCELLED BY BOARD\"\n },\n {\n \"Status Code\": \"NA\",\n \"Effective Date\": \"06/10/2016\",\n \"Description\": \"NOT ACTIVE\"\n }\n ]\n }\n }\n}\n```\n\n## API Rate Limiting\n\n### Overview\n\nTo ensure the stability and performance of the Verifiable Platform API for all users, we enforce rate limits on API requests. \nThese limits help maintain fair access and high availability across all clients.\n\n### Rate Limits\n\nAPI requests are rate limited to **10,000 requests per 5 minutes.** \nIf a client exceeds this limit, the API will return an HTTP **429 Too Many Requests** response.\n\nVerifiable may adjust rate limits in the future based on factors such as endpoint-specific traffic patterns or system load. \nChanges may include increasing or decreasing limits or introducing secondary rate limits for specific use cases. \nAny changes will be reflected in this documentation.\n\nExample response:\n\n```http\nHTTP/1.1 429 Too Many Requests\n{\n \"title\": \"You have exceeded the allowed rate limit of 10,000 per 5 mins. Try again later.\",\n \"status\": 429\n}\n```\n\n"
version: 26.12.1.962
servers:
- url: https://discovery.verifiable.com/api
description: Production
- url: https://discovery-staging.verifiable.com/api
description: Staging
tags:
- name: Authentication
description: 'These endpoint allow you to create and manage access tokens to be used in API calls. Unlike most other endpoints, when creating an access token, these do not require an access token to be used. Instead you authenticate via another secure mechanism and in exchange you retrieve an access token.
'
paths:
/auth/token/password:
post:
tags:
- Authentication
summary: 'Password Authentication
'
description: 'Endpoint for authentication using an email and password for a user already registered at Verifiable. In return you will receive an access token that can be used in the following API calls.
**Note:** The account may require a password change for successful authentication. If password change is required and `newPassword` is not set the server returns `409 Conflict`.
If `newPassword` is set but the current `password` is not correct the server returns `403 Forbidden`.
**Note:** If `newPassword` is set it *must* be different than the current password. If the password is the same the server returns `400 Bad Request`.
**Note:** When `newPassword` is set and the request returns `200 Ok`, all the active access tokens will be invalidated.
'
operationId: PasswordAuth
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/PasswordAuthModel'
responses:
'200':
description: Success
content:
application/json:
schema:
$ref: '#/components/schemas/AuthResponseModel'
'400':
description: Bad Request
'401':
description: Unauthorized
'403':
description: Forbidden
'409':
description: Conflict
'500':
description: Server Error
/auth/password/reset:
post:
tags:
- Authentication
summary: 'Resets a password
'
description: 'Endpoint for changing a password using a token.
'
operationId: PasswordReset
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/PasswordResetRequestModel'
responses:
'204':
description: No Content
'404':
description: Not Found
'400':
description: Bad Request
'403':
description: Forbidden
'500':
description: Server Error
/auth/password/requestreset:
post:
tags:
- Authentication
summary: 'Requests a password reset
'
description: "Endpoint for requesting a password reset.\n\nIf the e-mail sent in the body of this request has an account associated with it, a message with a link for changing the password will be sent to it. \n"
operationId: RequestPasswordReset
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/RequestPasswordResetRequestModel'
responses:
'204':
description: No Content
'400':
description: Bad Request
'403':
description: Forbidden
'500':
description: Server Error
/auth/token/google:
post:
tags:
- Authentication
summary: 'Google Authentication
'
description: 'It is possible to use Google Sign-In for authentication with the Verifiable API. In order to do so we follow the [Google Sign-In for server-side apps](https://developers.google.com/identity/sign-in/web/server-side-flow) flow. In order to use this flow you must use the `client ID` from Verifiable when signing in to Google and send the authorization code as payload to this endpoint. In return you will receive an access token that can be used in the following API calls. The email address of the user must already be registered at Verifiable.
'
operationId: GoogleAuth
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/GoogleAuthModel'
responses:
'200':
description: Success
content:
application/json:
schema:
$ref: '#/components/schemas/AuthResponseModel'
'400':
description: Bad Request
'401':
description: Unauthorized
'403':
description: Forbidden
'500':
description: Server Error
/auth/token:
get:
tags:
- Authentication
summary: 'List active access tokens
'
description: 'Returns all access tokens for the current user that are neither expired, nor invalidated.
'
operationId: ListActiveAccessTokens
parameters:
- name: sortedBy
in: query
description: The property by which the returned data will be sorted.
schema:
enum:
- Id
type: string
- name: sort
in: query
description: If set, the properties and directions the returned data will be sorted by.
schema:
type: object
properties:
Keys:
enum:
- Id
type: string
Values:
enum:
- Asc
- Desc
type: string
- name: offset
in: query
description: The offset for the page to start.
deprecated: true
schema:
type: integer
format: int32
- name: cursor
in: query
description: The cursor to render the page requested. To load the first page send an empty cursor, then the system will generate the cursors to go to the next and/or previous pages automatically.
schema:
type: string
- name: count
in: query
description: The number of items to include in a single page.
schema:
type: integer
format: int32
- name: sortDirection
in: query
description: The direction the returned data will be sorted by.
schema:
enum:
- Asc
- Desc
type: string
responses:
'200':
description: Success
content:
application/json:
schema:
$ref: '#/components/schemas/AccessTokenPageModel'
'400':
description: Bad Request
'401':
description: Unauthorized
'500':
description: Server Error
security:
- Bearer: []
/auth/token/{tokenId}/invalidate:
post:
tags:
- Authentication
summary: 'Invalidate an access token
'
description: 'Invalidates an access token so that it can no longer be used.
'
operationId: InvalidateAccessToken
parameters:
- name: tokenId
in: path
description: The unique identifier of the access token to be invalidated.
required: true
schema:
type: string
format: uuid
responses:
'204':
description: No Content
'400':
description: Bad Request
'401':
description: Unauthorized
'404':
description: Not Found
'500':
description: Server Error
security:
- Bearer: []
/auth/token/invalidate:
post:
tags:
- Authentication
summary: 'Invalidate multiple access tokens
'
description: 'Invalidates multiple access tokens that belongs to the user making the request so they can no longer be used.
'
operationId: InvalidateAccessTokens
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/InvalidateAllAccessTokensRequestModel'
responses:
'204':
description: No Content
'401':
description: Unauthorized
'500':
description: Server Error
security:
- Bearer: []
/auth/oauth/token:
post:
tags:
- Authentication
summary: 'OAuth Authentication
'
description: '**🔒 Premium Feature**
The OAuth 2.0 (machine-to-machine) and SSO authentication flows are premium features that must be enabled by the Verifiable team.
- **Availability:** These features are available as add-ons to select Verifiable plans.
- **Provisioning:** These features require organizational-level provisioning through a one-time configuration by the Verifiable team. To ensure maximum security, endpoints are not enabled by default.
- **Next Steps:** To enable these authentication methods for your organization, please contact your Customer Success Manager or [reach out to our Support Team](mailto:support@verifiable.com).
<br/>
It is possible to use the OAuth Client Credentials flow to authenticate with the Verifiable API. In order to use this flow, you must use the `client ID` and a `client secret` from Verifiable. You must send the client credentials along with the grant type `client_credentials` in a URL-encoded format.
'
operationId: OAuthToken
requestBody:
content:
application/x-www-form-urlencoded:
schema:
type: object
properties:
client_id:
type: string
format: uuid
client_secret:
type: string
grant_type:
type: string
encoding:
client_id:
style: form
client_secret:
style: form
grant_type:
style: form
responses:
'200':
description: Success
content:
application/json:
schema:
$ref: '#/components/schemas/OAuthTokenResponseModel'
'400':
description: Bad Request
'401':
description: Unauthorized
'403':
description: Forbidden
'500':
description: Server Error
components:
schemas:
RequestPasswordResetRequestModel:
required:
- email
type: object
properties:
email:
minLength: 1
type: string
description: The e-mail address from the account which should have the password reset.
format: email
additionalProperties: false
UserRoleModel:
type: object
properties:
id:
type: string
format: uuid
name:
enum:
- Admin
- LimitedAdmin
- Credentialing
- LimitedCredentialing
- Reader
- LimitedReader
type: string
permissions:
type: object
additionalProperties:
enum:
- None
- Read
- Write
- Allowed
type: string
nullable: true
additionalProperties: false
GoogleAuthModel:
type: object
properties:
code:
type: string
description: The authorization code returned by the Google Sign-In authentication flow.
timeToLive:
type: string
description: If set, the created token will expire after the duration specified by this parameter. Note that the token will still be expired after 4 weeks of no use, regardless of the time to live. Additionally there might be a limit set for your organization. If the requested time-to-live exceeds this limit the token will be capped to that limit.
format: timespan
token:
type: string
description: The JWT token returned by Google Sign-In authentication flow.
additionalProperties: false
example:
code: 4/yU4cQZT...4z7U4UmAI
timeToLive: 00:30:00
OAuthTokenResponseModel:
type: object
properties:
access_token:
type: string
description: The access token to use to access the Verifiable API.
token_type:
type: string
description: The OAuth 2.0 token type (ex. `Bearer`).
expires_in:
type: integer
description: The number of seconds in which the access token will expire.
format: int32
additionalProperties: false
PasswordResetRequestModel:
required:
- newPassword
- token
type: object
properties:
token:
type: string
description: The token received via e-mail.
newPassword:
type: string
description: The new password that will be set to the user associated with the token.
additionalProperties: false
AuthResponseModel:
type: object
properties:
tokenId:
type: string
description: Unique identifier for this token. This can be used to invalidate a token.
format: uuid
token:
type: string
description: The access token to be used in following API calls.
email:
type: string
description: The e-mail address of the user. It will either be the same e-mail address used on the password authentication or the e-mail address of the Google account in the case of Google authentication.
role:
$ref: '#/components/schemas/UserRoleModel'
expiresAt:
type: string
description: Expiration time of the access token.
format: date-time
persistenceHint:
enum:
- Persistent
- Ephemeral
type: string
additionalProperties: false
example:
t
# --- truncated at 32 KB (37 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/verifiable/refs/heads/main/openapi/verifiable-authentication-api-openapi.yml