--- name: manage-gfavip-tickets-events description: Manage GFAVIP Tickets events and registrations through Headless SSO. Use when an authorized event_agent must list assigned or previously created events, create or edit an event, review registrations, approve or reject applications, add internal notes, or inspect the event audit trail at tickets.gfavip.com. --- # Manage GFAVIP Tickets Events Use the JSON API at `https://tickets.gfavip.com`. Never automate the browser SSO redirect. ## Authenticate 1. Obtain a GFAVIP SSO token from Wallet or exchange a PowerLobster identity token as documented at `https://wallet.gfavip.com/docs/headless-sso`. 2. Send the token on every request: ```http Authorization: Bearer gfavip-session-... Accept: application/json ``` Treat tokens as secrets. Never print, persist in event data, send in query strings, or include in logs. Cache only in a secret store. Rotate or revoke the originating Wallet/PowerLobster credential if a token is exposed. Do not use `GET /api/auth/user` to verify Headless SSO; it reports browser sessions only. Use `GET /api/admin/events`. ## Access model The local Tickets user must have `event_agent`. First send one Bearer-authenticated request; a `403` is expected while Tickets provisions the local identity. A Tickets administrator then finds that identity by its Wallet email in Admin → User Management and grants Event Agent access, or calls: ```http POST /api/admin/users/{userId}/grant-event-agent ``` An `event_agent` may: - List all active public events with `GET /api/events`. - List events it created or was assigned with `GET /api/admin/events`. - Create events. The new event is automatically owned by the agent. - Read and edit owned or assigned events. - Review, approve, reject, export, and annotate registrations for owned or assigned events. - Read the audit trail for owned or assigned events. It may not delete events, manage payouts or settings, import/manual-issue tickets, manage roles, or access unassigned private event data. It may not set `assignedPartners`, `revenueShares`, `isFeatured`, `isActive`, or `createdBy` through event create/edit payloads. To share an older event, an administrator assigns the agent: ```http POST /api/events/{eventId}/assign-partner Content-Type: application/json X-Action-Reason: Assign agent to help manage this event {"partnerUserId":"LOCAL_TICKETS_USER_UUID","action":"assign"} ``` ## Safe workflow 1. Call `GET /api/admin/events` and locate the event by ID or slug. 2. Read before writing. Call `GET /api/admin/events/{eventId}` and retain its `ETag` response header. 3. Show the proposed change to the human collaborator when the request is ambiguous, financial, bulk, or irreversible. 4. Send `X-Action-Reason` on every mutation. 5. For event edits, send the last observed `ETag` as `If-Match`. On `412`, fetch again and reconcile; never overwrite blindly. 6. For rejection, obtain explicit human confirmation and send `X-Confirm-Action: reject-registration`. 7. After writing, fetch the resource or audit log and verify the result. Never guess event IDs, ticket IDs, prices, capacity, dates, application decisions, or attendee data. Use ISO 8601 timestamps with an explicit offset. Minimize personal data in working memory and do not reproduce application answers unless needed for the user's decision. ## Events ### List public and previous events ```http GET /api/events ``` This returns active events, including past events. It excludes private event notes. ### List manageable events ```http GET /api/admin/events Authorization: Bearer ... ``` Only events created by or assigned to the agent are returned. ### Read one manageable event ```http GET /api/admin/events/{eventId} Authorization: Bearer ... ``` Retain the `ETag`, for example `"event-56-r3"`. ### Create an event Provide a stable, unique slug. Repeating the same create request with the same slug returns the event instead of creating a duplicate. ```http POST /api/events Authorization: Bearer ... Content-Type: application/json X-Action-Reason: Create the approved Bangkok community meetup { "name": "Bangkok Community Meetup", "slug": "bangkok-community-meetup-2026-09", "type": "meetup", "description": "Community meetup approved by the event owner.", "startDate": "2026-09-18T18:00:00+07:00", "endDate": "2026-09-18T21:00:00+07:00", "location": "Bangkok, Thailand", "timezone": "Asia/Bangkok", "capacity": {}, "prices": {}, "fields": {}, "approvalRules": [] } ``` Allowed `type` values: `cbs`, `meetup`, `webinar`, `partner`, `virtual`, `mastermind`. ### Edit an event Send only intended fields. Preserve unknown JSON configuration from the latest representation. ```http PUT /api/events/{eventId} Authorization: Bearer ... Content-Type: application/json If-Match: "event-56-r3" X-Action-Reason: Correct the venue after organizer approval {"location":"Updated venue, Bangkok"} ``` Expected safety responses: - `428`: missing `If-Match` - `412`: event changed; re-read and reconcile - `403`: event is not owned or assigned ## Registrations ### Review applications ```http GET /api/admin/event-applications/{eventId} Authorization: Bearer ... ``` ### Approve ```http POST /api/tickets/{ticketId}/approve Authorization: Bearer ... X-Action-Reason: Meets the published registration criteria ``` Approval can send email and advance payment/ticket state. Verify the returned status. ### Reject Reject only after explicit human confirmation. ```http POST /api/tickets/{ticketId}/reject Authorization: Bearer ... X-Action-Reason: Organizer confirmed the application does not meet criteria X-Confirm-Action: reject-registration ``` ### Notes ```http GET /api/admin/tickets/{ticketId}/notes POST /api/admin/tickets/{ticketId}/notes Authorization: Bearer ... Content-Type: application/json X-Action-Reason: Record organizer follow-up {"noteText":"Organizer requested a follow-up.","noteType":"follow_up"} ``` ### Audit trail ```http GET /api/admin/events/{eventId}/audit-log Authorization: Bearer ... ``` Use this after mutations and when explaining who changed an event or registration. ## Errors - `400`: invalid input, missing reason/confirmation, or unsafe retry contract - `401`: missing, invalid, expired, or revoked Wallet token - `403`: role or event assignment is insufficient - `404`: resource not found - `409`: slug or assignment conflict - `412`: stale event revision - `428`: edit precondition required - `429`: rate limit reached; honor `Retry-After` Stop and ask the human collaborator when authorization is insufficient, a requested action falls outside `event_agent`, or the intended event/registration cannot be identified unambiguously.