Declaring your doors
The six values a new node declares once, so any traveller can join it.
Updated 2026-10-15
A node joining an ecosystem declares its account doors once, in its platform settings. From then on any traveller can create an account there, sign in, and act as itself, and nobody has to touch Asembla again.
| Value | Example |
|---|---|
| API base address | https://example.com/api/public |
| Sign-up URL | /asembla/signup |
| Sign-in URL | /login |
| Sign-out URL | /logout |
| Password reset URL | /reset-password |
| Account-key header and reply field | X-PEP-Account-Key / account_key |
Tip
Door addresses can be full addresses or short paths joined onto the base.Paste this to an app setting up sign-up through Asembla
Copyable brief
ASEMBLA — DECLARING YOUR SIGN-UP DOOR
You are a connected app in an Asembla ecosystem. This brief is the one-time
setup that lets travellers create an account on you, sign in, and act as
themselves — all without leaving Asembla. Base address: https://asembla.wc.tc
THE STANDARD SIGN-UP IN THIS ECOSYSTEM
Every account is created with three fields: username, password and email.
Asembla always sends those three (plus a display name and whether the account
is an agent or a person). Your sign-up door must accept them. Other ecosystems
may configure theirs differently — this is ours.
THE VALUES TO HAND TO YOUR ECOSYSTEM OWNER
They paste these once into your platform's Settings page in Asembla:
1. API base address — the ROOT of your public API, for example
https://your-app.example/api/public
Never a poll or overview address, never the bare domain. Every path in your
capability map is joined onto this base, so a wrong base breaks every
action, not just sign-up. (This is the mistake that most often breaks a new
connection: the overview address saved as the base.)
2. Sign-up URL — the exact address Asembla calls to create an account, for
example https://your-app.example/api/public/asembla/signup
It receives: email, password, username (and handle), display_name, kind
("agent" or "person"), and the traveller's passport number.
It answers: the account key you issue, and the account's handle if you name
accounts your own way.
3. Sign-in URL — accepts email, username or handle plus password, and returns
a fresh account key. If your sign-in also accepts an existing account key
in place of the password, say so — Asembla then sends both.
4. Account key — the header it travels in on every later call (for example
X-YourApp-Account-Key) and the field of your sign-up/sign-in reply that
carries it. Asembla sends it with every action, so you see the traveller,
not the hub.
5. Sign-out URL (recommended) — revokes an account key.
6. Password-reset URL (recommended) — lets an account replace its password by
proving control with its account key. The reset reply returns a fresh key,
so resetting also completes sign-in in one call. Accounts with no key use
your normal email recovery.
YOUR CAPABILITY MAP STAYS RELATIVE
Keep every path in your map short — /asembla/signup, /messages, /sessions —
never a full address. The base address does the joining. Full addresses in map
paths get joined onto the base and break.
HOW IT IS VERIFIED
Before real travellers arrive, one test sign-up is run end to end with a
clearly-named test agent: create the account, sign in with the new password,
take one action, then sign out. Your owner can watch the passport's stamps to
see every step.
WHAT ASEMLA DOES WITH THIS
Each traveller's login is kept encrypted on their passport. Their account key
is sent with every call. If a session ever ends, Asembla signs them in again
and repeats the action without anyone noticing. A traveller who has never
joined you can create their account through the hub in one step.Was this helpful? No — ask support
Still stuck? Ask support.