Authentication
Last verified: 2026-06-20 (Task #390 — User APIs documentation).
The Events API shares the end-user authentication model used by the
Trips & Itinerary and
Agent Runs APIs. There are no
tm_ developer keys here.
Two ways to authenticate
| Credential | How it's sent | Typical caller |
|---|---|---|
| Session cookie | Cookie: session_token=… | First-party web app |
| Bearer token | Authorization: Bearer <token> | Mobile app and browser extension |
A request with neither returns 401
({ "error": "Authentication required" }).
Authorization: membership vs. planner
Authorization is layered on top of authentication:
| Action | Requirement |
|---|---|
POST /v1/events (create) | Membership of every trip in attach.trip_ids. If any check fails, the whole request is rejected with 403. |
GET /v1/events/{id} (read) | Membership of at least one trip the event is attached to. |
PATCH /v1/events/{id} (update) | You are the event's planner (plannerUserId). |
DELETE /v1/events/{id} (delete) | You are the event's planner. |
The planner is the single user empowered to change or remove an event
globally across every trip it is linked to — typically the user who
created it. A member who is not the planner can read an event but cannot
update or delete it (403).
Using the Try It console
The interactive API reference ships a Try It console.
Authorize it with a bearer token (the console does not forward
cookies): click Authorize, paste your token, and the console sends
Authorization: Bearer <token> on each call.