Tickets

Ticketing has its own developer surface because it includes inventory, holds, QR/pass tokens, scanner flows, event app integration, and organizer operations. ATM docs cover how ticket purchases fit into payments, auth, app dashboards, and app callbacks. The detailed ticket API guides live on atmosphere.tickets.

• Ticket purchases appear in the unified ATM payments ledger.
• Ticket apps use app service-auth plus user assertions for buyer or organizer actions.
• Ticket tiers, sale windows, per-order limits, and configured capacity ceilings are organizer-owned ticket config that authorized event apps can share.
• Event apps own public event UX: event creation, event pages, descriptions, images, buyer ticket pickers, organizer event workflows, and in-app support.
• ATM owns shared ticketing infrastructure: ticketed-event config, capacity, holds, payment-linked issuance, QR/pass delivery, scanner/check-in state, refunds, and ticket lifecycle webhooks.
• Organizers operate ticketed events in Earn → Tickets. App developers configure app integration plumbing in Settings → Developer.
• Issued tickets keep an immutable buyer-history snapshot of the event, tier, price, app, and organizer so later organizer edits do not rewrite past receipts or support context.
• Scarce inventory, holds, attendee data, QR secrets, and check-ins stay private.
• Ticket email delivery attempts are app-visible operational logs, but raw QR/pass secrets stay private.
• Ticket pages and emails may use the event app's cover-image snapshot plus organizer and app avatars as presentation metadata; ATM does not own a separate ticket image, and validity still comes from ATM's private ticket state and opaque scan tokens.
• Add to Wallet actions appear only when ATM has generated active Apple/Google wallet pass URLs from platform provider credentials; QR remains the fallback.
• Printable PDF ticket attachments are deferred until after QR email, hosted ticket pages, and wallet passes are stable.
• First-party scanner staff sign into the scanner PWA and need private grants before they can verify or check in tickets.
• Event apps keep consumer-facing event pages and social UX.
• ATM Tickets handles payment-linked ticket truth and webhook events.
• Standard ticket callbacks and XRPC access are core integration surfaces, not paid add-ons.

1. The event app owns the public event and buyer-facing event UX.
2. The event app creates or updates organizer-owned ticketed-event config, tiers, and capacity through ATM Tickets.
3. The organizer can review and manage event-level ticket operations in Earn → Tickets.
4. The buyer selects tickets in the event app.
5. The app creates a hold through the ticket API.
6. ATM checkout collects payment for paid tickets.
7. ATM issues tickets after payment succeeds.
8. The app receives signed events and shows tickets to the buyer.
9. The app developer uses Settings → Developer for service-auth, webhooks, test/live module setup, and delivery/debug tooling.

Availability, holds, free claims, issuance, verification, and check-in are the core loop, but the ticket XRPC surface also covers the operations around it. All of these take app service-auth (plus a buyer or organizer assertion where the action is on a user’s behalf) and are listed with full schemas in the generated reference and the atmosphere.tickets docs.