API Reference
Every operation of the REST API, generated from the OpenAPI document and grouped by resource.
Every operation of the REST API, generated from the OpenAPI document Zuse Bifrost publishes and grouped by resource: the request fields with their types and constraints, the response fields, every refusal, the ability the token must carry, the webhook events the call fires, the MCP tools that wrap it, code samples in seven languages, and a playground that sends the request to the API host with your token. Each group has an overview page and one page per operation; a row below opens the operation's page.
Activity API
Every mutation Zuse Bifrost performs, whether from the app, the REST API, an MCP tool call, an accepted Heimdall draft or a scheduled system task, is recorded against its subject in the activity log. Read the overview.
Alert Destinations API
An alert destination is a place your alerts go: your email address or the Telegram chat linked to your account. Read the overview.
/v1/me/alert-destinationsList your alert destinationsPUT/v1/me/alert-destinationsReplace your alert destinationsApprovals API
An approval request is one time a planning record was put up for approval: an epic, a story, a requirement, a business rule or a use case, a baseline or a change request, submitted by its author and decided by the approvers the project's policy names for that kind of approval. Read the overview.
/v1/approvalsList the inboxGET/v1/approvals/{approval}Get an approval requestGET/v1/projects/{project}/approval-policiesList a project's approval policiesPUT/v1/projects/{project}/approval-policiesUpdate a project's approval policyGET/v1/projects/{project}/approvalsList a project's approvalsPOST/v1/approvals/{approval}/decideDecide an approvalPOST/v1/approvals/{approval}/withdrawWithdraw an approvalPOST/v1/baselines/{baseline}/submitSubmit a baselinePOST/v1/change-requests/{changeRequest}/submitSubmit a change requestPOST/v1/business-rules/{rule}/submitSubmit a business rulePOST/v1/requirements/{requirement}/submitSubmit a requirementPOST/v1/use-cases/{useCase}/submitSubmit a use casePOST/v1/epics/{epic}/submitSubmit an epicPOST/v1/work-items/{item}/submitSubmit a storyAttachments API
An attachment is a file pinned on one artefact of a project: a wireframe on a story, a signed specification on a requirement, a sample export on a data entity, a vendor quote on a decision. Read the overview.
/v1/projects/{project}/attachmentsList an artefact's attachmentsPOST/v1/projects/{project}/attachmentsUpload an attachmentGET/v1/attachments/{attachment}/downloadDownload an attachmentDELETE/v1/attachments/{attachment}Delete an attachmentBaselines API
A baseline is a named set of approved records frozen together: the scope the client signs before the build starts, what a release ships, what a sprint commits to, or the record as it stood at a milestone. Read the overview.
/v1/baselines/{baseline}Get a baselinePATCH/v1/baselines/{baseline}Update a baselineDELETE/v1/baselines/{baseline}Delete a baselineGET/v1/baselines/{baseline}/revisionsList a baseline's versionsGET/v1/baselines/{baseline}/revisions/{revision}Get a version of a baselineGET/v1/projects/{project}/baselinesList baselinesPOST/v1/projects/{project}/baselinesAdd a baselinePUT/v1/baselines/{baseline}/itemsSet a baseline's itemsPOST/v1/baselines/{baseline}/statusMove a baselinePOST/v1/baselines/{baseline}/revisions/{revision}/restoreRestore a version of a baselineBusiness Rules API
A business rule is a decision of the business the system must honour: a limit it refuses to cross, a fact derived from others, a number worked out from others, a conclusion drawn when conditions hold, an action it takes when they do, or a standing policy. Read the overview.
/v1/business-rules/{rule}Get a business rulePATCH/v1/business-rules/{rule}Update a business ruleDELETE/v1/business-rules/{rule}Delete a business ruleGET/v1/business-rules/{rule}/revisionsList a business rule's versionsGET/v1/business-rules/{rule}/revisions/{revision}Get a version of a business ruleGET/v1/business-rules/{rule}/quality-reviewsList a business rule's quality reviewsPOST/v1/business-rules/{rule}/quality-reviewsReview a business rule's qualityGET/v1/projects/{project}/business-rulesList business rulesPOST/v1/projects/{project}/business-rulesAdd a business rulePOST/v1/business-rules/{rule}/statusMove a business rulePOST/v1/business-rules/{rule}/revisions/{revision}/restoreRestore a version of a business ruleChange Requests API
A change request is a change asked for after the record was agreed: a new requirement, a clarification, a defect in the baseline, a regulatory demand, a client's wish, a piece of technical debt or a scope reduction. Read the overview.
/v1/change-requests/{changeRequest}Get a change requestPATCH/v1/change-requests/{changeRequest}Update a change requestDELETE/v1/change-requests/{changeRequest}Delete a change requestGET/v1/change-requests/{changeRequest}/revisionsList a change request's versionsGET/v1/change-requests/{changeRequest}/revisions/{revision}Get a version of a change requestGET/v1/projects/{project}/change-requestsList change requestsPOST/v1/projects/{project}/change-requestsRaise a change requestPOST/v1/change-requests/{changeRequest}/statusMove a change requestPOST/v1/change-requests/{changeRequest}/verifyVerify a change requestPOST/v1/change-requests/{changeRequest}/analyseAnalyse a change request's impactPOST/v1/change-requests/{changeRequest}/revisions/{revision}/restoreRestore a version of a change requestClients API
A client is an organisation the team does projects for: its names, its primary contact, where it works from and where the relationship stands. Read the overview.
/v1/clientsList clientsPOST/v1/clientsCreate a clientGET/v1/clients/{client}Get a clientPATCH/v1/clients/{client}Update a clientDELETE/v1/clients/{client}Delete a clientPOST/v1/clients/{client}/archiveArchive a clientPOST/v1/clients/{client}/restoreRestore a clientComments API
A comment is a note on one artefact of a project: a question on a requirement, an answer under it, a finding on a story, a decision taken in the margin of a RAID item. Read the overview.
/v1/projects/{project}/commentsList an artefact's commentsPOST/v1/projects/{project}/commentsPost a commentPATCH/v1/comments/{comment}Edit a commentDELETE/v1/comments/{comment}Delete a commentPOST/v1/comments/{comment}/resolveResolve a threadPOST/v1/comments/{comment}/reopenReopen a threadComponents API
A component is one application a project is made of: the web app, the API, a mobile app, a background service, an integration, a database or the platform itself. Read the overview.
/v1/components/{component}Get a componentPATCH/v1/components/{component}Update a componentDELETE/v1/components/{component}Delete a componentGET/v1/projects/{project}/componentsList componentsPOST/v1/projects/{project}/componentsCreate a componentPOST/v1/components/{component}/archiveArchive a componentPOST/v1/components/{component}/restoreRestore a componentCouncil API
The council is Heimdall with named voices beside it: Odin for architecture and the data model, Thor for testing, Loki for security, Týr for rigour and compliance, Frigg for planning and risk, Baldur for the people who will use the product and Hel for what fails in production. Read the overview.
/v1/projects/{project}/councilList a project's council sessionsPOST/v1/projects/{project}/councilConvene the councilGET/v1/council/{session}Retrieve a council sessionPOST/v1/council-findings/{finding}/acceptAccept a council findingPOST/v1/council-findings/{finding}/dismissDismiss a council findingData Entities API
A data entity is a thing the project keeps records of: a customer, an order, a branch, a shipment. Read the overview.
/v1/data-entities/{entity}Get a data entityPATCH/v1/data-entities/{entity}Update a data entityDELETE/v1/data-entities/{entity}Delete a data entityGET/v1/data-entities/{entity}/revisionsList a entity's versionsGET/v1/data-entities/{entity}/revisions/{revision}Read one version of a entityGET/v1/projects/{project}/data-entitiesList data entitiesPOST/v1/projects/{project}/data-entitiesCreate a data entityPOST/v1/data-entities/{entity}/statusMove a data entityPUT/v1/data-entities/{entity}/fieldsReplace a data entity's fieldsPOST/v1/data-entities/{entity}/revisions/{revision}/restoreRestore a version of a entityDecisions API
A decision is the record of a choice the project made: the context it was taken in, the options weighed with their pros and cons, what was decided, what follows, who decided and when, and the earlier decision it replaces. Read the overview.
/v1/decisions/{decision}Get a decisionPATCH/v1/decisions/{decision}Update a decisionDELETE/v1/decisions/{decision}Delete a decisionGET/v1/decisions/{decision}/revisionsList a decision's versionsGET/v1/decisions/{decision}/revisions/{revision}Get a version of a decisionGET/v1/projects/{project}/decisionsList decisionsPOST/v1/projects/{project}/decisionsAdd a decisionPOST/v1/decisions/{decision}/statusMove a decisionPOST/v1/decisions/{decision}/revisions/{revision}/restoreRestore a version of a decisionDesign References API
A design reference is a link a project keeps to one of its designs: a Figma file, a wireframe, a prototype, a screenshot, an API contract, a sequence diagram, an entity diagram or a document. Read the overview.
/v1/design-references/{reference}Get a design referencePATCH/v1/design-references/{reference}Update a design referenceDELETE/v1/design-references/{reference}Delete a design referenceGET/v1/projects/{project}/design-referencesList design referencesPOST/v1/projects/{project}/design-referencesAdd a design referenceEnvironments API
An environment is one named place a project's software runs, from a developer's machine to production: its kind, the component it runs (or the whole project), its addresses, the branch deployed there, the autodeploy and protected flags, the health the last check found, the version running there and whether a change freeze is in force. Read the overview.
/v1/environments/{environment}Get an environmentPATCH/v1/environments/{environment}Update an environmentDELETE/v1/environments/{environment}Delete an environmentGET/v1/projects/{project}/environmentsList environmentsPOST/v1/projects/{project}/environmentsCreate an environmentPOST/v1/environments/{environment}/freezeFreeze an environmentPOST/v1/environments/{environment}/unfreezeUnfreeze an environmentPOST/v1/environments/{environment}/healthRecord an environment's healthEpics API
An epic is a body of work the client recognises: the scope a release is cut from and the parent of every story. Read the overview.
/v1/epics/{epic}Get an epicPATCH/v1/epics/{epic}Update an epicDELETE/v1/epics/{epic}Delete an epicGET/v1/epics/{epic}/revisionsList an epic's versionsGET/v1/epics/{epic}/revisions/{revision}Get a version of an epicGET/v1/projects/{project}/epicsList epicsPOST/v1/projects/{project}/epicsAdd an epicPOST/v1/epics/{epic}/statusMove an epicPOST/v1/epics/{epic}/revisions/{revision}/restoreRestore a version of an epicGlossary API
A glossary term is a word the project agrees on. Read the overview.
/v1/glossary/{term}Get a glossary termPATCH/v1/glossary/{term}Update a glossary termDELETE/v1/glossary/{term}Delete a glossary termGET/v1/glossary/{term}/revisionsList a term's versionsGET/v1/glossary/{term}/revisions/{revision}Read one version of a termGET/v1/projects/{project}/glossaryList glossary termsPOST/v1/projects/{project}/glossaryAdd a glossary termPOST/v1/glossary/{term}/statusMove a glossary termPOST/v1/glossary/{term}/revisions/{revision}/restoreRestore a version of a termGroups API
A group is a named bundle of permissions on a team that several members hold at once: put the three people who run the on-call rota into an incident-commanders group and they share its permissions, take one out and they keep only what their own role gives them. Read the overview.
/v1/groupsList groupsPOST/v1/groupsCreate a groupGET/v1/groups/{group}Get a groupPATCH/v1/groups/{group}Update a groupDELETE/v1/groups/{group}Delete a groupPUT/v1/groups/{group}/membersReplace a group's membersImports API
A brief import hands a client's brief to Heimdall and gets back suggestions: the epics, stories, requirements, business rules, use cases, glossary terms, personas, stakeholders, risks, assumptions and decisions a good analyst would draft from it, each with how sure Heimdall was, why, and the passage of the brief it drew on, plus improvements, the gaps and questions a project of this kind leaves open. Read the overview.
/v1/projects/{project}/importsList a project's importsPOST/v1/projects/{project}/importsImport a briefGET/v1/imports/{batch}Get an importGET/v1/imports/{batch}/suggestionsList an import's suggestionsPOST/v1/imports/{batch}/discardDiscard an importPOST/v1/suggestions/{suggestion}/acceptAccept a suggestionPOST/v1/suggestions/{suggestion}/rejectReject a suggestionPOST/v1/suggestions/{suggestion}/mergeMerge a suggestionImprovements API
Improvements are Heimdall's standing suggestions on a project's own record: the gaps a good analyst fills before anyone builds. Read the overview.
Labels API
A label is a word a project pins on its work items: payments, tech-debt, client-asked. Read the overview.
/v1/projects/{project}/labelsList a project's labelsPOST/v1/projects/{project}/labelsAdd a labelPATCH/v1/labels/{label}Rewrite a labelDELETE/v1/labels/{label}Remove a labelLinks API
A link joins two artefacts of a project with a kind that says how the source relates to the target: a story implements a requirement, a test case verifies a rule, a bug is fixed by a story, a decision supersedes an older one. Read the overview.
/v1/projects/{project}/linksList an artefact's linksPOST/v1/projects/{project}/linksLink two artefactsDELETE/v1/links/{link}Unlink two artefactsMe API
GET /v1/me is the first call a client makes. Read the overview.
Notifications API
Every alert Zuse Bifrost sends a person (an approval waiting on them, an assignment, a mention, a failing test run, a release approved, an incident opened, a security notice, the Monday digest) also lands in the Notifications Center: the sidebar entry with its unread count and popover, and the page at /notifications. Read the overview.
/v1/me/notificationsList the caller's notificationsPOST/v1/me/notifications/read-allMark every notification readPOST/v1/me/notifications/{notification}/readMark a notification readPersonas API
A persona is an archetypal user the project is built for: a named, sketched person with goals, frustrations and habits, so the analyst, the developers and the testers picture the same someone. Read the overview.
/v1/personas/{persona}Get a personaPATCH/v1/personas/{persona}Update a personaDELETE/v1/personas/{persona}Delete a personaGET/v1/personas/{persona}/revisionsList a persona's versionsGET/v1/personas/{persona}/revisions/{revision}Read one version of a personaGET/v1/projects/{project}/personasList personasPOST/v1/projects/{project}/personasCreate a personaPOST/v1/personas/{persona}/archiveArchive a personaPOST/v1/personas/{persona}/restoreRestore a personaPOST/v1/personas/{persona}/revisions/{revision}/restoreRestore a version of a personaPing API
The one endpoint that needs no token. Read the overview.
Project Settings API
A project's settings are its per-project knobs: how long a sprint runs and on which days, which timezone its deadlines are read in, what work is sized in and on which scale, who a new item goes to, whether pull requests move items along and whether checklists gate a sprint or a done, whether a client guest may comment, whether Heimdall assists, where alerts go on Telegram, the board's limits and hidden columns, the business hours SLAs count and whether a production outage opens an incident. Read the overview.
/v1/projects/{project}/settingsGet a project's settingsPATCH/v1/projects/{project}/settingsUpdate a project's settingsProjects API
A project is one client engagement from discovery to maintenance: the container every component, environment, epic, story, requirement, test, release and incident lives under. Read the overview.
/v1/projectsList projectsPOST/v1/projectsCreate a projectGET/v1/projects/{project}Get a projectPATCH/v1/projects/{project}Update a projectDELETE/v1/projects/{project}Delete a projectPOST/v1/projects/{project}/archiveArchive a projectPOST/v1/projects/{project}/restoreRestore a projectRAID Log API
The RAID log is where a project writes down what may go wrong and what it leans on: risks (something that may happen and would hurt, scored by probability and impact, with a mitigation and a contingency), assumptions (something taken as true for the plan to hold, reviewed until it is confirmed or fails), issues (something that has happened and hurts now, scored by impact) and dependencies (something the project needs from outside itself). Read the overview.
/v1/projects/{project}/raid-itemsList RAID itemsPOST/v1/projects/{project}/raid-itemsAdd a RAID itemGET/v1/raid-items/{raidItem}Get a RAID itemPATCH/v1/raid-items/{raidItem}Update a RAID itemDELETE/v1/raid-items/{raidItem}Delete a RAID itemGET/v1/raid-items/{raidItem}/revisionsList a RAID item's versionsGET/v1/raid-items/{raidItem}/revisions/{revision}Get a version of a RAID itemPOST/v1/raid-items/{raidItem}/statusMove a RAID itemPOST/v1/raid-items/{raidItem}/revisions/{revision}/restoreRestore a version of a RAID itemRepositories API
A repository is a Git repository a project's code lives in: its provider, the account that owns it, its name, the branch releases are cut from, whether it is private and which component it builds. Read the overview.
/v1/repositories/{repository}Get a repositoryPATCH/v1/repositories/{repository}Update a repositoryDELETE/v1/repositories/{repository}Delete a repositoryGET/v1/projects/{project}/repositoriesList repositoriesPOST/v1/projects/{project}/repositoriesRegister a repositoryPOST/v1/repositories/{repository}/disconnectDisconnect a repositoryPOST/v1/repositories/{repository}/reconnectReconnect a repositoryRequirements API
A requirement is one sentence the client and the team agree the system must honour: a functional requirement says what it does for a person (CRM-FR-12), a non-functional one says a quality it keeps while it does it (CRM-NFR-3), with the category the quality belongs to and a measure with the metric and the target. Read the overview.
/v1/requirements/{requirement}Get a requirementPATCH/v1/requirements/{requirement}Update a requirementDELETE/v1/requirements/{requirement}Delete a requirementGET/v1/requirements/{requirement}/revisionsList a requirement's versionsGET/v1/requirements/{requirement}/revisions/{revision}Get a version of a requirementGET/v1/requirements/{requirement}/quality-reviewsList a requirement's quality reviewsPOST/v1/requirements/{requirement}/quality-reviewsReview a requirement's qualityGET/v1/projects/{project}/requirementsList requirementsPOST/v1/projects/{project}/requirementsAdd a requirementPOST/v1/requirements/{requirement}/statusMove a requirementPOST/v1/requirements/{requirement}/revisions/{revision}/restoreRestore a version of a requirementResearch API
Research is Heimdall reading the web for what a project's brief never states: what products of this kind commonly do, the laws, regulations and standards that apply in the client's country and industry, the integrations the client will expect, what the market already offers and the security and accessibility expectations the client will be held to. Read the overview.
/v1/projects/{project}/researchList a project's researchPOST/v1/projects/{project}/researchResearch a project's domainGET/v1/projects/{project}/suggestionsList a project's research suggestionsRoles API
A role is the permission set a member holds on a team. Read the overview.
/v1/rolesList rolesPOST/v1/rolesCreate a roleGET/v1/roles/{role}Get a rolePATCH/v1/roles/{role}Update a roleDELETE/v1/roles/{role}Delete a roleStakeholders API
A stakeholder is a person the project answers to: the client's sponsor and product owner, the people who sign off requirements, UAT runs and releases, Zuse's own account manager or architect, and third parties such as an auditor or a vendor. Read the overview.
/v1/projects/{project}/stakeholdersList stakeholdersPOST/v1/projects/{project}/stakeholdersAdd a stakeholderGET/v1/stakeholders/{stakeholder}Get a stakeholderPATCH/v1/stakeholders/{stakeholder}Update a stakeholderDELETE/v1/stakeholders/{stakeholder}Remove a stakeholderGET/v1/stakeholders/{stakeholder}/revisionsList a stakeholder's versionsGET/v1/stakeholders/{stakeholder}/revisions/{revision}Read one version of a stakeholderPOST/v1/stakeholders/{stakeholder}/revisions/{revision}/restoreRestore a version of a stakeholderTeam Members API
Team members are the people inside a team: the owner and everyone invited to work in it, staff and client guests alike. Read the overview.
/v1/teams/{team}/invitationsList a team's pending invitationsGET/v1/teams/{team}/membersList a team's membersPOST/v1/teams/{team}/membersInvite a team memberGET/v1/teams/{team}/members/{member}Get a team memberDELETE/v1/teams/{team}/members/{member}Remove a team memberPATCH/v1/teams/{team}/members/{member}/roleChange a team member's roleDELETE/v1/teams/{team}/invitations/{invitation}Withdraw an invitationTeams API
A team is the tenant: the container every project, role, group, token and webhook endpoint hangs off. Read the overview.
/v1/teamsList teamsPOST/v1/teamsCreate a teamGET/v1/teams/currentGet the current teamGET/v1/teams/{team}Get a teamPATCH/v1/teams/{team}Rename a teamDELETE/v1/teams/{team}Delete a teamTokens API
Personal access tokens are what authorise every REST and MCP call. Read the overview.
/v1/tokensList the caller's tokensPOST/v1/tokensMint a tokenGET/v1/tokens/{token}Get a tokenDELETE/v1/tokens/{token}Revoke a tokenUse Cases API
A use case is how an actor reaches a goal with the system, step by step: the persona who acts, the other actors in the room, the goal, what triggers it, what must be true before and after, how often it happens, and the steps (what the actor does and what the system does in reply) in a main flow with alternate and exception flows branching off numbered main steps. Read the overview.
/v1/projects/{project}/use-casesList use casesPOST/v1/projects/{project}/use-casesAdd a use caseGET/v1/use-cases/{useCase}Get a use casePATCH/v1/use-cases/{useCase}Update a use caseDELETE/v1/use-cases/{useCase}Delete a use caseGET/v1/use-cases/{useCase}/revisionsList a use case's versionsGET/v1/use-cases/{useCase}/revisions/{revision}Get a version of a use casePOST/v1/use-cases/{useCase}/statusMove a use casePUT/v1/use-cases/{useCase}/stepsReplace a use case's stepsPOST/v1/use-cases/{useCase}/revisions/{revision}/restoreRestore a version of a use caseWatchers API
A watcher is a person following one artefact: they are told of every comment posted on it. Read the overview.
/v1/projects/{project}/watchersList an artefact's followersPOST/v1/projects/{project}/watchersFollow an artefactDELETE/v1/watchers/{watcher}Stop followingWebhook Deliveries API
Every event Zuse Bifrost posts to one of your webhook endpoints is a delivery: one row per endpoint per event, carrying the signed envelope that was sent, the target's response and where the row is on the retry ladder. Read the overview.
/v1/webhook-deliveriesList webhook deliveriesGET/v1/webhook-deliveries/{delivery}Get a webhook deliveryPOST/v1/webhook-deliveries/retry-deadRetry every recent dead deliveryPOST/v1/webhook-deliveries/{delivery}/retryRetry a webhook deliveryWebhook Endpoints API
A webhook endpoint is a URL of yours that Zuse Bifrost posts events to, with the events it subscribes to and a signing secret you verify each delivery against. Read the overview.
/v1/webhook-endpointsList webhook endpointsPOST/v1/webhook-endpointsRegister a webhook endpointGET/v1/webhook-endpoints/{endpoint}Get a webhook endpointDELETE/v1/webhook-endpoints/{endpoint}Delete a webhook endpointPOST/v1/webhook-endpoints/{endpoint}/pausePause a webhook endpointPOST/v1/webhook-endpoints/{endpoint}/resumeResume a webhook endpointPOST/v1/webhook-endpoints/{endpoint}/rotate-secretRotate a webhook endpoint's secretPOST/v1/webhook-endpoints/{endpoint}/testTest-fire a webhook endpointWebhook Events API
A read-only polling endpoint that surfaces the most recent webhook deliveries for a given event type. Read the overview.
Work Items API
A work item is one row of the tracker: a story, a task, a sub-task, a bug, a spike or an improvement. Read the overview.
/v1/me/work-itemsList my work itemsGET/v1/projects/{project}/work-itemsList work itemsPOST/v1/projects/{project}/work-itemsAdd a work itemGET/v1/work-items/{item}Get a work itemPATCH/v1/work-items/{item}Update a work itemDELETE/v1/work-items/{item}Delete a work itemGET/v1/work-items/{item}/revisionsList a work item's versionsGET/v1/work-items/{item}/revisions/{revision}Get a version of a work itemGET/v1/work-items/{item}/quality-reviewsList a work item's quality reviewsPOST/v1/work-items/{item}/quality-reviewsReview a work item's qualityPOST/v1/work-items/{item}/statusMove a work itemPOST/v1/work-items/{item}/assignAssign a work itemPUT/v1/work-items/{item}/acceptance-criteriaReplace a work item's acceptance criteriaPOST/v1/work-items/{item}/revisions/{revision}/restoreRestore a version of a work itemHow is this guide?
Last updated on
Agent Readiness
The documents an agent reads to find Zuse Bifrost on its own: the API catalog, the MCP server card, the agent skills, the OAuth metadata, AGENTS.md and llms.txt, each built from the running application.
Activity API
Every mutation Zuse Bifrost performs, whether from the app, the REST API, an MCP tool call, an accepted Heimdall draft or a scheduled system task, is recorded against its subject in the activity log.