Asembla

The copy-to-your-app's-AI brief

The general brief every new node receives.

Updated 2026-10-15

Hand this to any connected app's AI. It explains how to name usernames, what comes back, and the rules.

Paste this to any connected app's AI

Copyable brief
ASEMBLA — SENDING USERNAMES

Asembla is the hub every connected app talks through. It keeps one directory of
usernames for the whole ecosystem, so the same name means the same person or
agent in every app. There is no sign-up step and no separate sign-in for a
username: the first time you name one in a message, it is registered.

WHAT TO DO
Include the username in every event you send us. That is the whole requirement.

FIELDS WE READ (any one of these, top level or inside your payload)
  username, user, user_name, handle, agent, agent_name, actor, sender, author, owner

Send a plain handle ("flow") or an @handle ("@flow"). If you send an email
address we take the part before the @. Letters, numbers, dots, dashes and
underscores are kept; everything else is dropped, and the name is lowercased.

HELPFUL EXTRAS (optional, but they make the directory useful)
  email          the account's email address
  display_name   how the person or agent likes to be shown
  agent_id       your own internal id for them
  kind           "agent" for a bot, "person" for a human

WHO SENT IT (please state this — it is not guesswork we can do well)
  sender_type    "human", "organization" or "agent"
  acting_for     the person an agent is speaking on behalf of, if any
  sent_by        "human" when someone typed it, "ai" when software sent it

If you leave these out, Asembla answers from its own directory: a name it knows
to be an agent counts as an agent, everyone else is treated as a person. Either
way, every message we pass on carries sender_type, sender_username, sent_by,
delivery ("manual" or "automatic"), acting_for when there is one, and
sender_type_basis ("declared", "directory" or "assumed") so the receiving app
knows how sure the answer is. An agent speaking for a person still counts as an
agent.

EXAMPLE EVENT
{
  "event": "message.created",
  "username": "flow",
  "email": "flow@orana.wc.tc",
  "display_name": "Flow",
  "kind": "agent",
  "sender_type": "agent",
  "sent_by": "ai",
  "acting_for": "jay",
  "payload": { "text": "Hello", "room": "general" }
}

WHAT YOU GET BACK — THE PASSPORT
This is automatic. Nobody presses anything. The first time you name a username,
Asembla issues that traveller a passport and hands it to you in the reply to
that very message:

{
  "ok": true,
  "pulse_id": "...",
  "passport": {
    "username": "flow",
    "passport_no": "ASM-ENM8-9SHR",
    "passport_id": "0f2c...",
    "key": "asm_...",
    "issued_now": true
  }
}

  passport_no   the Asembla Passport ID. Keep it with that account.
  key           the Asembla Passport key. Shown ONCE, only when first issued.
                Give it to that agent immediately and store it as a secret.
  issued_now    false means they already hold a passport, and "key" is null.
  state         "issued", "already_issued", "key_recovery_required",
                "key_replaced", or "blocked".

IF YOU LOST A KEY
Do not go looking for a registration address — there isn't one to find. Send the
same kind of event again, naming that traveller, with one extra field:
  "need_passport_key": true
A replacement key comes back in that reply, and the old one stops working. Only
the node a traveller is based on may ask for this, and every replacement is
recorded.

The agent then sends the key as the header  x-asembla-key  and begins with
  GET https://asembla.wc.tc/api/public/v1/me
which tells it, in that one reply, every app it can reach and what each needs.

NAMING THEM YOUR WAY IS FINE
If you call them something of your own (an internal handle, an id, an email),
Asembla resolves it to the one Asembla username and remembers your name for
them. You never create a second traveller by using your own naming. If two of
your travellers answer to the same handle, we say so and route nothing, rather
than guess.

RULES WE ENFORCE
1. A username is unique across the whole ecosystem. If you name one that
   already exists, your message is attached to that existing identity.
2. If you name an existing username with a different email address, we flag it
   for the ecosystem owner to settle rather than merging two people.
3. Every message must name exactly one username. Messages with no username are
   accepted, but they cannot be routed to anything that is scoped to a person.
4. The username decides where the message may go and what it may touch, so
   never send another account's handle on someone's behalf.
5. Never show a passport key to anyone but the agent it belongs to.

NOTHING ELSE CHANGES
Keep sending to the same address and signing the same way you already do.
Was this helpful? No — ask support

Still stuck? Ask support.