GraphQL API

Honeybase exposes a single GraphQL endpoint. Everything is namespaced one level under the roots: top-level Queries and Mutations fields each resolve to a namespace object whose fields are the actual operations.

query {
  tasks {
    listTasks(includeCompleted: false) {
      taskId
      name
      dueDate
    }
  }
}

Namespaces

Namespace	What's in it
tasks	Human work items: list/get/create/update/delete, time series, audit trail (taskUpdates)
processes	Processes, workflows (draft and released), runs (listProcessRuns, getProcessRun), stats
teams	Teams and membership
users	Organization members and roles
schedules, availability	Job schedules, availability state and history, reassignment
agents, tools, aiChat	AI agents, their runs and their tools
integrations, secrets, orgDatabase	Connections, secret names, the organization database
forms, taskViews, notifications, organize	As named
apiKeys, organizations, oauth, auth	Admin and session surfaces — not usable with an API key

The last row matters: an API key can never manage API keys, rename the organization, or perform anything the schema marks Requires Owner or Admin role. Those operations exist for the app's own session-authenticated calls.

Where to go next

1. Authentication — get a key and send it.
2. Conventions — ids, dates, and the JsonString gotcha.
3. Errors — read this before writing retry logic.
4. Schema reference — the generated, exhaustive type reference.

Reading the schema reference

The schema reference is generated directly from the running server's schema, so it is never out of date with the deployed API. Every operation's description ends with the permission it requires (Requires canManageTasks.) — check that before you call it, because a missing permission is not something to retry.