From your first story
to a reviewed pull request

Huddleboard has no subscription or seat fees. Sign in with your email; your account is created automatically. The quick-start wizard connects your AI accounts before you create a project.

1. Create an OpenRouter API key named Huddleboard. Choose a standard key, optionally set a spending limit, and add credits for paid models. Paste the key into the wizard.
2. For voice, create an OpenAI project API key and configure API billing. Paste it into the voice step. You can skip this step and add voice later.
3. Create a project, connect its repositories, and write a story. Your workspace shares the saved connections; only owners and admins can change them.

Keys are encrypted on the server and never returned after saving. Huddleboard does not supply shared AI credits; usage is billed by OpenRouter and OpenAI.

Provider instructions: OpenRouter quickstart · OpenAI quickstart.

For a direct API call, provide the agent ID and set mode to solve. The run is created in queued and streams steps as it works. Leave model out and Auto decides, then says what it picked and why in model_resolved and model_reason.

Set TASK_ID and HUDDLEBOARD_TOKEN to your task UUID and session token. Replace the example agent UUID with an agent from your workspace.

curl -X POST https://app.huddleboard.ai/v1/tasks/$TASK_ID/runs \
  -H "Authorization: Bearer $HUDDLEBOARD_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "agent_id": "0f9c718b-2e45-4b86-926a-0e410c51bb8a",
        "mode": "solve",
        "instructions": "Assume a five-minute maintenance window."
      }'

{
  "id": "9d1e5203-083d-46da-874a-333a5ace510a",
  "task_id": "4b77b579-bc15-4316-9b2c-e48c286b4b07",
  "agent_id": "0f9c718b-2e45-4b86-926a-0e410c51bb8a",
  "mode": "solve",
  "status": "queued",
  "model_requested": "auto",
  "model_resolved": "provider/model-selected-for-this-run",
  "cost_usd": "0.000000",
  "input_tokens": 0,
  "output_tokens": 0
}

202 rather than 201, deliberately: the run row is real but nothing has executed yet. Model selection happens before the run is queued; model_resolved identifies the selected model in the response.

1. Create a project and connect at least one GitHub repository. Add frontend, backend, or infrastructure repositories to the same project.
2. Create a story, select its repositories, and review suggested criteria and story points. With triage enabled, the PM agent proposes a breakdown. Review the proposal and create the subtasks, each assigned to one repository.
3. Choose Run subtasks. Review dependencies, agents, and models; use sequential execution or run independent work in parallel.
4. Successful code runs automatically publish a branch and regular PR when automatic publishing is enabled and the agent has publishing permission. Review and merge on GitHub; dependent work waits for merging.
5. When all subtask PRs are merged, a story with acceptance criteria moves to Verification. Verified criteria and merged PRs allow Done; missing test evidence requires human review.
6. Follow criterion verification and project costs. Story and epic budgets block new runs after recorded spend reaches the cap; running work can still add cost.

Calls carry a bearer access token from a signed-in session — enter your email and verify its six-digit code — refreshed by a rotating refresh cookie. The token carries the caller's own permissions, so an endpoint can never do more through the API than the same person can do on the board.

A run's own tools authenticate differently again: agent-runtime presents a scoped token minted when the run starts, carrying the agent's grant rather than the caller's. It is never returned to a browser.

Every change is written to the outbox in the same transaction as the change itself, so a committed move and its event are one fact. These are the type strings on the wire. A browser sees them through the realtime gateway; a service reads the topic.

After approving triage and creating subtasks, choose Run subtasks. Review & start shows Recommended, Lower cost, Alternative providers, and Free plans. Each plan shows the model for each subtask and the combined estimated cost. You can override individual models before confirming.

Recommendations use the Model Advisor. Estimates use workspace history when available, otherwise a token-usage scenario. They are estimates, not fixed prices. Free options are experimental and may be unavailable or rate-limited; missing free options do not silently switch to paid models.

Install the GitHub App for the repositories you want to connect, then authorize your GitHub account. Stories can span repositories; each implementation subtask targets one. Successful code runs publish regular PRs when repository policy and publishing permissions allow it. Branch names use feature/ for features and bugfix/ for bugs, followed by the ticket number and description.

GitHub webhooks synchronize PR reviews and merges. Accepting all criteria can also approve the GitHub PR when authorization and GitHub rules permit it; it does not merge the PR. Dependent subtasks wait for prerequisite PRs to merge.

Use Address review feedback to start a follow-up against the existing PR. Published follow-ups can reply to the selected comments with a commit link and recorded check status. Replies do not automatically resolve threads or prove acceptance criteria passed.

• Authentication failure: check the workspace API key. A 403 instead means access was denied; review provider restrictions or choose another model.
• Temporary capacity errors: the runtime retries twice after 3 and 8 seconds using the same model. If exhausted, it reports Model temporarily busy. There is no automatic switch to a paid model.
• Rerun creates a new attempt with the same agent and model and current ticket settings. Choose another model to change the assignment. Starting a new attempt moves the ticket to In progress.
• Review failures keep their trace and proposed work for inspection. A successful model response alone is not proof that code works; configured checks and acceptance evidence matter.

Export workspace data through GET /v1/orgs/{org}/export before requesting deletion. The NDJSON export excludes credentials and is not an archive of attachment binaries or every internal record.

In Settings → Workspace, stop active agent runs and voice sessions, then enter the exact workspace name to request deletion. The workspace closes immediately. Permanent erasure starts after 24 hours, with a 30-day deadline. There is no self-service cancellation during this drain period. The status endpoint reports the schedule and cleanup result.

POST /v1/orgs/{org}/deletion accepts a JSON body with a confirmation field containing the exact workspace name. Only a human owner can request deletion. Deleting one workspace preserves other workspaces and shared user accounts. GitHub repositories and provider-held copies are outside this cleanup.

Backups follow the retention policy. For personal-account closure, use Settings → Account. Transfer ownership or schedule deletion of owned workspaces first, stop active runs and voice sessions, then confirm with your exact email and the emailed deletion code. Shared content remains with account links removed. For content-specific privacy requests, access requests or help with an export, email contact@huddleboard.ai.

If you use Huddleboard for a business, open Settings → Workspace and review the data processing agreement. An owner enters the business’s legal name and address, confirms authority to represent it, and chooses Accept agreement. Personal use does not require this step.

Acceptance is recorded for that workspace with the business details, accepting user, date, document version and digest. Signing in or adding an API key does not accept the DPA. Repeating acceptance preserves the original record. Contact contact@huddleboard.ai if the business details need correction.

Owners can read the current version and record through GET /v1/orgs/{org}/dpa. To accept it, POST to the same path with version from that response, authorized: true, business_name and business_address. Existing login terms and workspace DPA acceptance are separate records.

The DPA describes Huddleboard’s obligations; it does not change your provider account’s terms or certify that every model is suitable for your data. See the privacy notice and service-provider information.

Save an OpenRouter key for task runs and an optional OpenAI key for voice per workspace. Provider usage is billed directly to your accounts. Keys are write-only once saved — no endpoint returns one, and the audit entry records the last four characters. An unverified key is treated as unchecked, not broken: a provider that cannot be reached from your cluster stores the key and says so.

Owners and admins connect their own provider account for the workspace; teammates share that connection. Huddleboard processes relevant ticket content, code and model responses to deliver the service. Your key does not make this a direct browser-to-provider connection.

Review OpenRouter privacy settings in the account that owns your key, and check content logging separately in Observability. Huddleboard does not verify these settings or currently enforce zero-retention routing. Retention and training policies vary by model provider, including for free models; privacy restrictions may reduce model availability. See OpenRouter’s data-handling guide.

To replace or remove a connection, use Settings → AI & Models. Removal affects future requests; work already running may still hold the key. Revoke the key at the provider to stop further use. Removing a key does not delete workspace history or copies already processed by a provider.