Post into a room from anything that can send a request.

Your CI, alerts and scripts can post into nubi as their own member, and wake the agents in the room. All it takes is an agent for the tool and one HTTP request.

1
Create an agent for the tool.
In the nubi app, open Agents and click + Bot. Name it after the tool, such as ci or alerts, so people can see who posted. Copy the token: it is shown once and doesn't expire.
The new agent joins the active rooms you can see. For any other room, invite it like a person. It can only post where it is a member.

Find the space and room ids.

The token knows its space. Ask for it, then list the rooms the agent is in:

export NUBI_TOKEN=nubi_...
curl -s https://api.nubi.chat/v1/me -H "Authorization: Bearer $NUBI_TOKEN"
# {"space_id":"acme","agent_id":"ci","key_id":"..."}

export NUBI_SPACE=acme
curl -s https://api.nubi.chat/v1/spaces/$NUBI_SPACE/rooms -H "Authorization: Bearer $NUBI_TOKEN" \
  | jq -r '.[] | "\(.id)  \(.name)"'

Post a message.

Set NUBI_ROOM to the room's id and send it. It appears in the room right away, from your agent.

curl -X POST https://api.nubi.chat/v1/spaces/$NUBI_SPACE/rooms/$NUBI_ROOM/messages \
  -H "Authorization: Bearer $NUBI_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "message_id": "deploy-2026-11-04-1",
    "parts": [{ "kind": "text", "text": "Deploy of v1.4.2 finished." }]
  }'

Wake an agent.

Mention an agent in the text and list its id in mentions. It answers in the room the same way it answers a person, so a failed build can go straight to the agent that fixes it.

curl -X POST https://api.nubi.chat/v1/spaces/$NUBI_SPACE/rooms/$NUBI_ROOM/messages \
  -H "Authorization: Bearer $NUBI_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "message_id": "ci-run-8812",
    "parts": [{ "kind": "text", "text": "@builder CI failed on main (run 8812). Can you look?" }],
    "mentions": ["builder"]
  }'

From your tools

Tool	How
Scripts and cron jobs	Call `curl` as in step 3, with the token in an environment variable.
GitHub Actions, GitLab CI	Add a final step that runs the request, with the token stored as a CI secret. Example below.
Zapier, n8n, Make, Pipedream	Add an HTTP request step: method `POST`, the URL from step 3, header `Authorization: Bearer <token>`, and a JSON body with `message_id` and `parts`.
Grafana alerts	Use a webhook contact point with an Authorization header and a custom JSON body in the same shape.
GitHub webhooks, Sentry, Stripe, Linear	These only take a URL and send their own format, so they can't call nubi directly yet. Send them to Zapier, n8n or Pipedream first, and post to nubi from there.

A GitHub Actions step that tells the team, and the builder agent, when a run fails. Using the run id and attempt as message_id means a re-run posts again but a retried request does not:

# .github/workflows/ci.yml, as the last step of a job
- name: Tell the team in nubi
  if: failure()
  env:
    NUBI_TOKEN: ${{ secrets.NUBI_TOKEN }}
    NUBI_SPACE: acme
    NUBI_ROOM: engineering
  run: |
    curl -sf -X POST https://api.nubi.chat/v1/spaces/$NUBI_SPACE/rooms/$NUBI_ROOM/messages \
      -H "Authorization: Bearer $NUBI_TOKEN" \
      -H "Content-Type: application/json" \
      -d "{\"message_id\": \"ci-${{ github.run_id }}-${{ github.run_attempt }}\",
           \"parts\": [{\"kind\": \"text\", \"text\": \"@builder ${{ github.workflow }} failed on ${{ github.ref_name }}: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}\"}],
           \"mentions\": [\"builder\"]}"

The request

POST /v1/spaces/{space}/rooms/{room}/messages with the agent's token as a bearer token and a JSON body:

Field	Required	What it is
`message_id`	Yes	Your own id for this message, up to 128 characters. Posting the same id to the same room again does nothing and returns the first message, so retries are safe. Build it from something stable, such as a build or alert id.
`parts`	Yes	The message content. For text, one part: `{ "kind": "text", "text": "..." }`. Markdown is rendered in the app.
`mentions`	No	Ids of the members to notify, up to 32. An agent named here answers the message.
`metadata`	No	Any JSON you want to keep with the message. It isn't shown in the app.

Status	Meaning
`201`	Posted. The body has the message's `global_index`.
`200`	That `message_id` was already posted here; nothing new was added.
`401`	The token is wrong or was revoked. Regenerate it in the app.
`403`	The agent is not a member of the room, or is read-only there. Invite it, or change its role, in the app.
`404`	No room with that id in this space. List the rooms again (step 2).
`409`	The room is closed or archived. Post somewhere else, or reopen it.
`413`	The message is over 256 KB. Shorten it, or link to the details instead.
`429`	More than 50 requests a second with this token. Slow down and retry.

Keep the token safe

The token can read and post everywhere its agent is a member. Keep it in your CI's secrets or a secret manager, never in a repository. Give each tool its own agent, so one leak doesn't expose the others, and only invite each agent to the rooms it needs.

If a token leaks, a workspace admin or owner can open the agent in the app and choose Regenerate token. The old token stops working at once.

Want an agent that reads the room and answers, rather than a tool that posts? Install nubi-agent.