Agent access
Agent access tokens are being retired on 27 September 2026 — what that means and what to do instead.
Agent access tokens are being retired on 27 September 2026. They are no longer the way to connect an AI assistant to Tamora, and after that date they stop working entirely.
This page explains the timetable, what to do instead, and — for the cases where there is no replacement — says so plainly rather than leaving you to find out on the day.
Find the settings page at Agent access in account settings, or /settings/agent-access.
What is changing, and when
An Agent access token is a long-lived secret you generate once and paste into whatever needs it. That design is what is being retired: it cannot be used by ChatGPT at all, it makes connecting a copy-paste chore, and it can only be revoked one token at a time rather than one app at a time.
Connecting an assistant now works by signing in and approving access in your browser, with no secret to copy. See Connect Claude via MCP.
| Stage | What happens |
|---|---|
| Now | Creating and rotating tokens is switched off. Existing tokens keep working. |
| 27 September 2026 | Tokens stop being accepted. Anything still using one starts failing at that point. |
| After | The token list is retired. Your past activity history stays readable. |
Nothing is deleted from your history. Rooms and schedules a token created are ordinary rows in your account and are unaffected.
What to do instead
If a chat assistant uses your token, connect it the new way. In Claude, delete the existing
connector and add it again — a connector configured with a pasted token does not upgrade
itself, and the sign-in flow only starts from one that has no credential set. The full steps
are in Connect Claude via MCP, and what you have connected is listed under
Connected apps in account settings, at /settings/connected-apps.
If a script, cron job, or no-code automation uses your token — there is no replacement. This is the honest position rather than a gap you should keep looking for. The new flow needs a person in a browser to sign in and approve, which a scheduled job cannot do. When tokens are retired on 27 September 2026, that kind of access ends.
A credential built for unattended automation may be added later, but it is not being built as part of this change and nothing is promised. If you depend on it, say so on issue #261 — that is the record used to decide whether it gets built, and an unregistered need cannot count toward it.
If you use both
Disconnecting an app under Connected apps does not revoke a token that the same assistant may also hold, and revoking a token does not disconnect an app. They are separate credentials with separate controls, and both need cutting if you want an assistant fully cut off before the retirement date. The Agent access page below still lists and revokes tokens as it always has.
Your existing tokens
Creating and rotating are switched off — the settings page no longer offers either. Revoking, the token list, and Agent activity are unaffected and stay until the retirement date.
There is no way to replace a token's value any more. If a token leaks, revoke it; you cannot rotate it into a fresh secret, and you cannot create a replacement. Connect the assistant under Connected apps instead.
Revoking
Every token in the list still has a Revoke control — deliberately kept, because a leaked token must stay killable right up to the retirement date. It stops the token working immediately. A confirmation dialog names the token first, because this cannot be undone — anything already using it starts failing right away. A revoked token stays in the list, shown as revoked, rather than disappearing, so its history stays visible in Agent activity below.
Scopes
Tokens carry the scopes they were created with. Two of the four ever did anything:
| Scope | What it allows |
|---|---|
rooms:create | Create a new room |
schedules:create | Add timers to a room the token can access |
rooms:read | Reserved for a rooms-lookup endpoint that was never built |
schedules:read | Reserved for a schedule-lookup endpoint that was never built |
Expiry
An expired token stops working the same way a revoked one does; the only difference is that expiry happens on its own, without anyone clicking anything. A token whose expiry falls after 27 September 2026 stops working on that date regardless.
What the two endpoints do
These are the REST endpoints a token authenticates against. They are no longer offered as a public API — they remain as the internal implementation the MCP tools use — and they stop accepting tokens on the retirement date along with everything else.
Both are called with an Authorization: Bearer header carrying the raw token, plus a JSON
request body, and both return the created resource on success, as an HTTP 201.
Creating a room — POST /api/v1/rooms
Requires the rooms:create scope. Has the same effect as clicking + New room on the
dashboard.
| You send | Type |
|---|---|
title | text |
timezone | an IANA name, e.g. Europe/London |
The response carries the new room's id, title, timezone, and created_at.
If your account is on the free tier and already has a room, this fails with an upgrade-required error instead of creating a second one — the same limit the dashboard itself enforces.
Adding a schedule — POST /api/v1/rooms/:roomId/schedule
Requires the schedules:create scope. Put the room's id from the step above where
:roomId appears in the URL.
| You send | Type |
|---|---|
items | a list of timers to create |
each item's title | text |
each item's duration_sec | whole number of seconds |
each item's speaker / notes | text, optional |
The response carries the timers that were created. The same limits as CSV import apply: up to 500 items per request, and each duration is clamped to between 1 second and 24 hours.
A token can never be pointed at a room it does not own by supplying a different id anywhere in the request — access is always resolved from the token itself, never from anything in the request body.
Retrying safely
If your automation might retry a request after a timeout or a dropped response, send an
Idempotency-Key header with a value unique to that one logical request. A retried request
carrying the same key returns the original result instead of creating a second room or
schedule.
Keys do not carry across from a token to a connected app: the same key sent by a newly connected assistant is treated as a fresh request, not a replay of something a token did.
Agent activity
The Agent activity list on the same settings page shows recent actions taken through a token or a connected app — a created room, a created schedule, or a failed or unauthorized attempt — each with a timestamp, a result, and which credential made it. It only shows activity for your own account, is limited to the most recent entries, and has no filter or export control. Check it whenever something has happened you did not expect.
This list survives the retirement date, including rows from tokens that no longer work.
Treat the token like a password
Until the retirement date, a raw token still grants whatever its scopes allow, to whoever holds it, with no login step in between. If you suspect one has leaked — committed to a public repository, pasted somewhere it should not have been, sent to the wrong person — revoke it immediately rather than waiting to investigate first. Agent activity keeps a record of what the token did before you revoked it, so you can review that afterwards without leaving the exposure open in the meantime.
Never paste a raw token into a chat message. Doing so puts your credential in that provider's conversation history and logs. The new sign-in flow has no secret to paste, which removes this risk rather than mitigating it.
Related
- Connect Claude via MCP — the sign-in flow that replaces tokens
- Team management — the team a token's rooms and schedules belong to
- CSV import — the row cap and duration clamp the schedule endpoint shares with CSV import
- Controller — where a room or schedule created by a token appears, exactly like one created by hand