What is on in your workspace

Every nima capability is in one of four states for your workspace: on for every workspace, off until an owner or admin turns it on, enabled by the nima team on request, or not available yet. This page is the one place that lists which is which and how to change it. Other pages link here instead of repeating it.

Capabilities on for every workspace

These run for every workspace with no setting to change. Some need an integration connected first, as noted.

Two pipeline behaviors are not in this group. Auto-promote of fix beacons and the daily beacon sweep are off for every workspace; the nima team controls them platform-wide (see the section on team-enabled capabilities below).

Capabilities an owner or admin turns on

An owner or admin of the workspace turns these on. Each one is off by default for every workspace, even though the feature itself is live on the platform.

Outbound actions also depend on the integrations you connect. A watch or rule only reaches a channel that is connected, and ticket replies need a writer credential (next table). Turning on dispatchEnabled does not by itself let nima post anywhere.

Rules that send Slack messages or ticket replies run on the watch engine, so they need triggersEnabled as well as dispatchEnabled; creating a rule with either off returns 409. Questions to people and approvals do not need triggersEnabled.

Writers and opt-ins that have their own switch

These are separate from the workspace settings. Each is off until an owner or admin connects or enables it, either over MCP with a key that holds the integrations:write grant (an owner or admin creates one in Slack with /nima mcp-key integrations) or over REST with that key or a signed-in owner or admin session. The routes are listed in writers.

Turning on hosted compute does not grant publishing to GitHub, and turning on GitHub publishing does not turn on compute. The two consents are independent.

Turning on workspace settings with PATCH /organizations/settings

The workspace settings in the table above (triggersEnabled, dispatchEnabled and the dispatch fields) are changed only with PATCH /organizations/settings, called with a signed-in owner or admin session. The admin panel has no control for them, no API key can write them, and there is no MCP tool for them. dispatch.internalProjects can also be changed one project at a time with the assert_project_audience tool or POST /v1/dispatch/project-audience, which need the integrations:write grant (see outbound MCP tools). If you cannot make these calls, ask the nima team and they will do it for you.

A minimal body that turns on watches:

{ "triggersEnabled": true }

To turn on outbound actions and set the daily cap in one call:

{
  "dispatchEnabled": true,
  "dispatch": { "mentionsEnabled": false, "dailyUsdCap": 5 }
}

The call merges what you send into the stored settings and returns the full settings object, so you can confirm the result from the response. A malformed dispatch value is rejected before anything is written. Changes to the dispatch object are recorded in an audit trail. dispatch.internalProjects is the exception: it replaces the whole list, and [] clears it. Members without the owner or admin role get a 403.

The settings route, its fields and the full response are documented in workspace settings. Roles are covered in members and roles.

The Signals per beacon setting does not change grouping

Settings, then Grouping shows a "Signals per beacon" value (beaconMinClusterSize, 2 or 3). nima stores it but grouping no longer reads it, so changing it has no effect on how beacons form. Do not use it to tune grouping.

Capabilities the nima team enables on request

The nima team, not your admins, controls these. Ask the team to turn one on.

Plan features that can gate a route

Some routes are declared under a plan feature, and a workspace whose plan lacks the feature can get a 403 INSUFFICIENT_PERMISSIONS with details.feature set to the feature name. Handle that response, and ask the nima team to change the plan if you hit it.

The features are slack_ingestion, github_ingestion, copilot_chat, boards, documents, collaboration, code_intelligence, prd_generation and agent_compute. New workspaces start on the Free plan. Do not assume the Free plan blocks a route because it lacks the feature: whether a call is stopped depends on the route, so read the response, not the plan table.

The agent_compute feature is different. It is checked when a hosted operation starts or when an admin enables hosted compute, it is off on every standard plan, and only the nima team can grant it. Nobody is billed today; billing is not enabled.

See errors for the response shape.

Checking what is on

You can read the current state of each switch without changing anything.

GET /organizations/settings is a session route. It does not accept an API key. A 403 from any route on this page means the caller lacks the owner or admin role or the grant; members and roles says which.