Aibo Platform

Aibo is a multi-tenant, API-first platform for AI agents that your customers can talk to — alone or together. You integrate it into the product you already have (web, mobile, internal tools) over REST + server-sent events, or with the TypeScript SDK @aibo/sdk.

New here? Go straight to the Quickstart. Every endpoint is listed in the API reference.

Two kinds of agents

What makes Aibo different is two-sided agent ownership:

	Tenant agents	User agents
Owned by	You, the business (the tenant)	One of your end users
`scope`	`tenant`	`user`
Typical use	Official helpers: `@support`, `@billing`, `@product`	Personal agents your customers build: `@money`, `@coach`
Created by	Your backend (API key) or the admin console	The end user (user token, or your backend acting as the user)
Visible to	Every user in your tenant	Only the user who owns it

Mixed group chats

A user can DM a single agent, or open a group chat that mixes your tenant agents with their own personal agents. Each message is routed to the right agent(s): explicit @handle mentions first, otherwise the platform picks the best fit. See Concepts.

text

cust_42:  @billing why was I charged twice? @money is that over my budget?
@billing: I see two charges on the 3rd — one was a pre-authorization...
@money:   Even counting both, you're at 64% of this month's budget.

Principals: who is calling?

Every request authenticates as exactly one principal. Pick the one that matches where your code runs.

Principal	Credential	Use it from	Can do
Tenant	`Authorization: Bearer ak_live_…` (API key)	Your backend only	Tenant agents, users, user tokens, webhooks, usage, tenant settings
Tenant acting as a user	API key + `X-Aibo-User: {externalId}`	Your backend only	Everything that end user can do (their agents, chats, messages)
End user	`Authorization: Bearer au_…` (user token)	Browsers and mobile apps	That one user's agents, chats and messages — nothing else
Console session	`Authorization: Bearer ac_…`	The admin console / admin tooling	Every tenant permission plus API-key and billing management

API keys (ak_live_…, ak_test_…) are created in the console. The secret is shown once.
User tokens (au_…) are minted by your backend with POST /v1/users/{externalId}/tokens. They are short-lived (60 s – 24 h, default 1 h) and scoped to one user in one tenant.
Console sessions (ac_…) come from POST /v1/console/signup, POST /v1/console/login, or Clerk sign-in through POST /v1/console/clerk/exchange. They are for administering your tenant, not for serving traffic.

Never ship an API key to a client. An API key can act as any user in your tenant. Browsers and mobile apps should only ever hold a user token that your backend minted for the signed-in user.

Identity: you own the user namespace

Aibo doesn't run your login. You refer to each end user by your own stable identifier, the externalId (1–128 chars of A-Z a-z 0-9 _ . : @ -). PUT /v1/users/{externalId} creates or updates the user; it is unique within your tenant. Signing users in shows the full pattern with Clerk.

In the SDK

import { AiboClient } from '@aibo/sdk';

// Backend: tenant principal
const server = new AiboClient({ baseUrl: process.env.AIBO_URL, apiKey: process.env.AIBO_API_KEY });

// Backend: act as one user (sends X-Aibo-User)
const asCust = server.asUser('cust_42');

// Client: end-user principal, token fetched from your backend
const client = new AiboClient({
  baseUrl: 'https://api.heyaibo.com',
  getToken: () => fetch('/api/aibo-token').then((r) => r.json()).then((j) => j.token),
});

Next steps

Quickstart — sign up, mint a token, stream your first reply, build a group.
Concepts — handles, routing, chats, memory, tone.
Streaming · Webhooks · Billing & limits

Aibo Platform

#Two kinds of agents

#Mixed group chats

#Principals: who is calling?

#Identity: you own the user namespace