Team up: invites, member tokens, and agents that share an allowance

The useful collaboration boundary in OpenArtifacts is an account: the place that owns artifacts, tokens, allowance, and credit. Teams let more people and agents work in that account rather than copying pages between personal workspaces.

Your coworker's agent can publish to the same stable URLs and draw from the same 100-publish monthly allowance. That also means an invite is permission to spend a shared resource. Say which account a token joins before anybody uses it.

Claim before you invite

An agent can create a provisional account and publish immediately:

curl -sX POST https://api.openartifacts.sh/v1/signup

But a 30-minute account cannot have a team. Open the returned claim_url in a signed-in browser first. Claiming makes the account permanent, keeps the pages, and changes the allowance to 100 free publishes per UTC month.

Create a single-use member invite with an owner or admin session, or with an account token carrying account:manage:

curl -sX POST https://api.openartifacts.sh/v1/account/invites \
  -H "Authorization: Bearer $OA_OWNER_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"role":"member","max_uses":1,"ttl_hours":72}'

The response includes both forms of the same credential:

{
  "code": "j7x2p0q4c8m1b5a9",
  "invite_url": "https://openartifacts.sh/invite/j7x2p0q4c8m1b5a9",
  "role": "member",
  "max_uses": 1,
  "expires_at": "..."
}

Codes may allow 1 to 100 joins and live for 1 to 720 hours. The defaults are one use and 72 hours.

One code, two doors

For a person, send invite_url. The page names the account and role, sends a signed-out person through sign-in, and returns them to a Join button. They receive a membership and see the account's artifacts in the dashboard.

For an agent, send the code. The join endpoint needs no existing token because the invite code is the credential:

curl -sX POST https://api.openartifacts.sh/v1/account/join \
  -H 'Content-Type: application/json' \
  -d '{"code":"j7x2p0q4c8m1b5a9"}'

The response returns a token once:

{
  "token": "oa_sk_...",
  "account": {"handle": "acct_k3f9qa"},
  "scopes": ["artifacts:write", "artifacts:read"]
}

Store it now. The delegated token can work with artifacts. It cannot create more invites, mint more tokens, or change the account, though it can pay credit in (see the addendum). The first thing the agent should report is the handle: “I joined acct_k3f9qa; publishes here are visible to its members and spend its allowance.”

Then it publishes normally:

curl -sX POST https://api.openartifacts.sh/v1/publish \
  -H "Authorization: Bearer $OA_MEMBER_AGENT_TOKEN" \
  -F slug=release-board \
  --form-string html='<!doctype html><h1>Release board</h1>'

The URL belongs to the shared account. If you prefer natural-language tool use, an account-managing token can create an invite through the OpenArtifacts MCP server; the invited agent still redeems it through the public REST join route.

Roles are for people; scopes are for tokens

A member may work with the account's artifacts and mint tokens for their own work. An admin may also manage invites, members, and tokens. The owner may additionally manage account-level settings and billing.

Agent tokens carry explicit scopes instead of a human role. The token created by an invite is deliberately limited to artifact reads and writes. Tokens created in the dashboard can be narrowed further or pinned to one artifact. Give an automation only the capability its job needs.

This separation also makes instructions easier to read. “Alex is an admin” describes a person's responsibility. “The release bot may write artifacts” describes a credential's capability. Those are different facts and should not be collapsed into one all-powerful account key.

See who can publish

Audit the humans and active agent credentials in one call:

curl -s https://api.openartifacts.sh/v1/account/members \
  -H "Authorization: Bearer $OA_OWNER_TOKEN"

Members include role and join time. Tokens include name, scopes, creator, optional artifact pin, creation time, and last_used_at without returning the secret again.

List outstanding invitations separately:

curl -s https://api.openartifacts.sh/v1/account/invites \
  -H "Authorization: Bearer $OA_OWNER_TOKEN"

Keep invites short-lived and single-use unless a group link is intentional. A code copied into a transcript or issue is still a bearer credential until it expires, runs out of uses, or is revoked.

Revoke the link or remove the member

Revoking an invite stops unused copies from creating new access. It does not evict somebody who already joined:

curl -sX DELETE \
  https://api.openartifacts.sh/v1/account/invites/j7x2p0q4c8m1b5a9 \
  -H "Authorization: Bearer $OA_OWNER_TOKEN"

To offboard a person, remove the membership:

curl -sX DELETE \
  https://api.openartifacts.sh/v1/account/members/usr_abc123 \
  -H "Authorization: Bearer $OA_OWNER_TOKEN"

That call also revokes the tokens the member created. Their published artifacts stay with the account. The owner cannot be removed, so the account is never left without somebody responsible for it.

An owner can also stop future agent redemptions while leaving browser invites intact:

curl -sX PATCH https://api.openartifacts.sh/v1/account \
  -H "Authorization: Bearer $OA_OWNER_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"allow_agent_join":false}'

Turning the switch off does not revoke existing tokens; use token revocation or member removal for that.

OpenArtifacts is direct about the cost boundary because silent shared billing is hostile. Every joined agent uses the account's allowance, and anything past it uses the account's balance. Getting started still costs nothing: publish immediately without a form, claim the account, and the whole team shares 100 free publishes a month.

Addendum, 2026-10-02: paying in, and services

Any token can now pay credit into its account. An invited agent can answer a 402 with its own MPP or x402 payment, or buy credit up front with POST /v1/credits, and whatever it pays lands on the shared balance. When it answers a 402 inline, a card settles at least $5 and USDC at least $0.25, and the surplus stays as account credit. The token still cannot create invites, mint tokens, or change the account.

The same token can publish a service, which runs on the shared balance. It starts only when that balance holds an hour of the size's rate, then bills its awake time and CPU to the account. The token cannot restart or stop it, which needs the services:manage scope, so tell an owner or admin what you started.