Budibase Authentication

generated: '2026-09-04'
method: searched
source: >-
  https://docs.budibase.com/docs/public-api and
  openapi/budibase-public-api-openapi.yml (securitySchemes), confirmed against live
  responses 2026-09-04
description: >-
  The Budibase Public API has exactly one authentication mechanism: a static per-user API
  key in a request header. There is no OAuth, no token exchange, no refresh, no scopes and
  no service account. Authorization is inherited wholesale from the RBAC role of the human
  user who generated the key.
summary:
  types:
    - apiKey
  api_key_in:
    - header
  oauth2: false
  openid_connect: false
  mutual_tls: false
  scopes: false
schemes:
  - name: ApiKeyAuth
    type: apiKey
    in: header
    parameter: x-budibase-api-key
    description: >-
      "Your individual API key, this will provide access based on the configured RBAC
      settings of your user." — verbatim from the OpenAPI securityScheme description.
    applied: global
    applied_detail: Declared at the root `security` level, so it covers all 44 operations.
    sources:
      - openapi/budibase-public-api-openapi.yml
      - https://docs.budibase.com/docs/public-api
context_headers:
  - name: x-budibase-app-id
    required: true
    scope: all table, row and view operations
    description: >-
      The workspace / app ID. Not a credential, but a request will fail without it, and the
      failure surfaces as a 400 or 403 that reads like an auth error.
    how_to_obtain: >-
      From the builder URL after /builder/workspace/. Drop the "_dev_" segment to address
      the published copy instead of the development copy.
key_management:
  issuance: >-
    Generated by an individual user from the Budibase portal user dropdown menu
    ("View API key").
  scope: >-
    One key per user. There is no way to issue a second key, a scoped key, or a key not
    tied to a human account.
  rotation: >-
    Generating a new key immediately invalidates the previous one. No overlap window, so
    rotation is a hard cutover with downtime for every integration using that key.
  revocation: Implicit — regenerate to revoke.
  expiry: None. Keys do not expire.
  service_accounts: >-
    Not supported. Any automation must borrow a human user's identity and privileges, and
    inherits everything that user can do.
authorization:
  model: RBAC inherited from the key owner
  roles:
    - BASIC
    - ADMIN
    - custom role IDs
    - per-app builder
    - global builder
    - global admin
  scoping_api: /roles/assign and /roles/unassign
  detail: >-
    There are no API scopes. Least privilege is achievable only by creating a dedicated
    Budibase user with a restricted role and using that user's key — a workaround, not a
    feature.
observed_failures:
  - status: 400
    message: Invalid API key provided, please check the x-budibase-api-key header.
    note: A missing or invalid key returns 400, NOT 401. See errors/budibase-problem-types.yml.
  - status: 401
    message: Session not authenticated
  - status: 403
    message: Workspace Admin/Builder user only endpoint.
transport_security:
  https_required: true
  tls: TLSv1.3
  hsts: max-age=31536000; includeSubDomains; preload
  observed: '2026-09-04'
well_known:
  openid_configuration: not served (404/502 on every host)
  oauth_authorization_server: not served (404/502 on every host)
  evidence: well-known/budibase-well-known.yml
sso_note: >-
  Budibase supports SSO including OpenID Connect for END USERS signing in to Budibase.
  That is a product feature and has no bearing on Public API authentication — the API
  accepts only the API key header.
gaps:
  - No scoped or least-privilege credentials.
  - No key expiry or rotation window; rotation is breaking by design.
  - No service accounts, so every integration is tied to a person who may leave.
  - Credential failure signalled with 400 rather than the conventional 401.
maintainers:
  - FN: Kin Lane
    email: kin@apievangelist.com