Authentication - Delay Documentation

Overview

Delay API offers both authenticated and unauthenticated endpoints. For authenticated endpoints, an Authorization header containing a bearer token is required.

"Authorization": "Bearer $ACCESS_TOKEN"

API Tokens

There are two ways to obtain API tokens for the Delay API:

User App Token: This can be created from the developer options in the system settings. You can set the expiration date and configure permissions for this token.
Developer OAuth Token: To acquire this, you must register on the developer platform. You’ll receive a client_id, client_secret, and audience. Use these in the POST request to obtain an OAuth token.

POST https://auth.delay.com/oauth/token
{
  "grant_type": "password",
  "client_id": "$CLIENT_ID",
  "client_secret": "$CLIENT_SECRET",
  "audience": "https://hive.dev.delay.dev/admin/v1",
  "username": "$EMAIL",
  "password": "$PASSWORD"
}

Token Permissions

Tokens are in JWT format and the claims structure looks like this:

{
  "https://hive.delay.com/userID": "REDACTED_USER_ID",
  "iss": "REDACTED_ISSUER",
  "sub": "REDACTED_SUBJECT",
  "aud": "https://hive.dev.delay.dev/admin/v1",
  "iat": TIMESTAMP,
  "exp": EXPIRATION,
  "azp": "REDACTED",
  "gty": "password",
  "permissions": [
    "create:workspaces",
    "read:current_user",
    "read:workspace"
  ]
}

The permissions field lists the allowed operations on resources, using the format operation:resource. Operations like read, create, update, and delete correspond to the HTTP methods GET, POST, PUT, and DELETE. Some PATCH endpoints use more specific resources, like update:workspace_owner.

Row-Level Access Control

In addition to basic token-based permissions, Delay also implements row-level access control at the database level, leveraging PostgresSQL’s RLS features. For detailed information, refer to the official PostgresSQL documentation.