---
url: /guide.md
description: >-
  What Platypus does for a venue — the admin at a glance, and where each feature
  is documented.
---

# What Platypus does

Platypus sells tickets for small theatre venues. You get public event pages on `platypus.tickets` under your own venue address (`/t/your-venue/`), an admin for running them, and checkout that pays into **your own Stripe account**. Platypus never holds your money.

## Your admin

Sign in at `https://platypus.tickets/t/your-venue/auth/login` with your admin email. Forgotten your password? *Forgot password?* on that page emails you a time-limited link to set a new one.

The dashboard shows what's coming up and what needs doing. Each upcoming event offers its everyday actions right there: open it, view its tickets page, print the door sheet, and copy the public event link. The next-event card also offers **Copy door link** once a [door check-in link](/guide/door-checkin) exists. Everything else hangs off the sidebar:

| Area | What it's for |
| --- | --- |
| **Events** | Create and manage events — dates, description, images, and ticket types. [Setting up an event](/guide/setting-up-an-event) · [Cancelling & restoring](/guide/event-lifecycle) |
| **Tickets** | Sales tallies per event, issuing tickets yourself (including comps), printable door sheets, PDF re-downloads. [Tickets and delivery](/guide/tickets-and-delivery) |
| **Venues** | Your directory of performance venues, used when scheduling multi-date events. Appears when your venue produces shows across more than one location |
| **Mailing list** | Subscribers, tags, and campaigns. [Mailing list & campaigns](/guide/mailing-list) |
| **Customer segments** | The audiences discounts and campaigns target — every mailing-list tag is a segment. [Customer segments](/guide/customer-segments) |
| **Reports** | Sales, page views, mailouts, issues, and the audit log — with CSV exports. [Reports](/guide/reports) |
| **Security** | Your own sign-in: password, multi-factor authentication, and recovery codes. [Account security](/guide/account-security) |
| **Users** | Delegated team logins with roles. [Team users](/guide/team-users) |
| **Account and Billing** | Your Platypus subscription. [Subscription & billing](/guide/subscription-and-billing) |
| **Payments** | Connect your Stripe account so paid checkout works, and act on any flagged payment exceptions. [Stripe payments setup](/guide/stripe-payments) · [Payment exceptions](/guide/payment-exceptions) |
| **Settings** | Organisation details, ABN and ticket terms (see [Business identity](/guide/business-identity)), Site Domain (for embeds), [contact details](/guide/contact-form), [mail provider](/guide/mail-settings), [appearance](/guide/appearance), and [timezone](/guide/timezone) |

## Your public pages

Visitors see your events at `https://platypus.tickets/t/your-venue/events` — a listing of everything published, each with its own detail page and its **Buy tickets** button. The listing and per-event cards are built to be [embedded in your own website](/api/embeds), so the Ticket Office lives where your audience already is.

## The two prerequisites for selling

1. **Connect Stripe** — paid checkout stays hidden until your Stripe keys are saved and verified. Five minutes: [Stripe payments setup](/guide/stripe-payments). Free ticket types are the one exception: buyers can claim them before Stripe is connected.
2. **An event with published tickets** — at least one ticket type with capacity, on a published event: [Setting up an event](/guide/setting-up-an-event).

Your [Platypus subscription](/guide/subscription-and-billing) bills your platform access. It is deliberately **not** a switch on the Ticket Office; the switch you do have is on each event's Tickets page ([Ticket Office](/guide/ticket-office)).

## Something missing?

Looking for a topic that isn't here? That's worth telling us about — email [support@platypus.tickets](/faq/support).

---

---
url: /guide/setting-up-an-event.md
description: >-
  Creating an event — metadata, description, single or multiple dates, and
  ticket types with pricing and capacity.
---

# Setting up an event

**Events → New event** opens a three-tab form: **Event information**, **Event description**, and **Tickets**. Save sits in the top bar and only appears once you've changed something.

## Event information

* **Title** and **category** — the category is your own label (e.g. *Drama*, *Comedy*, *Kids*) shown on the listing.
* **Date mode** — one date or several:
  * **Single**: one date and start time.
  * **Multiple**: add a stop per performance (two stops can share a date for a matinee and an evening show), each with its own time label (e.g. *7:30 PM*) and location label. Stops can pull a venue from your **Venues** directory (shown when your venue produces shows across more than one location) — picking one snapshots its details onto the stop. Up to 100 stops.
* **Location** — the venue/location line shown to visitors (single-date events).
* **Event image** — JPG/PNG/GIF/WebP up to 500 KB, shown on the listing and detail page. Uploading the same image twice reuses the stored copy.
* **Visibility**:
  * **Publish status** — *draft* keeps the event invisible to the public; *published* puts it on your listing. Once a published event has sold tickets, the toggle is replaced by a notice: the event must now be [cancelled](/guide/event-lifecycle) rather than reverted to draft.
  * **Private event** — published but unlisted: reachable only by its link, with an optional **event password**. Private events never appear on your public listing or in the API.
  * **Over 18** — flags age restriction on the public page.
* **Audience** — the event's [mailing-list tags](/guide/mailing-list#tags), applied to buyers who opt in so you can target campaigns later, plus a **reminder** email to ticket holders — on by default, one day before the event; set it anywhere from 0–30 days or switch it off. The reminder is deliberately plain: date, time, venue, and a link to download their tickets (one per order). It carries no event-page link and no promotion, which is what keeps it a factual message rather than marketing under the Spam Act.

The public page URL comes from the title and date (e.g. `/t/nbt/events/the-long-run-2030-04-05`); a private event gets a random number in place of the date, so its link can't be guessed. The URL is editable next to the title until first publish. After that it locks, so retitling later doesn't break links you've already shared.

## Event description

A rich-text editor for the full pitch (up to 20,000 characters, formatting included). It's shown on the event's public page and returned via the API, so keep it self-contained. The toolbar gives you:

* **Text formatting** — bold, italic, underline, strikethrough, headings, block quotes, and left/centre/right alignment. **Undo and redo** live on the toolbar too (or `Ctrl`/`Cmd`+`Z`).
* **Lists** — numbered and bulleted, and they nest: press `Tab` in a list item to indent it, `Shift`+`Tab` to bring it back. Nesting is saved exactly as you see it.
* **Links** — select text and use the link button; paste or type a URL. Typing a bare URL links it automatically.
* **Inline images** — click the image button, drag a file into the editor, or paste one (JPG/PNG/GIF/WebP up to 10 MB; large photos are resized automatically for the web, so phone photos are fine as-is). You'll be asked for a short description of the image for screen-reader users. Leave it blank only if the image is purely decorative; the description can be edited later with the image selected.
* **Image size and placement** — select an image and drag its corner handles to resize it. The toolbar's placement buttons float it left or right (text wraps around it), centre it, or stretch it full width; click the active option again to clear it. Drag an image to move it elsewhere in the text.
* **YouTube** — paste a video URL to embed the player on the event page.

What you see in the editor is what the public page shows. Anything the editor can't produce (scripts, embeds from other sites, pasted-in exotic styling) is stripped when you save.

## Tickets

Tickets are sold in **ticket types** (batches) you define per event — for example *General admission* $25 and *Child* $15, or a free ticket. Each type carries:

* **Price** (AUD, or mark it **free**) and an optional **surcharge** — buyers see the combined price. A **free** ticket type is claimable through the public checkout with no card step: buyers choose how many, confirm, and get their tickets by email like any paid order. Free tickets carry no per-ticket platform fee, and capacity limits apply exactly as for paid types.
* **Capacity** (*ticket limit*) — the number available. Checkout enforces it: once they're gone, they're gone, including while unpaid orders briefly hold seats.
* **Order limit** — the most one order can buy. Required, and it must be lower than the ticket limit.
* **Publish status** — a *draft* type is invisible to buyers; publish it when you're ready to sell. Publishing the event prompts you about still-draft ticket types so nothing stays accidentally unsellable.
* On multi-date events, each type belongs to a **specific stop** — use **Copy batches to all dates** to fan a type out across every performance (stops that have already sold are left alone).

Type names must be unique per date.

## Discounts

Once tickets are enabled, a **Discounts** tab appears next to Tickets — the home for this event's [discounts and voucher codes](/guide/customer-segments). On a saved event it lists the discounts this event carries, with each one's uses and the dollars it has given customers on paid orders. From there you can create a new discount with the wizard, edit or deactivate one, remove one from this event (the discount itself is kept), or opt into a discount another event already has via **Add an existing discount**. On a brand-new event the tab explains that discounts attach after the first save.

Discounts apply per event. A discount this event doesn't carry never applies here: its voucher code is refused at this event's checkout, and if no active discount is carried the voucher field doesn't appear at all. When the field does appear, buyers can **Apply** their code on the first checkout step to see the discounted total before reserving. Duplicating an event copies no discounts.

## Before it can sell

A published event with published **paid** ticket types still needs your [Stripe connection](/guide/stripe-payments) before anyone can buy them. **Free** ticket types don't wait for Stripe: an event with free capacity shows its **Buy tickets** button even before payments are set up, offering the free types only. Everything else (the event page, the listing, embeds) works without Stripe too.

Online sales run through the event's [Ticket Office](/guide/ticket-office), open from the moment a published event has published ticket types until you close it or the event day passes. Once it's published and selling, [Tickets and delivery](/guide/tickets-and-delivery) covers what buyers receive, and [Cancelling & restoring](/guide/event-lifecycle) covers changing your mind.

---

---
url: /guide/tickets-and-delivery.md
description: >-
  Ticket delivery and the door sheet — the confirmation email and PDF download,
  issuing tickets yourself from the admin, and when paper beats the scan link.
---

# Tickets, PDFs & the door

**A ticket in Platypus is a PDF**: a bordered stub with the event details on one side and a QR code on the other, ready to print or show on a phone. The QR is what door staff scan on the night. This page covers how those PDFs reach buyers, how to issue tickets yourself, and the printed door sheet.

## How buyers get their tickets

The moment an order is confirmed (a payment succeeding, or a free order's final confirmation — see [Stripe payments](/guide/stripe-payments)), Platypus emails the buyer a confirmation with the ticket PDF attached: one document containing every ticket in the order, QR codes included, sent through your [mail settings](/guide/mail-settings). The email doubles as their receipt, itemising ticket prices, any discount, and the total paid with payment date and method. The seller block carries your organisation name, venue address, ABN, and contact email, plus a link to your ticket terms when you've set them (see [Business identity](/guide/business-identity)), and closes with the line that it was sent via Platypus Tickets on your behalf. The email has a plain-text version too, and on hosted mail a reply goes to your From address rather than to Platypus.

An order of free tickets skips the payment step: the tickets issue the moment the buyer confirms, the email's totals read *Free*, and there is no payment line. That email is their only receipt — no card statement backs it up.

The confirmation screen at the end of checkout shows the same order summary and a **Download your tickets (PDF)** button that returns the identical PDF, so a buyer whose email is slow still walks away with tickets. The download only works for that buyer's own paid order. A pending, expired, or someone else's order gets nothing.

For an event with several dates, the email, the confirmation screen, and the tickets all name the exact date purchased — that date's time and location, not another stop's and not your home venue. On single-date events the ticket's venue line is the event's own location if you set one, otherwise your venue address from **Settings**.

Two limits worth knowing:

* **If the confirmation email fails to send, the sale is safe** — the tickets stay issued and the failure lands in your audit log. Download the order's PDF from the admin **Tickets** page and send it on yourself.
* **There is no buyer login and no resend button.** A buyer who loses both the email and the confirmation page needs you: find the order under **Tickets**, download its PDF, email it over.

## Issuing tickets yourself

For door sales, comps, and guests, create a ticket group from **Tickets** in the admin: pick the event, enter who it's for and how many tickets of each type, and download the group's PDF (same stub-and-QR layout as an online order) to print or email. Ticket types come from the event's batches (see [Setting up an event](/guide/setting-up-an-event)), and admin-issued counts draw down the same capacity as the [Ticket Office](/guide/ticket-office): asking for more than a batch has left is rejected with the remaining count, and nothing is created. Issuing tickets yourself works whether the Ticket Office is open or closed.

Admin-issued tickets are sold tickets everywhere it matters: they appear in the sold totals and on the door sheet, and they scan at the door exactly like a purchase.

## The printed door sheet

The door sheet is a printable list of everyone coming. Open it from the **Door sheet** link on the **Tickets** page, the Events list, or the Dashboard (shown only for events with ticketing enabled). The page opens in a new tab: plain black-and-white A4 with no app chrome, made for a printer.

It shows the event's title, date, and time, sold totals broken down by ticket type, and one row per sold ticket: a tick-box, the ticket code in monospace, the ticket type, and the name with the buyer's email — `Alex (person@example.com)`. Rows are ordered by name (ignoring letter case), so finding someone with a pen is fast. Only paid tickets appear; pending checkouts and expired orders are excluded. Every printed page carries a footer, `<Event> - <Date> <Time> - Page x of y`, so you can tell at the door that no page is missing.

For a multi-date event you get a **Door sheet** link per date as well as one for the whole event. The per-date sheet lists only that date's ticket holders and puts that date's time and location in the header. Print the one for tonight, not the tour.

The sheet lists buyer names and emails, so treat the printout like the personal data it is. It's for the door, not the noticeboard.

## Paper sheet or scan link?

Use both. The [door check-in link](/guide/door-checkin) is the primary: scanning verifies live that a ticket is genuine, paid, for tonight, and not already used. A paper tick can't stop the same ticket walking past two doors. The sheet is the backup that needs no battery and no wifi, and it doubles as a name list for regulars who never open the email. Print it close to doors opening: it's a snapshot, so tickets sold after printing won't be on it. They'll still scan fine.

A PDF that won't download or looks wrong is worth reporting — email [support@platypus.tickets](/faq/support) with the order reference. For the night itself, read [Door check-in](/guide/door-checkin).

---

---
url: /guide/door-checkin.md
description: >-
  Checking tickets in at the door with a secret scan link — creating and sharing
  the door link, what staff see, the check-in window, undo, and the printed door
  sheet fallback.
---

# Door check-in

On show night, door staff scan each ticket's QR code with a phone and Platypus confirms on the spot that it is genuine, paid, for tonight, and not already used. Staff don't need accounts or logins. You share a **secret door link**; the link itself is the credential.

## 1. Create the door link

Open **Tickets** in the admin sidebar, pick the event, and press **Create door link** on the *Door check-in* card. You get a link like:

```
https://platypus.tickets/door/curious-tango-42
```

Copy it and send it to whoever is working the door. Text message is fine, and the word-style link is easy to read aloud or retype if a tap doesn't work. Anyone who has the link can check tickets in, so share it only with people working that night.

## 2. What door staff see

Opening the link on a phone shows a camera view, a running **checked-in / sold** tally, and a code entry box:

* **Scan** — point the camera at the ticket QR (on paper or a screen). The verdict fills the screen: green with the attendee's name for a good ticket, red with a reason for anything else — *unknown code*, *unpaid order*, *already used* (with the time), *cancelled performance*, or *wrong day* (showing the day the ticket is actually for).
* **Type instead** — if the camera can't read a crumpled printout, type the short code printed under the QR and press **Check**.
* **Undo** — mis-scanned someone? Press **Undo — mis-scan** on the green screen and the ticket becomes scannable again.

Each ticket checks in exactly once. Scanning it a second time shows *already used*, even if two phones scan it at the same moment.

## When check-in is open

The door link works **on the day of the performance and the whole following day**, so a ticket holder wandering in after midnight still scans fine. Outside that window the link shows a *check-in closed* page and accepts nothing. For an event with several dates, each ticket is valid only around its own date: last night's ticket shows *wrong day* tonight.

The window follows your venue's timezone (set in **Settings**).

## Rotating or revoking the link

On the *Door check-in* card:

* **Rotate link** — issues a fresh link and kills the old one instantly. Do this if a link leaked or after each run of shows.
* **Revoke** — kills the link without replacing it. Scanning stops until you create a new one.

Every check-in, undo, and link change is recorded in your venue's audit log. The admin **Tickets** page shows the same checked-in-against-sold tally per event, so you can see how many actually came without borrowing the door phone.

## Can attendees check themselves in?

No. The QR on a ticket is just the ticket's code — it is not a web address, so scanning it with a phone camera shows a short text string and nothing else. Checking in requires the secret door link, which never appears on tickets. There is nothing an attendee can scan, tap, or visit that marks their own ticket as used.

## If the wifi dies

Print the **door sheet** before the show (**Tickets** → your event → **Doorsheet**; the row menus and Dashboard call it **Door sheet**) — it lists every sold ticket with a tick-box, ordered by name, and works with a pen. The scan page needs a connection; the paper never does.

---

---
url: /guide/event-lifecycle.md
description: >-
  Cancelling events — what ticket buyers see, why refunds and buyer contact are
  your job, hiding a cancelled listing, and recovering with restore or
  duplicate.
---

# Cancelling, restoring & duplicating events

Cancelling closes the Ticket Office immediately but deletes nothing — the event, its tickets, and every buyer record stay put. To stop online sales without cancelling, [close the Ticket Office](/guide/ticket-office) instead. Know this before you cancel: **Platypus does not refund your buyers and does not tell them anything**. The cancellation changes the public page and blocks checkout; contacting and refunding ticket holders happens outside the platform, and it's on you.

## Cancelling a published event

Open **Events** and choose **Cancel event** from the event's row menu. You must give a reason. It's shown publicly on the event page, so write it for your audience (*"Cast illness — Saturday's performance will not go ahead"*). The confirmation spells out what Platypus won't do: notify your buyers, or refund them.

The moment you confirm:

* The **Buy tickets** button disappears and checkout refuses the event. A buyer mid-checkout is told the event has been cancelled and gets no tickets; anyone who **already paid keeps their order and tickets** unchanged.
* Scheduled reminder emails for the event stop going out.
* At the door, a scanned ticket for it shows *Cancelled performance* (see [Door check-in](/guide/door-checkin)).

You can't flip the status back in the edit form. A cancelled event's record page is view-only; the recovery actions below are the only ways out.

## Refunds and emailing ticket holders

Platypus never moves money back. Ticket payments went straight to your own Stripe account (see [Stripe payments](/guide/stripe-payments)), so issue refunds from your Stripe dashboard.

Platypus also never emails buyers about a cancellation. Do it yourself, promptly: the event's **Tickets details** page shows a warning banner with a direct link to a pre-filled **Email ticket holders** campaign addressed to everyone who bought a ticket. The same action sits in the event's row menu whenever the event has paid sales.

## What stays public — and hiding it

A cancelled event **stays on your public events listing until its date passes**: clearly marked *Cancelled*, muted, with no price and no way to buy. Its card still links to the detail page, which shows a cancellation notice with your recorded reason. It is never featured as the *Next performance*. Once the date passes, it drops off like any other past event.

If you'd rather it vanish sooner, the event's archive row offers **Hide from public site**: the event leaves the listing and the API, and the row gains a *Hidden* marker. One limit: the detail page itself **stays reachable by direct link**, still showing the cancellation notice, so anyone holding the URL can read what happened. **Show on public site** reverses it. The toggle exists only for cancelled events, and every use is written to your audit log.

## Restoring (and rescheduling)

On the archive row (its main action reads **View cancelled event**) or the record page's danger zone, press **Restore event**. The event returns to *draft*, the cancellation reason and timestamp are cleared, and the fully editable form opens. Republish whenever you're ready. The event reappears publicly with no trace of the cancellation.

Rescheduling is exactly this: restore, change the date, republish. Restoring also resets public visibility to shown, so if you cancel again later the event starts visible again.

## Duplicating

**Duplicate event** builds a fresh draft copy: title, category, date and time, description, location, image and settings flags, plus each ticket type copied as an unpublished draft. The copy gets a new web address, and none of the old sales come with it — no tickets, no buyer data, and none of the event's [discounts](/guide/customer-segments). A multi-date event's individual stops are **not** copied; re-add the dates you need. You land straight on the new draft's edit page.

Restore when it's the same show moving; duplicate when you want the cancelled event left intact as a record and a clean slate to sell from.

## Cancelling a single date

For an event with multiple dates you can cancel one stop on its own, with its own required reason, and leave the rest selling:

* The other dates are untouched; if the cancelled stop was next up, your public listing date moves on to the next scheduled one.
* On the public page the stop shows struck through with its reason and no buy button, and checkout refuses it. Its sold tickets are kept, paid holders keep theirs, and no reminder is sent for it.
* If the stop has paid sales, you're prompted to email only that date's ticket holders.

Refunds for a cancelled date are your responsibility, same as a full cancellation. A cancelled stop can be restored to scheduled later, which clears its reason.

## Deleting vs cancelling

Cancelling is the normal path for a show that won't happen — it keeps the record, the tickets, and the audit trail. It's also the *only* way to withdraw an event once tickets exist: a published event with ticket sales can't be reverted to draft (the editor replaces the publish toggle with a notice, and the server refuses the change), so unpublishing can never silently strand ticket holders. Stopping online sales while the show goes ahead is a different job, and a reversible one: [close the Ticket Office](/guide/ticket-office). **Delete event** is a hard delete: permanent, non-recoverable, and only available when the event has **no paid sales and no checkout in progress** (long-expired checkout holds don't block it). Paid sales always block deletion. Cancel instead.

Deleting makes you type the event's exact title to confirm, and the server rejects a mismatch independently of the form. The dividing line: if anyone has ever paid, you cancel; delete is for mistakes and events that never sold.

If an event behaves in a way this page doesn't describe (still selling after a cancel, for instance), that's a bug — email [support@platypus.tickets](/faq/support).

---

---
url: /guide/ticket-office.md
description: >-
  The Ticket Office — closing online sales now or at a set time, the public
  message, reopening, the automatic close after the event day, and what the
  audit log records.
---

# Ticket Office

The Ticket Office is your online sales for an event: the **Buy tickets** button, the checkout, the orders that arrive by email. **You can close it without cancelling the event.** Close it now or at a set time, tell buyers what to do instead, and reopen it while the event is still upcoming. Door sales, tickets you issue yourself, and check-in carry on regardless: closing the Ticket Office stops new online orders and nothing else.

The controls live on the event's Tickets page: **Tickets → your event → Ticket Office**. The event editor shows the current state on its Tickets tab with a link across.

## Closing it now

1. Open **Tickets → your event**.
2. In the **Ticket Office** card, choose **Close now**.
3. Optionally write a public message (up to 300 characters, plain text), for example *Tickets are available at the door from 6:30 pm.*
4. Confirm with **Close Ticket Office**.

From that moment the public event page lists the ticket types and prices as before, but in place of **Buy tickets** it shows *Online ticket sales have closed.* with your message beneath. The events listing keeps the price and swaps **Book tickets** for *See details*. Anyone who opens the checkout link lands back on the event page.

Buyers who were already mid-checkout can finish: a reservation made before you closed keeps its 10-minute hold and completes normally, though its basket can no longer be changed. The card tells you how many buyers are mid-checkout at the moment you close.

## Closing it at a set time

Choose **Schedule closure**, pick a date and time in your venue's timezone, and add the same optional message. The time must be in the future and no later than the end of the event's last day (the last stop, for a multi-date event). The card then reads *closes 12 Sep, 7:30 pm*, and the public page shows *Online sales close 12 Sep, 7:30 pm.* above the **Buy tickets** button so buyers see the deadline coming.

The closure takes effect at that exact moment for every buyer, wherever they are. **Change schedule** moves it; **Clear schedule** removes it. **Close now** while a closure is scheduled closes the office immediately and drops the schedule.

Move the event and the scheduled closure moves with it: shift a single-date event a week later and the closing time shifts a week later too, at the same clock time. A multi-date event follows its last stop, so adding, moving, or cancelling the final date moves the closure by the same number of days. If a move puts the closing time in the past, the Ticket Office is closed from that save onward, and the save says so.

## Reopening

**Reopen Ticket Office** puts the **Buy tickets** button back straight away and clears the message and any schedule. Reopening is available while the event is upcoming. Once a single-date event's day has passed, the office stays closed.

## The automatic close

A single-date event's Ticket Office closes on its own once the event day has passed in your venue's timezone, even if you never touched it. The public page then reads *This event has already taken place.* and offers no way to buy. Multi-date events close per stop instead: a date that has passed can't be booked, while later dates keep selling until you close the whole event or its last day passes.

## Multi-date events

Closing the Ticket Office covers every date of a multi-date event at once. Each stop keeps its from-price on the public page; the per-date **Buy tickets** buttons go, and one closed notice appears beneath the list.

## Cancelling, restoring, and duplicating

Cancelling an event closes its Ticket Office as part of the cancellation, and the cancellation notice takes over the public page. Restoring a cancelled event to draft reopens the Ticket Office as well, so a republished event starts open; the same happens when you revert an unsold published event to draft. A duplicated event always starts with its Ticket Office open.

## Where the state shows

* **Public event page and embeds** — the notice and your message replace the **Buy tickets** button; the ticket list stays.
* **Events listing** — price kept, *See details* and *Online sales closed* in place of **Book tickets**.
* **Admin lists** — the Events and Tickets pages show a badge beside the event's status while a closure is scheduled, in effect, or the event day has passed.
* **API** — every event carries a `ticket_office` object with the open/closed status and the reason. See [Event endpoints](/api/events).

Buyers never see the words "Ticket Office"; public copy describes the effect in plain words. You see the name in the admin, in reports (online orders are labelled *Ticket Office* in the sales channel split), and here.

## What the audit log records

Every change is a line in the [audit log](/guide/reports#audit-log-admins-only): *Ticket Office closed*, *Ticket Office closure scheduled*, *Ticket Office closure rescheduled* (including moves caused by rescheduling the event), *Ticket Office closure schedule cleared*, *Ticket Office closed by schedule*, *Ticket Office message updated*, and *Ticket Office reopened*, each with who did it and when. Filter the log by the text "Ticket Office" to see the whole trail. The message text itself is not stored in the log, only its length.

## When something looks wrong

| Symptom | Likely cause | Fix |
| --- | --- | --- |
| **Close now** is missing from the card | The event is a draft, private, has tickets turned off, or has already passed | Publish the event and turn on **Tickets enabled**; a past event's office stays closed |
| Scheduling refuses the time | The time is in the past, or after the end of the event's last day | Pick a time before the end of the last day; to close after that, the automatic close already does it |
| The office closed on its own | The event day has passed, or a rescheduled event moved a scheduled closure into the past | Check the audit log for *closed by schedule* or *rescheduled*; reopen if the event is still upcoming |
| A buyer bought a ticket after you closed | Their reservation predated the closure | Expected: holds made before a closure complete within their window |

Anything else: email [support@platypus.tickets](/faq/support).

---

---
url: /guide/mailing-list.md
description: >-
  Building and using your subscriber list — how people join and leave, adding
  and importing subscribers, tags, sending email campaigns, and phone capture.
---

# Mailing list & campaigns

Your mailing list is the audience you email about shows: one list of subscribers per venue, managed from **Mailing list** in the admin sidebar. The page is split into tabs — an **Overview** tab with your subscriber counts and the send buttons, **View & export** for the searchable list, **Add & import**, **Tags**, and **Unsubscribed & blocked** for the addresses Platypus keeps campaigns away from. **Campaigns are email only.** Platypus stores phone numbers but never sends anything to them.

## How people join — and leave

Two ways onto the list:

* **The public subscribe form.** A visitor enters their email (and optionally a phone number) and gets a confirmation email. They're not a recipient until they open the link and press **Confirm** on the page it lands on (double opt-in; the button is there because some mail scanners follow every link in a message, and a scanner must never be able to confirm on a person's behalf). The confirmation link lasts 3 days; if it lapses, subscribing again sends a fresh one. The form never reveals whether an address is already on your list, and carries a short collection notice naming your venue and linking the privacy policy.
* **Checkout opt-in.** The ticket checkout offers a mailing-list tick box. When the order is paid, the buyer lands on your list tagged `opt-in`, plus whatever tags the event carries. A buyer who doesn't tick the box and isn't already a subscriber is left alone — no record is created. A buyer who unsubscribed earlier, or whose sign-up was never confirmed, isn't put straight back on: ticking the box sends them a confirmation email, and they're a recipient only once they press **Confirm**.

Leaving is one click, and it sticks. Every campaign email to subscribers carries an unsubscribe link in the footer, plus the headers mail apps use for their own **Unsubscribe** button; either route takes effect immediately, with nothing to log in to and nothing to confirm. Platypus remembers the address: the person stays on your list marked *Unsubscribed*, and no later import, checkout tick box, or manual add can put them back on campaigns. Only they can undo it, by subscribing again and pressing **Confirm**. You can still remove any subscriber yourself from the list view. Removing deletes the record; unsubscribing keeps it, and that memory is what stops a re-imported spreadsheet from emailing someone who asked you to stop.

## Adding and importing subscribers

On **Add & import**, the **Add a subscriber** button opens a dialog for adding one person at a time — email, phone, name, with at least an email or a phone required. People you add are treated as confirmed (they'll receive campaigns straight away), so only add people who've actually agreed to hear from you. Adding an email or phone that's already on the list is harmless: nothing changes, and no duplicate is created. An address that has unsubscribed is refused with a message saying so; that person can rejoin only through the subscribe form.

For a whole spreadsheet, use the **CSV import**: a file with `email`, `phone`, and `name` columns (at least one of the first two). The form offers a **template CSV** with the right headings and an example row. You get a **preview first**: how many rows would import, how many are duplicates, how many are **kept out** because that address unsubscribed, and how many are invalid and why. Nothing is saved until you confirm.

The import creates confirmed subscribers, skips duplicates, leaves unsubscribed addresses out, and counts bad rows without aborting; a summary panel reports the tallies. Tags picked at import time apply to *every* subscriber the file touches: new rows and the existing subscribers it matched. That makes re-importing a file the way to re-tag an audience — existing subscribers gain the new tags, and the rest of their record is left alone.

**View & export** shows the full list: searchable, sortable, filterable by tag or by status (*Unsubscribed* shows who has left), 25 per page, with a total / confirmed / unconfirmed / unsubscribed breakdown that follows your filters. Export the whole list (or only the filtered matches) to CSV any time. Exports include a tags column and an *Unsubscribed (UTC)* column, so a list you take elsewhere still shows who must not be emailed; internal fields like confirmation tokens are left out.

## Importing from your mail provider

If your [mail provider](/guide/mail-settings) exposes its lists to Platypus (Mailgun or Resend with a verified full-access key), the **Add & import** tab also shows **From your mail provider**: your provider-side lists or segments with their member counts, each with an **Import** button. Importing pulls that audience onto your Platypus list — members become confirmed subscribers, deduplicated against people already on your list, and carry a provenance tag like `Mailgun: Members` so you can target (or untangle) them later. Invalid addresses are skipped and counted; members who unsubscribed on the provider side are never imported, and neither is anyone who has unsubscribed from your Platypus emails (they're counted as kept out).

The same consent rule as the CSV import applies: only import people who actually agreed to hear from you. Once in, they're ordinary subscribers — every campaign email they get carries an unsubscribe link, and unsubscribing here sticks for all future sends and re-imports, whatever the provider list says.

Imports are a point-in-time copy (re-running updates rather than duplicates), capped at 2,000 members per source. The section only appears when your provider supports the import; on any other setup (SendGrid, whose member export Platypus can't read, or a key that can send but can't read lists) it stays hidden. If you expected it, see [which key to paste](/guide/mail-settings#choosing-a-provider).

## Tags

Tags are labels on subscribers — up to 100 per venue, matched case-insensitively. Two are applied automatically and can't be renamed or deleted: `subscribe` (joined via the public form) and `opt-in` (ticked the box at checkout). Events can carry tags too: when a paid order is fulfilled, the event's tags land on the buyer's subscriber record, even for an existing confirmed subscriber who didn't tick the opt-in box. That's how a "Comedy" tag accumulates the people who actually buy comedy tickets.

The **Tags** tab lists every tag with its subscriber count — click a count to see those subscribers. Rename or delete your own tags from here; deleting a tag detaches it, and the subscribers stay. Renames and deletions go to your audit log.

Tags are how campaigns target: a campaign to subscribers can carry a tag filter and reach only people holding **at least one** of the selected tags. The composer shows a live recipient count as you change the selection, so you always know who a send will reach.

## Unsubscribed & blocked

The **Unsubscribed & blocked** tab lists every address Platypus keeps campaigns away from, newest first, each with its reason: *Unsubscribed* for people who used a link, *Blocked by you* for addresses you added here. Unsubscribing or blocking stops campaigns only; emails about an order, such as ticket confirmations, are unaffected.

To block an address, type it in (with an optional note for your own records) and press **Block**. A blocked address never gets a campaign, however it turns up again: a CSV or provider import, the checkout tick box, or the add-a-subscriber dialog. Blocks and releases go to your audit log.

**Release** lifts a block you added. An unsubscribe isn't yours to lift: only the person can reverse it, by subscribing again and confirming. A released record stays in the list, greyed out, so you can see what changed and when.

## Sending a campaign

Campaigns are built in a short wizard (**Type → Recipients → Compose → Review & send**), reached from the **Overview** tab, the campaigns list, or an event's row menu. Each step is checked before you can move on. Opening the wizard from an event row skips the steps the link already answered: you land straight on Compose, and you can still step back to the earlier ones.

**Type** — three campaign shapes:

* **Event page** — pick one event; the email renders its title, description, date, location, and image with a link to the public page.
* **Upcoming events** — tick several upcoming published events, add an optional intro, and each renders in date order. An event that gets cancelled or unpublished before you send drops out of the email.
* **General mail-out** — write your own subject and body in the rich-text editor. It has the same formatting, lists, alignment, and inline images as the [event description editor](/guide/setting-up-an-event#event-description), minus video, which email clients can't play, and minus image placement, which they can't render; image resizing still works. The HTML is sanitised server-side, so pasted scripts and the like are stripped.

**Recipients** — **subscribers** (confirmed, with an email address, and not unsubscribed or blocked; optionally narrowed by tags, with a live "would reach N" count as you adjust) or the **ticket holders** of one event, which for a multi-date event can be narrowed to a single performance. A **Platypus segment** quick-pick applies a [segment](/guide/customer-segments)'s tag in one click: the system "Platypus signups" segment, or any tag's segment (every tag is one). Ticket buyers who never joined the mailing list are deliberately not a campaign audience.

Event rows offer **Email subscribers** and, once there are paid orders, **Email ticket holders** as prefilled shortcuts. A ticket-holder send reaches each paying buyer once, leaving out anyone who has unsubscribed or been blocked; those emails carry no unsubscribe link (recipients are buyers, not list members) and their footer names the event instead. Recipients are locked in once the draft is saved — changing them afterwards resets the draft, though your subject and content are kept.

**Review & send** — reaching this step saves the campaign as a draft and shows the rendered email right on the page, with a link to open it in a new tab. Send from here (with a confirmation), or keep the draft and come back later. To fix something, **Edit content** returns you to Compose with everything intact.

Browsers and inboxes render differently, so there's also **Send test**: type an address and the exact campaign is delivered to that one inbox, subject marked *\[Test]*, without touching your audience or the campaign's status. The address is remembered in your browser for next time. Drafts reopen in the composer, which shows the same preview and test send beside the editor; the preview refreshes when you save, and is flagged as showing your last save while you have unsaved changes.

Two honest limits gate your first send:

* **A mail provider.** Campaigns and their test sends go out through [your own mail provider](/guide/mail-settings); ticket and reminder emails are unaffected. If running a paid provider doesn't fit your venue, Platypus can configure your account for [total hosted email support](/faq/features#campaigns-without-a-paid-mail-provider) instead: campaigns then ride Platypus hosted email, sent from a Platypus address carrying your venue's name, with replies going to your own From address, and a notice under the send button asks you to use it considerately.
* **Your identity.** Every email must say who sent it and how to reach you (Spam Act 2003, s17), so a send (test sends included) is refused until **Settings → General** has your **Organisation Name** and there is a way to reach you: a **Public Contact Email** under **Settings → Contact**, or the **From address** under **Mail**. The footer prints that name, your ABN when set, and whichever contact details you've filled in; a postal address is welcome there but not required. [Mail settings](/guide/mail-settings#what-every-email-says-about-you) shows the footer in full.

Sending is queued and tracked per recipient: one bad address doesn't stop the batch, a re-run never emails anyone twice, and a send that would reach nobody is refused with a message rather than silently "sent".

## The campaign page

Every campaign has its own page — click its subject in the campaigns list, or send one and you'll land there. While a send is under way the page updates itself: status and the sent/failed counters tick along without a refresh, alongside how many recipients unsubscribed from that email and how many were *Suppressed* (skipped at send time because they unsubscribed or were blocked between the draft being saved and the send). Once it finishes, any failed recipients are listed with the error each address returned, downloadable as a CSV for chasing bounces. Drafts show their edit and delete actions here too, and the email preview is always a click away.

## Discounts moved

Tag-gated discounts (formerly the "member benefit" tab) now live on each event's Discounts tab, targeting [customer segments](/guide/customer-segments); every tag doubles as a segment automatically. Any benefit you had configured became a **deactivated voucher code** with a generated code and its member restriction intact — it no longer applies by itself. To offer it again, open it on the event's Discounts tab, give the code a name you'd put in an email, activate it, and send it to your members in a [campaign](/guide/mailing-list#campaigns). Its redemption history is untouched.

## Phone numbers

The subscribe form and the checkout both take an optional phone. Checkout numbers are captured only once the order is paid, stored unconfirmed, and deduplicated — a repeat buyer doesn't create a second row, and a capture hiccup never delays their tickets.

Phones are **storage only**. Platypus sends no SMS and makes no calls; the numbers exist for your own records and exports. A phone-only subscriber (no email) never receives a campaign.

Campaign delivery follows your mail provider (your own, or Platypus hosted email where we've arranged it), so when it misbehaves, start with the [mail settings troubleshooting table](/guide/mail-settings#troubleshooting). Anything it and the failed-recipients list can't explain is worth reporting — email [support@platypus.tickets](/faq/support).

---

---
url: /guide/contact-form.md
description: >-
  The public contact form — what visitors see, where messages are delivered, the
  Contact Form Inbox setting, and what to check when messages stop arriving.
---

# Contact form

Every venue site carries a **Contact** page in its public navigation, at `/t/your-venue/contact`. A visitor fills in their name, email, and message (phone optional) and presses **Send message**; Platypus emails the lot to the address you save as the **Contact Form Inbox**. **Messages are delivered as email and nowhere else — Platypus keeps no copy.**

## What the visitor sees

The page has two halves. Beside the form, a *Get in touch* card lists whatever contact details you've chosen to publish: the **Public Contact Email**, **Public Contact Phone**, and **Public Contact Address** from the **Contact** tab of **Settings**, plus the **Venue Address** from the Venue tab. Each line appears only when it's set; leave them all blank and the card disappears, leaving the form on its own.

The form asks for a name, an email address, an optional phone number, and a message of up to 2,000 characters. On success the visitor sees a confirmation: *Your message has been sent. We will be in touch soon.* Sending a message adds nobody to anything — the mailing-list signup is the separate **Subscribe** page, covered in [Mailing list & campaigns](/guide/mailing-list).

If you theme your public pages with [custom CSS](/api/appearance-css), this page exposes the hooks `#page-contact`, `#contact-details`, and `#contact-form`.

## Where messages go

Submissions are delivered to the **Contact Form Inbox**, on the **Contact** tab of **Settings** in the admin sidebar. That address is never shown publicly, and it's deliberately separate from the **Public Contact Email**: the address printed on the page receives nothing from the form, so you can publish a general address while submissions go to the person who actually answers them.

Each submission arrives as one email with the subject *New contact form message — your venue's name*, carrying the sender's name, email, phone (when they gave one), and message. The sender's address is set as the Reply-To, so replying in your mail app goes straight back to the visitor.

Delivery uses your venue's [mail provider](/guide/mail-settings) — the same settings that send your tickets. On the default Platypus hosted mail it works with no setup.

## Is there an inbox inside Platypus?

No. Despite the setting's name, the Contact Form Inbox is an email address, not a screen in the admin. There is no page of past messages: Platypus doesn't store submissions, so a message exists only as the email it becomes. That's worth taking seriously — if your mail provider is broken, a visitor's message is gone, not queued. The [test send](/guide/mail-settings#send-a-test-email) on the **Mail** tab is the cheap way to be sure that isn't happening.

## When no inbox is set

You can't save the **Contact** tab with the inbox blank, but a venue that has never saved that tab has no inbox at all. The contact page still renders and still shows the form; a visitor who submits sees *Contact is not currently available. Please try again later.* and no email is sent. Set the inbox before you point anyone at the page — it's the one field on that tab that makes the form do something.

## Spam

There's no CAPTCHA. Submissions are rate-limited to ten a minute per visitor, which blunts a crude flood, and whatever gets through is ordinary email you delete like any other. Nothing lands in Platypus, so there's nothing to clean up on this side.

## Troubleshooting

| Symptom | Likely cause | Fix |
| --- | --- | --- |
| Visitors report *Contact is not currently available* | No Contact Form Inbox saved | Set it on **Settings → Contact** |
| Messages stopped arriving | The mail provider broke, or the inbox address changed hands | Run a [test send](/guide/mail-settings#send-a-test-email); check the inbox's spam folder |
| Messages turn up at the public contact email | They won't — that address gets nothing from the form | Watch the address saved as **Contact Form Inbox** |
| Replying to a notification emailed the visitor, not you | The notification's Reply-To is the sender | That's the point — replying answers the visitor directly |
| The *Get in touch* card is missing | All four contact detail fields are blank | Fill in whichever of them you want published |

If a clean test send arrives but form messages still don't, that shouldn't happen — email [support@platypus.tickets](/faq/support).

---

---
url: /guide/customer-segments.md
description: >-
  Customer segments, discounts, and voucher codes — every mailing-list tag is a
  segment, discounts live on each event's Discounts tab, and every discount is a
  code the buyer enters at checkout.
---

# Customer segments

**Customer segments** in the admin sidebar shows the audiences your discounts and campaigns can target. You never create a segment by hand: **every mailing-list tag is automatically a segment** of the same name, and two are built in and always present:

* **Platypus signups** — everyone confirmed on your mailing list via the public subscribe form (the `subscribe` tag).
* **Platypus sales** — everyone who has bought tickets from you, whether or not they ever joined your mailing list. Buying never adds anyone to the list as a side effect.

Each segment shows a live count of the people it currently matches, plus whether any discount uses it. The count runs the same checks checkout enforcement runs, so the number you see is the number that applies. To add or rename a segment, add or rename the [mailing-list tag](/guide/mailing-list#tags) behind it: renaming a tag renames its segment, and deleting a tag removes it. A tag whose segment gates a discount can't be deleted until the discount is removed or re-targeted, and the built-in segments can't be deleted at all.

## Discounts live on the event

Discounts are managed per event, on the **Discounts** tab of the event form. The tab appears once **Tickets** are enabled (see [setting up an event](/guide/setting-up-an-event#discounts)).

**Every discount is a voucher code.** It has a name that buyers see on their order, a value in percent or dollars off, and a code the buyer enters at checkout — nothing applies by itself. By default a code works for anyone who has it; restrict it to a segment and it only works for buyers whose email is in that segment. Who receives the discount is decided by who you give the code to, which also makes it easy to explain: put the code in a campaign, on a poster, or in a hand at the door.

A discount only ever applies to the events that carry it. Creating one from an event's Discounts tab attaches it to that event; another event can opt into the same discount with the tab's **Add an existing discount** picker, so "SPRING10 across three spring shows" is one discount on three events. Removing a discount from an event keeps the discount — it stops applying there, and nothing more. Deleting it removes it from every event, and the confirmation warns you when other events share it. Deactivating works the same way: the switch is on the discount, not the event, so turning a shared code off from one event turns it off everywhere — the confirmation names the other events first.

## Creating a discount

**New discount** on the event's Discounts tab opens a two-step wizard:

1. **Set up** — name, percent or dollar value, and the code. **Suggest** fills in a ready-made code from the name; type your own if you'd rather it read `BESTIES25`. The code is for anyone who has it unless you expand **Limit to a customer segment** and pick one — each segment shows how many people it currently matches, and picking one that matches nobody warns you (buyers would be refused until people match). Use limits and a validity window sit behind **Limits & dates**, all optional.
2. **Review & publish** — the summary, an optional promo line for the event page, what buyers will actually pay per ticket type, and whether the discount starts active.

The review step's price preview is computed by the same code that prices real checkouts, so what it shows is what buyers pay — including the rule that a discount never takes a paid order below $0.50 AUD. There is no events step: the discount is for the event you started from. Editing an existing discount is a normal form that saves from the top bar, with the same price preview; when the discount is shared, the editor lists the other events it applies to, since your changes reach them too.

## Voucher codes

A voucher code is 3–32 letters, numbers, and dashes, unique within your account. Case doesn't matter: `save10` and `SAVE10` are the same code.

Buyers type the code into the optional **Voucher code** field on the checkout selection step and press **Apply** to see their discounted total before reserving anything. A wrong, expired, or used-up code says so right there; a segment-restricted code asks for the buyer's email first, then answers for that address. Skipping **Apply** loses nothing — the code is checked and applied when the buyer continues. A code entered on an event that doesn't carry its discount is refused with *This code cannot be used for this event.* If an event carries no active discount at all, the voucher field doesn't appear on its checkout.

You can limit a code:

* **Total use limit** — how many paid orders can ever use it (e.g. "first 20 buyers").
* **Per-customer limit** — how often one email address can use it (e.g. once each).
* **Valid from / until** — a window outside which the code doesn't work.

Only **paid** orders count against the limits. An abandoned checkout doesn't use anyone's code. The Discounts tab shows each code's uses against its limit (e.g. `3 / 100`).

## Whether a code is actually working

The **Status** column on the Discounts tab answers the question the other columns dance around: would this code work if someone typed it right now? The discount editor shows the same status, next to the dates and limits that decide it.

| Status | What it means |
|---|---|
| *active* | Redeemable now, with no end date and no limit in sight. |
| *active until 30 Sep* | Redeemable now; the window closes on that date, in your venue's timezone. |
| *starts 12 Sep* | Switched on, but its window hasn't opened yet. Nobody can redeem it before then. |
| *N uses left* | Redeemable, but the total use limit is close — a warning tint, so a code about to run out doesn't surprise you mid-season. |
| *limit reached* | The total use limit is spent. Buyers are refused. |
| *expired* | The end of its window has passed. Buyers are refused. |
| *inactive* | You switched it off, and nothing else is blocking it. |

*Limit reached* and *expired* are tinted as warnings, because both mean the same thing to a buyer at checkout: refused.

When a code is both switched off **and** out of road — deactivated with an end date already past, say — the status names the harder problem. A row reading *expired* is telling you that switching it back on wouldn't help; extend the window, or lift the limit, first.

Two things the Status column can't tell you, because both depend on who is buying: whether a buyer has personally used up a per-customer limit, and whether their email is in the code's segment. For those, the buyer sees the reason at checkout when they press **Apply**.

## What a discount has given away

Once a discount has been redeemed on paid orders, its row on the Discounts tab and its editor show the cumulative dollar value it has given customers: the sum of what buyers actually saved, counted from paid orders only. The dashboard's **Next event** card shows the same idea at event level — a **Discounts** figure with the total given away on that event, next to its undiscounted revenue.

## One discount per order

An order carries at most one discount: the code the buyer entered. Discounts never stack, there is nothing to rank or compare, and a buyer who enters no code pays full price even if their email would qualify for a segment-restricted one. The discount always leaves at least $0.50 AUD payable (card minimum) — a voucher can reduce a paid order, never make it free.

## Where discounts show up

* The optional **promo line** appears on the event page and checkout for *everyone*. It never reveals whether a particular visitor qualifies, and it only decorates the events that carry the discount; a code outside its validity window stops decorating prices.
* A buyer who applied a code sees it by name with the amount taken off — on the selection step's preview, above the card details, and on the order summary. In the rare case a code is used up in the moment between entering it and paying, checkout says the code could not be applied and shows the full price before any card details go in.
* Redemptions appear in the audit log. The Discounts tab shows each code's paid-use count and dollars given, and the sales report's CSV export includes the discount columns.

Duplicating an event never copies its discounts: the duplicate starts clean, so a limited code can't quietly extend to a show you didn't intend.

Seeing a code refused where it should work? Check the event carries the discount, the code is active and in its window, its limits aren't used up, and — for a segment-restricted code — that the buyer's email is actually in the segment (the segment page shows who matches). If the numbers still look wrong, email [support@platypus.tickets](/faq/support) with the event, the discount, and the buyer's email address.

---

---
url: /guide/reports.md
description: >-
  The Reports section — sales and revenue, page views, mailout delivery,
  checkout issues and broken links, the admin-only audit log, and CSV exports.
---

# Reports

**Reports** in the admin sidebar opens on a 30-day summary (tickets sold, revenue, page views, and how your last mailout delivered) with a card into each report below it. **Every report exports as a CSV**, named for the report, your venue, and today's date — for example `sales-report-yourvenue-2026-08-01.csv`; exports respect the filters active on the page, and each download is recorded in your audit log.

The section is visible to **admins and managers** only — event managers and door roles don't see it. All figures use your venue's [timezone](/guide/timezone), and every chart has a **View as table** link underneath showing the same numbers as a plain table.

## Sales report

The sales report covers a date range you pick (presets from 7 days to a year, or a custom from/to pair) and shows:

* **Tickets sold per day** and **revenue per day** as line charts.
* **Sales channels** — the split between the *Ticket Office* (online orders) and the tickets you issued yourself, listed by the channel picked when you made them: *Complimentary*, *Manual*, or *Phone*. The CSV export keeps the stored channel values.
* **A per-event breakdown** with per-date lines for multi-date events.

Only *paid* orders count. Pending checkouts and expired holds are excluded, so these figures always match the dashboard and the Tickets pages. Revenue is the ticket price plus any booking surcharge; discounts aren't subtracted here, but the CSV export includes the discount columns so you can reconcile against your Stripe payouts.

Filter the whole report to a single event when you want one show's numbers. **Export CSV** downloads one row per order (date, event, occurrence, buyer, tickets, revenue, channel, discount and its label, and the UTC order time), honouring whatever range and filter you have active.

## Issues report

The issues report is where problems surface:

* **Checkout funnel** — how many orders were reserved, reached payment, and were paid, with a conversion percentage. Expired holds (buyers who walked away) and failed payment attempts appear alongside.
* **Declined payments** — each failed attempt with the card network's reason code (`card_declined`, `insufficient_funds`, and so on). A declined buyer can still retry; a decline row is an attempt that didn't go through, not a lost sale.
* **Open payment exceptions** — the "money captured but no tickets" cases. They surface here with a link; you still review and resolve them on the **Payments** page, and [Payment exceptions](/guide/payment-exceptions) covers what each flag means and how to refund one.
* **Broken links** — public pages of yours that visitors requested but that don't exist (for example an event link shared before the event was renamed), with how often and which site last linked there. Security probes and guesses are deliberately excluded — only genuine dead links appear.

Funnel data exists only from the day the feature went live. Both halves export as CSV.

## Page views report

The page views report shows traffic on your public pages (home, events listing, event pages, and the checkout), including views that happen inside pages you've embedded on your own website. You get a views-per-day trend, your top pages, a direct-versus-embedded split, and a CSV export.

**What Platypus collects, in plain language:** when someone loads one of your public pages, Platypus records the page's address, the day, whether it was inside an embed, and the website that linked them (the site name only). It stores **no cookies, no IP addresses, and no browser fingerprints** — so there's no consent banner, and it works the same inside embeds. "Unique visitors" are estimated per day only: the same person visiting on two different days counts once each day, because nothing links their visits across days.

A few caveats: known crawlers and bots are filtered out, but the filter isn't perfect; your own visits while signed in to the admin aren't counted; and the data starts the day the feature went live, so there's no history before that.

## Mailouts report

The mailouts report lists every campaign sent in the range with its delivered and failed counts and a success rate, plus a per-day delivery trend chart. The numbers come from the same per-recipient tracking recorded when each campaign was sent — nothing new is collected.

For any campaign with failures, **Failures CSV** downloads the failed addresses with their error messages, so you can chase bounces or clean your list.

## Audit log (admins only)

The audit log answers "who did what, when": logins, settings changes, event edits, [Ticket Office](/guide/ticket-office) closures and reopenings, campaign sends, exports, and payment warnings, each with the acting user and time. Filter by level, actor, date range, or message text, and open a row for its full details. The filtered view exports as CSV, and that export is recorded like everything else.

Only the **admin** account can see the audit log: entries include team members' email addresses and connection details, so managers and other roles don't get access. Entries are kept for 12 months. Anything from before the log existed survives only in the platform's short-lived server logs.

If a number here disagrees with Stripe, your bank, or your own records, don't assume you're misreading it — email [support@platypus.tickets](/faq/support) with the report name and the date range you had active.

---

---
url: /guide/mail-settings.md
description: >-
  Choosing the provider that sends your email — Platypus hosted mail vs your own
  Mailgun, Resend, SendGrid, or SMTP account, the From address, what every email
  says about you, the test send, and troubleshooting.
---

# Mail settings

Everything Platypus emails on your behalf goes out through the provider chosen here. Open **Settings** in the admin sidebar and pick the **Mail** tab. New venues start on **Platypus hosted mail**, which needs no setup. **Your email already works.** Come here when you want mail sent through your own provider, from your own domain.

## What Platypus sends for you

* **Ticket confirmations** — the order email with the ticket PDF after a successful [checkout](/guide/stripe-payments)
* **Contact-form messages** — delivered to you when someone uses your public contact page
* **Mailing-list mail** — the double-opt-in confirmation, unsubscribe links, and [campaigns](/guide/mailing-list#sending-a-campaign) when you run your own provider (hosted mail doesn't carry campaigns — see the trade-offs below)
* **Per-event reminder emails**
* **Test emails** — from the button described below

Every one of these uses this page's settings, so if the provider here breaks, they all stop arriving. That's what the test button is for.

## Choosing a provider

Pick one provider; the form shows only the fields that provider needs. Secrets (API keys, passwords) are stored encrypted and never shown again. Leaving a secret field blank on a later save **keeps** the stored value — it doesn't clear it.

Providers differ in more than deliverability: some also expose their **lists, segments, and bounce data** to Platypus, shown as badges under the provider picker. Everything a provider adds beyond *Sending* depends on pasting the right kind of key.

| Provider | What you need | Beyond sending |
| --- | --- | --- |
| **Platypus hosted mail** | Nothing — works out of the box | — |
| **Mailgun** | Your verified sending domain and your **account (private) API key** — a domain sending key (`key-...`) covers sending only | Lists, bounce info |
| **Resend** | A **full-access** API key (`re_...`) — a sending-only key sends and nothing more | Segments, bounce info |
| **SendGrid** | An API key (`SG....`) with **Marketing** scopes — a Mail Send-only key stops at sending | Bounce info; lists shown but not importable |
| **Amazon SES** | Your region's SMTP endpoint plus SES **SMTP credentials**, generated in the SES console — not your IAM keys | — |
| **Mailchimp (Mandrill)** | Your Mailchimp Transactional username and an API key; the host is fixed at `smtp.mandrillapp.com`. A Mandrill key can't reach Mailchimp audiences | — |
| **Custom SMTP** | Host, port (usually `587`), encryption (usually `tls`), username, password | — |

When you save one of the three list-capable providers, Platypus checks what your key can actually reach and shows the result under the picker: that the key is verified for full access, or a note that it can send but can't reach lists. The **Verify connection** button re-runs that check at any time. A key that can't reach lists still sends perfectly well; you only need the stronger key for list features — and for SendGrid those stop short of member import, so [importing that audience](/guide/mailing-list#importing-from-your-mail-provider) means exporting a CSV instead.

**Hosted mail's trade-offs:** messages come from a Platypus address on the platform's sending domain, with your theatre's name as the sender — not from your own address. Replies still reach you, on every email Platypus sends for you (ticket receipts and reminders included): your From address is set as the Reply-To, with your public contact email as the fallback. The hosted-mail note on this tab shows exactly what recipients see, sender name and address, and where a reply lands.

Hosted mail also doesn't carry [email campaigns](/guide/mailing-list#sending-a-campaign): those need your own provider, unless Platypus has configured your account for total hosted email support. When that's in place, a notice on this tab says so, and campaigns ride hosted mail too. Hosted mail is currently unmetered; there's no sending charge. If you want mail from your own domain, pick any of the other providers.

For a provider you run yourself, your From address must be one that provider lets you send as — the API providers generally require your domain to be verified with them first.

## The From address

The **From address** and **From name** are always required, whichever provider you pick — a save with a missing or invalid email is rejected. This is the sender your audience sees on every message (and, on hosted mail, where replies go). Use an inbox someone actually reads: contact-form messages and confused ticket buyers end up there.

## What every email says about you

Every email Platypus sends on your behalf ends with the same short block: your **Organisation Name** (your venue name until you set one), your ABN when set, whichever of your public contact email, phone, and address you've filled in, and the line *Sent via Platypus Tickets on behalf of your venue*. Receipts, reminders, opt-in confirmations, unsubscribe links, campaigns, and the test email all carry it, in the HTML and in the plain-text version every email now has.

That block is the Spam Act 2003's sender-identification rule (s17) made concrete: a commercial email must name the business that authorised it and give a way to reach that business that stays valid for 30 days. The organisation name and ABN come from **Settings → General**, the contact details from **Settings → Contact**. Ticket emails always go out; a [campaign](/guide/mailing-list#sending-a-campaign) waits until the organisation name and a contact email (or the From address) are set.

## Send a test email

At the bottom of the Mail tab, enter a recipient address and press **Send test email**. Platypus sends a fixed test message with a generated PDF attached, so one send proves delivery *and* attachments work. The test uses your **saved** settings — save first, because it ignores unsaved form changes.

The page reports success, or the provider's actual error message if the send was rejected. On hosted mail, if the platform's mailer isn't set up for real delivery, you get a clear *hosted mail is not configured for delivery* error instead of a false success.

## Troubleshooting

| Symptom | Likely cause | Fix |
| --- | --- | --- |
| Test send shows a provider error about credentials | Wrong, revoked, or rotated key/password | Re-enter the secret, save, test again |
| Save rejected naming a credential field | The selected provider requires it and nothing is stored yet | Fill in that field |
| Secret field is empty when you revisit the page | Secrets are never redisplayed | Normal — blank keeps the stored value; type a new one only to replace it |
| Test still behaves like the old settings | The test uses saved settings, not the form | Save your changes, then test |
| *Hosted mail is not configured for delivery* | Platform-side mail isn't set up — not your configuration | Report it to Platypus, or switch to your own provider |
| Mail arrives from a Platypus address, not yours | That's how hosted mail works | Switch to Mailgun, Resend, SendGrid, or SMTP with your own domain |
| A campaign send is refused asking for your organisation name or a contact email | The sender-identity check (Spam Act s17) | Fill **Organisation Name** under **Settings → General** and **Public Contact Email** under **Settings → Contact**, then send again |
| SES rejects the login | IAM access keys used instead of SMTP credentials | Generate SMTP credentials in the SES console |
| Save reports the key can send but can't reach lists | The key is send-scoped (Mailgun domain sending key, Resend sending-only key, SendGrid key without Marketing scopes) | Sending still works; paste the stronger key type only if you want list features |
| Nothing arrives, no errors shown | Provider config broke since it last worked, or spam filtering | Run a test send; check the recipient's spam folder; confirm your domain is verified with the provider |

If the test send succeeds but one kind of email still goes missing, the sending feature's own guide is the next stop: [contact form](/guide/contact-form), or [mailing list & campaigns](/guide/mailing-list). Anything this table can't explain is worth reporting — email [support@platypus.tickets](/faq/support).

---

---
url: /guide/subscription-and-billing.md
description: >-
  Your Platypus subscription — plans, the per-ticket fee and its price bands,
  managing payment and invoices, and what the subscription does (and doesn't)
  control.
---

# Subscription & billing

Platypus bills your venue a subscription for platform access, plus **$1 AUD per ticket sold**. Your subscription is with Platypus Tickets Pty Ltd (ABN 62 702 006 399). This page covers paying Platypus. Taking money from your ticket buyers is separate — that's [Stripe payments setup](/guide/stripe-payments).

## Plans

| Plan | What you pay |
| --- | --- |
| **Monthly** | A flat base fee each month, plus the per-ticket fee |
| **Yearly** | $50 AUD per year, plus the per-ticket fee (still billed monthly) |

The per-ticket fee is metered on paid tickets only — [free ticket types](/guide/setting-up-an-event) are never counted. The subscribe screen shows the exact base fee before you commit. There's no trial period: Platypus charges the first invoice the moment you subscribe.

## The per-ticket fee

The fee is a flat dollar amount per ticket, never a percentage of your ticket price. Which amount applies is decided by a schedule of price bands: each band covers a range of ticket prices and carries its own flat fee, judged on the full amount the buyer pays for that ticket (your ticket price plus any per-ticket surcharge). The current schedule is one band — **$1 AUD at every ticket price** — and is published in the [pricing section at platypus.tickets](https://platypus.tickets/#pricing).

If the schedule changes, the new fees apply from the next ticket sold. Tickets already sold are never re-billed, and your monthly invoice lists the metered usage against each fee it was sold under.

## Subscribing

**Account and Billing** in the admin sidebar shows your subscription state. If you're not subscribed, pick a plan and click **Subscribe**: Platypus sends you to a Stripe-hosted checkout to enter card details, then returns you to the billing page. (If the panel says billing isn't configured yet, that's on the Platypus operator, not you.)

## Managing it

The **billing portal** button hands you to Stripe's hosted portal for everything ongoing: changing your card, viewing and downloading invoices, or cancelling. If you cancel, the subscription runs to the end of the paid period.

## What the subscription controls — honestly

The subscription pays for your platform access. It is **not** a switch on the Ticket Office:

* Paid ticket checkout works when your [Stripe keys are configured](/guide/stripe-payments); free ticket types are claimable without Stripe at all.
* Platypus meters the per-ticket fee against your subscription as paid tickets sell. Free tickets are never counted.
* Deactivating your venue's account is an operator action, never an automatic consequence of a lapsed card. If it happens, your public pages and admin return "not found" until the account is reactivated; payments already in flight still complete and issue tickets.

If you're winding down, cancel the subscription **and** email [support@platypus.tickets](/faq/support) about the account itself.

---

---
url: /guide/stripe-payments.md
description: >-
  Connecting your Stripe account so the Ticket Office can take payments on your
  behalf — keys, webhook, test mode, go-live checklist, and troubleshooting.
---

# Stripe payments setup

Ticket money goes **straight to your venue's own Stripe account**. Platypus initiates the payment with your keys and never holds your funds. Until Stripe is connected here, paid ticket types can't be bought; an event with [free ticket types](/guide/setting-up-an-event) still shows its **Buy tickets** button, offering the free types only.

You'll need a [Stripe account](https://stripe.com) with its business details activated (a free account in test mode is enough to rehearse). Open **Payments** in the admin sidebar; the page walks you through three steps — about five minutes.

While you're setting up payments, the page also nudges you to fill in your **ticket terms & refund policy** and **ABN** under Settings. Buyers see the policy at checkout and the ABN on receipts (see [Business identity](/guide/business-identity)). Selling works either way; the nudge tells you what buyers aren't seeing yet.

## 1. Create a restricted key in Stripe

In your Stripe dashboard: **Developers → API keys → Create restricted key**. A restricted key can only do what the Ticket Office needs, which makes it much safer than a full secret key. Grant exactly:

| Permission | Level | Why |
| --- | --- | --- |
| Payment Intents | Write | takes payments |
| Account | Read | confirms the connection and shows your account name |
| Webhook Endpoints | Write | lets Platypus set up payment confirmation for you |

Leave everything else on **None**. (A full secret key `sk_live_...` works too, but restricted is recommended — it limits what could go wrong if the key ever leaked.)

## 2. Paste your keys

* **Publishable key** — `pk_live_...` (or `pk_test_...` while testing). Safe to share; it only identifies your account.
* **Secret key** — the restricted key you just created (`rk_live_...`). Stored encrypted, never shown again.

Platypus verifies the secret key against Stripe when you save: a rejected key is never stored, and a successful save shows your Stripe account name on the page. Both keys must be from the same mode (both live, or both test).

## 3. Set up payment confirmation (webhook)

When a payment goes through, Stripe tells Platypus so the tickets are issued and emailed. That link is a webhook:

* **Automatic (recommended):** click **Set up automatically**. Platypus creates the endpoint on your Stripe account and stores its signing secret. Done.
* **Manual** (if your key lacks Webhook Endpoints permission): in Stripe, **Developers → Webhooks → Add endpoint**; paste the endpoint URL shown on the Payments page, select exactly the events `payment_intent.succeeded`, `payment_intent.canceled`, and `payment_intent.payment_failed`, then copy the endpoint's signing secret (`whsec_...`) back into the Payments page.

A missing webhook **warns but doesn't close the Ticket Office** — payments still verify at the end of checkout. Set it up anyway: it's the safety net that issues tickets if a buyer's connection drops at the wrong moment.

## 4. Verify

The status card shows the connected account, a **LIVE**/**TEST MODE** badge, and the webhook state. **Test connection** re-checks at any time without re-entering keys.

## Test keys vs live keys

Rehearse with your Stripe **test** keys (`rk_test_`/`pk_test_`) — checkout then accepts only [Stripe's test cards](https://docs.stripe.com/testing) such as `4242 4242 4242 4242`. Buy a ticket yourself and confirm the order completes and the ticket PDF arrives by email.

**Switching between test and live keys clears the stored webhook** (Stripe webhooks are per-mode). Re-run **Set up automatically** after the switch.

## Go-live checklist

* \[ ] Live restricted key (`rk_live_`) and live publishable key (`pk_live_`) saved
* \[ ] Webhook state shows **Automatic ✓** (or **Manual ✓**) — re-done after the test→live switch
* \[ ] **Test connection** shows your account name with a **LIVE** badge
* \[ ] **Buy tickets** button visible on a public event page

## When a payment needs attention

Very occasionally Stripe captures a buyer's money but Platypus can't (or shouldn't) issue the tickets. When that happens, **you're emailed straight away**, a red banner appears at the top of the **Payments** page with the affected orders listed underneath, and the Payments item in the sidebar carries a warning triangle until everything is dealt with. [Payment exceptions](/guide/payment-exceptions) covers what each flag means, how to refund from your Stripe dashboard, and when to mark a row resolved.

## Troubleshooting

| Symptom | Likely cause | Fix |
| --- | --- | --- |
| No **Buy tickets** button on the event page | Keys missing and no free capacity, the event has no purchasable capacity, or the Ticket Office is closed | Complete steps 1–2; check the event's ticket types are published with capacity ([free types](/guide/setting-up-an-event) sell without keys); reopen the [Ticket Office](/guide/ticket-office) if you closed it |
| Save rejected with a Stripe error naming a permission | Restricted key missing that permission | Edit the key in Stripe (Developers → API keys), add it, then **Test connection** |
| **Set up automatically** fails with a permission message | Key lacks Webhook Endpoints: Write | Add the permission, or use the manual path in step 3 |
| Real card declined at checkout | Test keys still configured | Save your live keys, re-run webhook setup |
| Payment succeeded but tickets not confirmed / webhook errors in Stripe | Wrong or stale signing secret, wrong endpoint URL, or wrong events | Re-run **Set up automatically**; if manual, confirm the URL and the three exact events, re-paste the `whsec_` |
| **Test connection** fails after previously working | Key rolled or deleted in Stripe | Create a new key and save it on the Payments page |
| "Stored key unreadable — re-enter your keys" | Platform-side key rotation | Paste your keys again |
| Webhook auto-setup reports an endpoint limit | Stripe's 16-endpoints-per-account cap | Delete unused endpoints in Stripe (Developers → Webhooks) and retry |

A failure the table doesn't explain is worth reporting — email [support@platypus.tickets](/faq/support) with what the status card shows and the time it happened.

---

---
url: /guide/payment-exceptions.md
description: >-
  Payment exceptions — what each flag on the Payments page means, how to refund
  the buyer in Stripe, and when to mark the record resolved.
---

# Payment exceptions

**A payment exception is money captured without the tickets to match.** It happens in the rare gap between a buyer paying and Platypus issuing tickets — the checkout hold expired, or the event was cancelled while the payment was in flight. Platypus quarantines the order, records exactly what happened, and emails you. Nothing here fixes itself: **the refund is yours to make, in your own Stripe dashboard**, because the payment sits in your venue's Stripe account.

Open records appear on the **Payments** page — a banner, a table with one row per exception, and a warning marker in the sidebar until they're dealt with.

## What each exception means

The table names each record with one of five labels:

| Label on the Payments page | What happened | Were tickets issued? |
|---|---|---|
| *Payment on an expired hold* | The buyer paid after their checkout hold had already expired and the seats had been released | No |
| *Payment on a cancelled event* | The payment landed for an event that was cancelled in the meantime | No |
| *Payment on a cancelled date* | Same, for one cancelled date of a multi-date event | No |
| *Payment less than the priced amount* | Stripe captured less than the order's price — Platypus refuses to issue underpaid tickets | No |
| *Payment exceeds the priced amount* | Stripe captured more than the order's price | **Yes** — tickets went out normally |

The first four are quarantines: the buyer paid and got nothing, and is owed the full amount back. The last one is the opposite — the tickets are fine, and the buyer is owed the difference.

## Refunding the buyer

Each row shows the Stripe **PaymentIntent id** (it looks like `pi_…`). That id is the bridge between Platypus and your Stripe dashboard:

1. In Stripe, open **Payments** and paste the PaymentIntent id into the search box. The matching payment opens with the buyer's card and amount.
2. Choose **Refund**. For the four quarantine kinds, refund the **full amount**. For *Payment exceeds the priced amount*, refund **only the difference** — the row shows both the captured and priced amounts, so the gap is arithmetic, not judgement.
3. Stripe returns the money to the buyer's card on its usual refund timeline — days, not minutes, so tell the buyer not to watch their banking app.

Refunds made in test mode against test cards behave the same way, so you can rehearse this whole procedure before it ever matters.

## What to tell the buyer

The buyer already knows something is off — for a quarantined order, checkout ended in an error (or went silent) after their card was charged. A short email closes it out:

* **Quarantine kinds** — tell them the payment has been refunded in full, why the order couldn't be completed (their hold expired; the event or date was cancelled), and, if the show is still on sale, that they're welcome to buy again. The rebuy is a fresh order; Platypus can't revive the quarantined one.
* **Overpayment** — tell them their tickets stand and the difference has been refunded. Nothing else changes for them.

## Mark it resolved

Once the refund is done (or you've reviewed the record and decided none is owed), use **Mark resolved** on the row. The record moves out of the open list, the sidebar warning clears, and the resolution is stamped with who did it. **Resolving is one-way**: there's no reopen, so resolve after the money has actually moved, not before.

## Two sharp edges

* **Refunding never cancels tickets.** A refund in Stripe doesn't reach back into Platypus: if you refund an ordinary fulfilled order (not a quarantine — those have no tickets), the PDF still scans at the door. If you refund a ticket holder, cross the name off the door sheet.
* **Exceptions don't expire.** An ignored record stays open, and stays on the Payments page, indefinitely. The buyer's bank may eventually force the issue as a dispute — dealing with it on your terms first is cheaper.

Something on the Payments page that doesn't match this description, or a payment you can't trace? Email [support@platypus.tickets](/faq/support) with the PaymentIntent id and your venue address — tracing captured-but-unfulfilled payments is one of the things support is for.

---

---
url: /guide/business-identity.md
description: >-
  Your ABN and ticket terms & refund policy — where to set them and where buyers
  see them.
---

# Business identity

Two optional fields under **Settings → General** put your business identity in front of buyers where Australian Consumer Law expects to find it: **ABN** and **Ticket Terms & Refund Policy**. **Selling works without them.** Until they're set, the **Payments** page reminds you what buyers aren't seeing.

## Ticket terms & refund policy

Your ticket terms are a plain-text statement of your refund, exchange, and entry conditions. Once saved, the statement appears in three places:

* On its own public page at `/t/your-venue/terms`, linked from your site footer.
* In the declaration buyers tick at checkout ("…and accept the *your venue* ticket terms").
* Linked from the payment-failed screen and from every buyer receipt.

Write it as plain text: line breaks are kept, and formatting isn't needed. The one thing the policy can't override is Australian Consumer Law — if a buyer's event is cancelled, they're entitled to a remedy regardless of what your policy says, so don't write a policy that pretends otherwise.

Leave it blank and buyers see the platform's [buyer terms](https://platypus.tickets/buyer-terms) alone — no dead links anywhere.

## ABN

The ABN field takes your 11-digit Australian Business Number and prints it in the seller block of every buyer receipt ("Sold by: … · ABN …"). Receipts for sales over $75 should carry it.

## The receipt

Every confirmed order emails the buyer a receipt alongside their ticket PDF. The seller block carries your organisation name, venue address, ABN, and contact email exactly as saved in **Settings → General**, and links your ticket terms when you've set them. A free order gets the same receipt with the payment line replaced by a note that no payment was required — the seller block is identical, so your ABN still appears. [Tickets and delivery](/guide/tickets-and-delivery) covers the rest of what that email contains.

## Your name in every email

The receipt is not the only place your identity prints. Every email Platypus sends for you, from opt-in confirmations to campaigns, ends with your organisation name, your ABN when set, your public contact details, and a line saying it was sent via Platypus Tickets on your behalf. That is the Spam Act 2003's sender-identification rule: a commercial email must name the business that authorised it and give a way to reach that business. Until you set an organisation name, emails name your venue instead, and [campaigns](/guide/mailing-list#sending-a-campaign) wait; ticket emails always go out. [Mail settings](/guide/mail-settings#what-every-email-says-about-you) shows the block in full.

If what buyers see doesn't match what you've saved, tell us: email [support@platypus.tickets](/faq/support).

---

---
url: /guide/timezone.md
description: >-
  The venue timezone — where to set it, the day-boundary decisions it drives,
  reminder due days, and touring stops that carry their own zone.
---

# Timezone

Your venue has one timezone, set in **Settings → General → Timezone**. On nearly every surface it controls one thing: **which day it currently is at your venue**. Two exceptions read the wall clock — discount validity windows and scheduled Ticket Office closures, both covered below. Platypus stores every date and timestamp in UTC and never converts your event dates or times; the timezone decides where "today" starts and ends, and every decision that compares an event date against today uses your local day, not the UTC one.

## Setting it

The field is a dropdown of the Australian timezones plus UTC. Until you pick one, your venue runs on the platform default (`Australia/Sydney`), and the Settings page shows that effective value rather than a blank — venues set up before this field existed have always classified their days correctly without anyone touching it. A value outside the offered list is rejected on save.

Changing it takes effect straight away: every day-boundary decision from that moment uses the new zone. Nothing stored is rewritten.

## What runs on your local day

* **The public listing** — your events grid and event API show events dated today or later. An event drops off at your local midnight, not at UTC midnight. Cancelled events follow the same rule: marked and unsaleable, but listed until their date passes (see [Cancelling events](/guide/event-lifecycle)).
* **The "next performance" date** — a multi-date event is presented under its earliest non-cancelled stop dated on or after your local today.
* **Upcoming and past in the admin** — the dashboard and the Events index split on the same local today as the public site, so all three always agree about which side of midnight an event sits on.
* **Checkout on multi-date events** — a stop whose date has already passed on your clock can't be opened for checkout or reserved.
* **Door check-in** — a ticket scans on its performance day and the following day, judged on your clock (see [Door check-in](/guide/door-checkin)).
* **Reminder due days** — the days-before countdown runs against your local today; details below.
* **Reports** — charts bucket sales by your local day, and range presets end on your local today. Daylight-saving transitions don't smear the buckets: each sale's timestamp is converted exactly. Page views are recorded against your local day too.
* **Discount windows** — wall-clock time, not a day boundary: a discount's start and end are interpreted in your timezone, so a window that ends at 23:59 ends at *your* 23:59.
* **Scheduled Ticket Office closures** — the other wall-clock decision. A closing time is entered and shown in your timezone and takes effect at that exact moment for every buyer; the automatic close after a single-date event's day is a day-boundary rule like the rest (see [Ticket Office](/guide/ticket-office)).

A concrete case: at 1:30 am on 14 July in Sydney, the UTC clock still reads 13 July. A Sydney venue's event dated 13 July is already past — off the public listing and out of the admin upcoming list, hours before UTC midnight arrives.

## Does changing the timezone move my events?

No. Event dates, time labels, and sale timestamps stay exactly as you entered them; a 7:30 pm show stays a 7:30 pm show. The setting moves the day boundary those values are compared against, nothing else. Switching from Sydney to Perth shifts no dates, but for a few hours around midnight it can change whether today's event still counts as upcoming.

## Reminders and the due day

A [reminder email](/guide/setting-up-an-event) goes out when an event's date is exactly its days-before offset from today — and "today" here is your venue's local today, so the reminder lands on the calendar day you'd expect rather than the UTC one.

For a multi-date event, each stop is judged independently on its own due day, and each stop reminds only its own ticket buyers.

## Touring stops carry their own zone

Each venue in your **Venues** directory carries a timezone, chosen from the same list as the setting. When a stop of a multi-date event pulls a venue from the directory, that venue's timezone is snapshotted onto the stop along with its address, so a later edit to the venue record can't rewrite a date that has already sold. Remove the venue from a stop and the stop falls back to your venue timezone; delete the venue record entirely and existing stops keep the zone they were sold under.

The snapshot decides one thing: that stop's reminder due day is evaluated in the stop's own timezone, so a Perth date on a Sydney venue's tour reminds on Perth's calendar. The listing cutoff, the next-performance date, and the check-in window all stay on your venue's clock.

## If a day boundary looks wrong

| Symptom | Likely cause | Fix |
| --- | --- | --- |
| Events drop off the public listing hours early or late | Timezone unset or wrong, so midnight falls at the default's boundary | Set your zone in **Settings → General → Timezone** |
| Today's event shows under *Past* in the admin | The configured zone's midnight arrives earlier than yours | Correct the setting; the lists reclassify immediately |
| One stop of a tour reminded on the wrong day | The stop snapshotted a venue with a different timezone | Check that venue's timezone under **Venues**, then re-pick it on the stop |

If the day boundary still misbehaves with the right zone set, that's a bug — email [support@platypus.tickets](/faq/support) with the event date, your timezone setting, and when the wrong behaviour happened.

---

---
url: /guide/account-security.md
description: >-
  Protecting your admin account — changing your password from inside the admin,
  setting up multi-factor authentication with an authenticator app, recovery
  codes, and what to do if you're locked out.
---

# Account security

Your admin login guards real money and your customers' details, so it gets its own page in the admin: open **Security** in the sidebar. Everything here is about *your own* account, split across two tabs — **Password** for changing your password, and **Multi-factor setup** for multi-factor authentication (MFA). Managing your team's logins lives in [Team users](/guide/team-users).

Until MFA is set up, the Security item in the sidebar carries a small warning triangle. That's deliberate nagging: **a password alone is one phishing email away from being someone else's password.** Clicking the nagged item lands you straight on the Multi-factor setup tab.

## Changing your password

On the **Password** tab, fill in your current password and the new one, then save with the bar at the top. A new password needs at least 12 characters with an uppercase letter, a lowercase letter, a numeral, and a symbol, and Platypus refuses passwords that have turned up in public breaches — the same bar every login on your venue has to clear. The change applies immediately: you stay logged in on this device, and every other device still signed in as you is logged out the next time it does anything.

If you've forgotten your password, use **Forgot password?** on the login page instead — the emailed reset link stays valid for 3 days.

## Setting up multi-factor authentication

MFA adds a second step to logging in: a six-digit code from an authenticator app on your phone (Google Authenticator, Microsoft Authenticator, 1Password, Aegis — anything that speaks TOTP).

1. On the Security page's **Multi-factor setup** tab, confirm your password and choose **Set up authenticator app**.
2. Scan the QR code with your app (or type in the setup key shown under it).
3. Enter the six-digit code the app shows and choose **Confirm and activate**.

MFA is **not active until you confirm**. If you wander off halfway, nothing changes, and you can start again later.

### Recovery codes

The moment you confirm, Platypus shows a set of **recovery codes** — one-time passwords for the day your phone is lost, dead, or in a taxi. **They are shown only once.** Store them somewhere that isn't the phone: a password manager or a printed page in a drawer.

Each code works exactly once at the login screen. To replace them, confirm your password and choose **Generate new recovery codes** on the Multi-factor setup tab; every code in the old set stops working the moment the new set appears.

## Logging in with MFA

After MFA is active, logging in asks for your email and password as usual, then for the current code from your authenticator app. Lost the device? Choose **Lost your device? Use a recovery code** on that screen and spend one of your recovery codes instead.

## Turning MFA off

On the Multi-factor setup tab, confirm your password under **Turn off multi-factor authentication**. Logins go back to password-only, and the sidebar warning returns. The old QR code stops working; setting MFA up again later generates a fresh secret.

## Locked out completely?

If you've lost both the authenticator device *and* your recovery codes, [contact Platypus support](/faq/support). An operator can clear MFA on your account (the action is logged in your venue's audit trail), after which you log in with your password and can re-enrol from the Security page. Your password itself can always be reset by email from the login page, so no one else who uses your admin can lock you out of your own account.

---

---
url: /guide/team-users.md
description: >-
  Sharing the admin with your team — the five roles and what each can do,
  inviting users by email, deactivating vs deleting, setting or resetting a
  teammate's password or MFA, and why the admin account can never be locked out.
---

# Team users

You don't have to hand your admin password to whoever runs the door on Friday. **Everyone who helps run your venue can have their own login**, scoped to what they actually do: open **Users** in the admin sidebar to set them up. Each action they take is recorded in your venue's audit trail under their own name.

The Users area is visible to the **admin** (you) and to **managers**. Other roles never see it.

## The roles

| | Admin | Manager | Event manager | Door manager | Door staff |
| --- | :-: | :-: | :-: | :-: | :-: |
| Events (create, edit, cancel, close or reopen the Ticket Office) | ✓ | ✓ | ✓ | – | – |
| Tickets & door sheets | ✓ | ✓ | ✓ | view only | one event, view only |
| Mailing list & campaigns (incl. sending) | ✓ | ✓ | ✓ | – | – |
| Venues | ✓ | ✓ | ✓ | – | – |
| Settings | ✓ | ✓ | – | – | – |
| [Reports](/guide/reports) (sales, page views, mailouts, issues) | ✓ | ✓ | – | – | – |
| Audit log | ✓ | – | – | – | – |
| Payments & Billing (incl. closing the account) | ✓ | – | – | – | – |
| Invite & manage users | ✓ | ✓ | – | – | – |

* **Admin** — the account created when your venue was set up. There is exactly one, and it can do everything. Only the admin can change Stripe payment settings, manage the Platypus subscription, or close the account (cancelling the subscription from the billing portal).
* **Manager** — everything an admin can do except payments, billing, the audit log, and touching the admin account itself. Managers can invite and manage users of any role below admin, including other managers.
* **Event manager** — runs the programme: events, tickets, door links, and the mailing list, including sending campaigns. No access to settings, payments, billing, reports, or users.
* **Door manager** — sees ticket sales and door sheets, and nothing else; no create or edit anywhere, and never event cancellation. Handy for front-of-house volunteers.
* **Door staff** — like a door manager, but for **one assigned event only**: its ticket sales, its door sheets, nothing else. If their event is deleted they keep their login and land on **About**, where a notice asks them to get an admin or manager to pick their next event. This is the role for the volunteer who's there for one show night.

Anything a role can't do isn't shown: a door manager's sidebar has no Settings, no Mailing list, and nowhere to create an event. Every user gets a **Security** page for their own password and [multi-factor authentication](/guide/account-security).

## Inviting someone

In **Users**, fill in their name, email address, and role, and send the invitation. Choosing **Door staff** reveals a **Their event** select: pick the show they're working — the invitation won't send without one, and you can reassign the event later from their row. The new user gets an email link and sets their own password: you never know it, they never know yours. The link stays valid for 7 days, and the **Send set-password link** row action issues a fresh one any time; it doubles as a password reset if they're locked out.

One login per email address per venue. If someone leaves and comes back, reactivate their old user rather than creating a twin.

## Deactivate, delete, and rescue

Each row's action menu lets you (or a manager):

* **Deactivate** — access ends immediately (their next click logs them out). Reversible; their history stays intact. Prefer this over deleting for anyone who might return.
* **Delete** — removes the login permanently.
* **Send set-password link** — a fresh email link; works as both invitation re-send and password rescue.
* **Set password** — type a new password for them yourself, for when the email route won't work (a volunteer with no inbox access half an hour before doors). A strength meter and checklist guide you through the [password requirements](/guide/account-security). It takes effect immediately and signs them out everywhere else. Share it securely, and encourage them to change it from their own Security page, since a password you know isn't really *theirs*.
* **Reset MFA** — clears a teammate's multi-factor authentication if they've lost their phone *and* their recovery codes. They log in with password only and re-enrol from their Security page.

## The admin account is untouchable

No manager can edit, deactivate, delete, or reset the admin account. No one at all can. Only you manage your own credentials, from your [Security page](/guide/account-security). With email password reset and MFA recovery codes on top, no delegate action can ever lock you out of your own theatre.

If a teammate still can't get in after a fresh set-password link and a direct **Set password**, email [support@platypus.tickets](/faq/support) with their address.

---

---
url: /guide/appearance.md
description: >-
  The Settings > Appearance tab — writing custom CSS for your public pages, the
  stable selector contract (page IDs, layout hooks, repeating classes), and the
  disableCustomCss debugging switch.
---

# Appearance & custom CSS

Your public pages ship with Platypus's warm light theme. When you'd rather they match your own site (colours, fonts, spacing, hiding a block), open **Settings** in the admin sidebar and pick the **Appearance** tab. The **Custom CSS** field there applies to **every public page**, including [embedded pages](/api/embeds) shown inside an iframe on your own website.

## The Custom CSS field

* One stylesheet, up to **20,000 characters**, written straight into the field.
* Platypus injects it into every public page **after** the theme's own styles, so your rules win over the defaults without `!important` gymnastics.
* It never touches the admin — only public pages (home, events, event detail, subscribe, contact, checkout) and embeds.
* The literal sequence `</style` is rejected on save: the stylesheet renders inside a `<style>` block, so a closing tag can't be smuggled in. Everything else is your CSS, verbatim.
* The *About this section* panel on the **Appearance** tab documents these same hooks in accordions, so the reference sits right where you type.

## Seeing a page without your CSS

To see any public page without your stylesheet, add `?disableCustomCss=1` to its URL. The switch affects that single request and stores nothing; remove the parameter and your CSS is back. Use it to tell "my rule did this" apart from "the theme did this".

## The selector contract

These IDs and classes are **stable hooks**: they carry no styling of their own and won't be renamed, so CSS you write against them keeps working across Platypus updates.

### Page identifiers

The outer wrapper of every public page carries `id="page-<slug>"`, so you can scope a rule to a single page — that page's nav and footer included:

| Page | ID |
| --- | --- |
| Home | `#page-home` |
| Events listing | `#page-events` |
| Event detail | `#page-event-detail` |
| Subscribe / confirmation | `#page-subscribe`, `#page-subscribe-confirmed` |
| Unsubscribe / confirmation | `#page-unsubscribe`, `#page-unsubscribe-confirmed` |
| Contact | `#page-contact` |
| Checkout | `#page-checkout` |
| Ticket terms | `#page-terms` |
| Embedded cards | `#page-embed-details`, `#page-embed-tickets` |

```css
/* A different footer on the home page only */
#page-home #site-footer {
    background: #1d3a2a;
}
```

### Layout hooks (every full page)

| Hook | Element |
| --- | --- |
| `#site-nav` | Navigation bar |
| `#site-brand` | Brand / logo link |
| `#site-main` | Main content region |
| `#site-footer` | Footer |
| `#site-attribution` | The "Ticketing by Platypus Tickets" line inside the footer |
| `.site-nav-link` | Each navigation link |

The two card embeds carry no chrome, so inside them only the page ID and the card hooks below match.

### Unique page elements

| Hook | Element |
| --- | --- |
| `#home-intro`, `#home-links` | Home intro copy and link-card block |
| `#events-header` | Events listing header |
| `#event-main`, `#event-sidebar`, `#event-description` | Event detail columns and description |
| `#tickets-card`, `#event-details-card`, `#event-dates-card` | Event detail cards |
| `#buy-tickets-button` | The purchase button |
| `#ticket-office-notice` | The notice shown while online sales are closed |
| `#ticket-office-closing` | The "Online sales close …" line while a closure is scheduled |
| `#subscribe-card`, `#subscribe-form`, `#subscribe-confirmed-card` | Subscribe pages |
| `#unsubscribe-card`, `#unsubscribe-form`, `#unsubscribe-confirmed-card` | Unsubscribe pages |
| `#contact-form`, `#contact-details` | Contact page |

### Repeating elements

| Hook | Element |
| --- | --- |
| `.ticket-batch` | Each ticket-type row on an event detail page |
| `.home-link-card` | Each link card on the home page |
| `.contact-detail-item` | Each contact detail on the contact page |
| `.ev-card`, `.ev-row`, `.ev-grid`, … | The events listing's `ev-*` family (cards, rows, grid, filters, pills) |

```css
/* Round every event card and hide the category pills */
.ev-card {
    border-radius: 1rem;
}
.ev-pill {
    display: none;
}
```

## How this interacts with the theme

The public theme is fixed to light mode and scoped to public pages. Your custom CSS loads after it, so anything you write overrides the theme; leave the field empty and pages use the theme as-is. Embeds follow exactly the same rules: style it once here and the pages match everywhere they're shown. When a page looks wrong and you can't tell whose rule is responsible, `?disableCustomCss=1` settles it. A hook that's stopped matching is a bug in the contract — email [support@platypus.tickets](/faq/support).

---

---
url: /api.md
description: >-
  The Platypus.Tickets public event API — base URL, response format, what is and
  isn't supported, and CORS rules.
---

# Introduction

Platypus exposes a **small, read-only public API** for event data. It exists so you can show a venue's events on the venue's own website — typically feeding a custom listing, or sitting alongside the [iframe embeds](/api/embeds).

## Base URL

Every endpoint lives under the venue's tenant prefix:

```
https://platypus.tickets/t/{slug}/api/
```

`{slug}` is the venue's tenant slug — the same one that appears in its public event pages (for example `nbt` in `https://platypus.tickets/t/nbt/events`).

There is **no authentication**. The API returns only data that is already public on the venue's event pages.

## Response format

Responses use a JSON:API-**style** document structure: resources carry `type`, `id`, `attributes`, and `links`; attribute names are `snake_case`; collection responses add top-level `data`, `links`, and `meta`.

It is deliberately not a full [JSON:API](https://jsonapi.org/) implementation. To save you reading the spec against reality:

| JSON:API feature | Supported? |
| --- | --- |
| `type` / `id` / `attributes` / `links.self` resource shape | Yes |
| `application/vnd.api+json` media type | No — responses are plain `application/json` |
| `?include=` compound documents | No — occurrences are always embedded inline |
| `?filter[...]=` | No |
| `?sort=` | No |
| `?page[size]=` | No — page size is fixed at 12 |
| `?page=` (Laravel-style page number) | Yes, on the index endpoint |

## Pagination

The index endpoint returns 12 events per page with Laravel's standard pagination envelope: `links.first/last/prev/next` and `meta.current_page/last_page/per_page/total` (plus `meta.links` for rendering pagers). Request further pages with `?page=2`.

## Visibility

The API applies the same visibility rules as the public event listing:

* Only **published** events appear. Drafts never do.
* **Private** events (unlisted, password-protected pages) never appear — not in the index, not by id.
* **Cancelled** events remain visible, with `publish_status: "cancelled"` and a `cancellation_reason`. If the venue chose to hide the cancelled listing, the API hides it too: the index omits it, and the show endpoint responds `404`.
* Past-dated events drop off the index.

## CORS

Browsers may call the API from exactly two origins: the Platypus site itself, and the venue's own configured website domain — the **Site Domain** in the venue's admin settings (served as `https://{site-domain}`). Requests from any other origin get no `Access-Control-Allow-Origin` header, so the browser blocks them. Each venue's allowance applies only to its own `/t/{slug}/` paths.

If you're building for a venue and hitting CORS errors, the venue admin needs to set the Site Domain to the domain your page is served from — see [Embedding on your site](/api/embeds#site-domain).

## Endpoints

The whole API is two endpoints:

| Method | Path | Purpose |
| --- | --- | --- |
| `GET` | `/t/{slug}/api/events` | Published, listed events (paginated) |
| `GET` | `/t/{slug}/api/events/{id}` | One event by numeric id |

Full detail and real request/response examples: [Event endpoints](/api/events).

**These examples can't drift.** The JSON in this section is fixture files asserted byte-for-byte by the Platypus test suite against real API responses; if the API changes shape, the build fails until the examples are regenerated. The wider accuracy contract is in [About these docs](/faq/about-these-docs).

---

---
url: /api/events.md
description: >-
  The two public event endpoints — list events and fetch one event — with real
  request and response examples.
---

# Event endpoints

**Both endpoints are unauthenticated, read-only `GET`s**, scoped to one venue by the `{slug}` path segment. The JSON below comes straight from test-asserted fixtures: real API output, not hand-maintained examples.

## List events

```
GET /t/{slug}/api/events
```

Returns the venue's publicly listed events, soonest first, 12 to a page: published events plus cancelled events the venue still lists, dated today or later in the venue's timezone. Responses are wrapped in the pagination envelope described in the [introduction](/api/#pagination).

```bash
curl -s https://platypus.tickets/t/nbt/api/events
```

```json
{
    "data": [
        {
            "type": "events",
            "id": "1",
            "attributes": {
                "title": "An Evening of One-Act Plays",
                "slug": "an-evening-of-one-act-plays-2030-03-14",
                "category": "Drama",
                "event_date": "2030-03-14T00:00:00.000000Z",
                "event_time": "19:30:00",
                "date_mode": "single",
                "occurrence_count": 0,
                "next_occurrence": null,
                "occurrences": [],
                "description": "Four short plays from local writers, performed back to back with one interval.",
                "location": "Main Stage",
                "over_18": false,
                "publish_status": "published",
                "tickets_enabled": true,
                "show_images": true,
                "small_image_path": null,
                "cancellation_reason": null,
                "cancelled_at": null,
                "ticket_office": {
                    "status": "open",
                    "reason": null,
                    "closes_at": null,
                    "closed_at": null,
                    "message": null
                }
            },
            "links": {
                "self": "https://platypus.tickets/t/nbt/api/events/1"
            }
        },
        {
            "type": "events",
            "id": "2",
            "attributes": {
                "title": "The Long Run",
                "slug": "the-long-run-2030-04-05",
                "category": "Comedy",
                "event_date": "2030-04-05T00:00:00.000000Z",
                "event_time": "19:30:00",
                "date_mode": "multiple",
                "occurrence_count": 3,
                "next_occurrence": {
                    "occurrence_date": "2030-04-05",
                    "time_label": "7:30 PM",
                    "location_label": "Main Stage",
                    "status": "scheduled"
                },
                "occurrences": [
                    {
                        "occurrence_date": "2030-04-05",
                        "time_label": "7:30 PM",
                        "location_label": "Main Stage",
                        "status": "scheduled"
                    },
                    {
                        "occurrence_date": "2030-04-06",
                        "time_label": "7:30 PM",
                        "location_label": "Main Stage",
                        "status": "scheduled"
                    },
                    {
                        "occurrence_date": "2030-04-07",
                        "time_label": "2:00 PM",
                        "location_label": "Main Stage",
                        "status": "scheduled"
                    }
                ],
                "description": "A three-night season of our award season favourite.",
                "location": "Main Stage",
                "over_18": false,
                "publish_status": "published",
                "tickets_enabled": true,
                "show_images": true,
                "small_image_path": null,
                "cancellation_reason": null,
                "cancelled_at": null,
                "ticket_office": {
                    "status": "open",
                    "reason": null,
                    "closes_at": null,
                    "closed_at": null,
                    "message": null
                }
            },
            "links": {
                "self": "https://platypus.tickets/t/nbt/api/events/2"
            }
        }
    ],
    "links": {
        "first": "https://platypus.tickets/t/nbt/api/events?page=1",
        "last": "https://platypus.tickets/t/nbt/api/events?page=1",
        "prev": null,
        "next": null
    },
    "meta": {
        "current_page": 1,
        "from": 1,
        "last_page": 1,
        "links": [
            {
                "url": null,
                "label": "&laquo; Previous",
                "page": null,
                "active": false
            },
            {
                "url": "https://platypus.tickets/t/nbt/api/events?page=1",
                "label": "1",
                "page": 1,
                "active": true
            },
            {
                "url": null,
                "label": "Next &raquo;",
                "page": null,
                "active": false
            }
        ],
        "path": "https://platypus.tickets/t/nbt/api/events",
        "per_page": 12,
        "to": 2,
        "total": 2
    }
}

```

## Get one event

```
GET /t/{slug}/api/events/{id}
```

`{id}` is the numeric event id: take it from the `id` in the index response, or follow the `links.self` URL directly. Unknown ids, drafts, private events, and hidden-cancelled events all return `404`.

```bash
curl -s https://platypus.tickets/t/nbt/api/events/1
```

```json
{
    "data": {
        "type": "events",
        "id": "1",
        "attributes": {
            "title": "An Evening of One-Act Plays",
            "slug": "an-evening-of-one-act-plays-2030-03-14",
            "category": "Drama",
            "event_date": "2030-03-14T00:00:00.000000Z",
            "event_time": "19:30:00",
            "date_mode": "single",
            "occurrence_count": 0,
            "next_occurrence": null,
            "occurrences": [],
            "description": "Four short plays from local writers, performed back to back with one interval.",
            "location": "Main Stage",
            "over_18": false,
            "publish_status": "published",
            "tickets_enabled": true,
            "show_images": true,
            "small_image_path": null,
            "cancellation_reason": null,
            "cancelled_at": null,
            "ticket_office": {
                "status": "open",
                "reason": null,
                "closes_at": null,
                "closed_at": null,
                "message": null
            }
        },
        "links": {
            "self": "https://platypus.tickets/t/nbt/api/events/1"
        }
    }
}

```

## Attributes

| Attribute | Type | Notes |
| --- | --- | --- |
| `title` | string | Event title |
| `slug` | string | URL slug of the public event page (`/t/{slug}/events/{event-slug}`) |
| `category` | string | Venue-chosen category label (e.g. `Drama`) |
| `event_date` | string | Event date as a datetime string. For `multiple`-mode events this mirrors the current/next stop and advances as stops pass |
| `event_time` | string | `HH:MM:SS`. Mirrors the current stop for `multiple`-mode events |
| `date_mode` | string | `single` or `multiple` |
| `occurrence_count` | integer | Number of stops. Always `0` for `single`-mode events |
| `next_occurrence` | object | null | Compact occurrence the venue is pointing at now (see below); `null` in `single` mode |
| `occurrences` | array | All stops in date order (see below). Empty (`[]`) for `single`-mode events |
| `description` | string | Event description; may contain HTML authored in the admin editor |
| `location` | string | Venue/location label |
| `over_18` | boolean | Age-restriction flag |
| `publish_status` | string | `published` or `cancelled` (drafts are never returned) |
| `tickets_enabled` | boolean | Whether ticketing is configured for the event. Read `ticket_office` for whether online sales are open right now |
| `show_images` | boolean | Whether the venue wants event imagery shown |
| `small_image_path` | string | null | Path of the event image, or `null` |
| `cancellation_reason` | string | null | Set when `publish_status` is `cancelled` |
| `cancelled_at` | string | null | ISO-8601 timestamp of cancellation |
| `ticket_office` | object | Whether online sales are open right now, and if not, why (see below) |

## Ticket Office

The `ticket_office` object says whether the venue's online sales for the event are open at the moment of the request. Render your own buy affordance from `status` rather than from `publish_status` and `tickets_enabled`, which describe configuration, not sellability.

| Field | Type | Notes |
| --- | --- | --- |
| `status` | string | `open` or `closed` |
| `reason` | string | null | `null` while open. While closed: `manual` (the venue closed it), `scheduled` (a scheduled closure fired), `event_ended` (a single-date event's day has passed), `cancelled`, or `not_ticketed` |
| `closes_at` | string | null | ISO-8601 UTC instant of a scheduled closure, present while one is pending or after it fired |
| `closed_at` | string | null | ISO-8601 UTC instant the office closed, for `manual` and `scheduled` |
| `message` | string | null | The venue's plain-text line for buyers, only while `reason` is `manual` or `scheduled`. Escape it before rendering |

While a closure is pending, `status` stays `open` and `closes_at` carries the deadline, so a consumer can show it ahead of time.

## Multi-date events

When a venue schedules an event across several dates (`date_mode: "multiple"`), every stop is embedded in the event itself. There is no separate occurrences endpoint to call. Each compact occurrence carries `occurrence_date` (`YYYY-MM-DD`), `time_label`, `location_label`, and `status` (`scheduled` or `cancelled`). `next_occurrence` points at the nearest upcoming stop, and the flat `event_date`/`event_time` mirror it.

```bash
curl -s https://platypus.tickets/t/nbt/api/events/2
```

```json
{
    "data": {
        "type": "events",
        "id": "2",
        "attributes": {
            "title": "The Long Run",
            "slug": "the-long-run-2030-04-05",
            "category": "Comedy",
            "event_date": "2030-04-05T00:00:00.000000Z",
            "event_time": "19:30:00",
            "date_mode": "multiple",
            "occurrence_count": 3,
            "next_occurrence": {
                "occurrence_date": "2030-04-05",
                "time_label": "7:30 PM",
                "location_label": "Main Stage",
                "status": "scheduled"
            },
            "occurrences": [
                {
                    "occurrence_date": "2030-04-05",
                    "time_label": "7:30 PM",
                    "location_label": "Main Stage",
                    "status": "scheduled"
                },
                {
                    "occurrence_date": "2030-04-06",
                    "time_label": "7:30 PM",
                    "location_label": "Main Stage",
                    "status": "scheduled"
                },
                {
                    "occurrence_date": "2030-04-07",
                    "time_label": "2:00 PM",
                    "location_label": "Main Stage",
                    "status": "scheduled"
                }
            ],
            "description": "A three-night season of our award season favourite.",
            "location": "Main Stage",
            "over_18": false,
            "publish_status": "published",
            "tickets_enabled": true,
            "show_images": true,
            "small_image_path": null,
            "cancellation_reason": null,
            "cancelled_at": null,
            "ticket_office": {
                "status": "open",
                "reason": null,
                "closes_at": null,
                "closed_at": null,
                "message": null
            }
        },
        "links": {
            "self": "https://platypus.tickets/t/nbt/api/events/2"
        }
    }
}

```

Hitting CORS errors when you call these endpoints from a browser? The [CORS rules in the introduction](/api/#cors) explain which origins are allowed and where the fix lives.

---

---
url: /api/embeds.md
description: >-
  Embedding Platypus event details, the Ticket Office, and your events listing
  on your own website with iframes.
---

# Embedding on your site

**Platypus pages are built to live inside your own website.** Three surfaces embed with a plain `<iframe>` — no JavaScript snippet, no API key:

| Surface | URL | What it shows |
| --- | --- | --- |
| Event details card | `/t/{slug}/events/{event-slug}/embed/details` | Date, time, and location — the "Dates & venues" card for multi-date events |
| Tickets card | `/t/{slug}/events/{event-slug}/embed/tickets` | Ticket types with prices (or *Free* / *Sold out*) and the **Buy tickets** button; the "Dates & venues" card with per-date buy buttons for multi-date events; the closed notice (*Online ticket sales have closed.* and the venue's message) in place of the button while the [Ticket Office](/guide/ticket-office) is closed; cancellation notice for cancelled events |
| Events listing | `/t/{slug}/events` | Your full public events page (grid/list) |

The two card embeds carry no Platypus chrome (header, navigation, or footer); the events listing embeds as the full page, navigation and footer included. All three render with your venue's Platypus stylesheet.

## Site Domain — the one prerequisite {#site-domain}

Platypus refuses to be framed by arbitrary websites. Every public page sends a `Content-Security-Policy: frame-ancestors` header that allows exactly two origins: Platypus itself, and **your configured Site Domain**. A venue admin sets it under **Settings → General → Site Domain** as a bare hostname such as `www.exampletheatre.com.au`; Platypus allows that host as an `https://` origin.

If the iframe renders blank and the browser console reports a `frame-ancestors` violation, the Site Domain is unset or doesn't match the domain the page actually lives on. Fix the setting; no code change is needed.

Admin and login pages can never be framed by your site — or anyone else's.

## Example

```html
<iframe
  src="https://platypus.tickets/t/nbt/events/an-evening-of-one-act-plays-2030-03-14/embed/tickets"
  title="Tickets — An Evening of One-Act Plays"
  style="width: 100%; max-width: 480px; border: 0"
  height="520"
></iframe>
```

The event slug is the `slug` attribute from the [API](/api/events#attributes); it also appears in the event page's URL. Pick a `height` that fits the content, because the cards don't auto-resize the frame.

## Buying tickets inside the frame

The tickets card's **Buy tickets** button navigates the iframe itself to checkout, and checkout is designed to complete in-frame, card entry included. Buyers never need to leave your page. Paid tickets need your venue's Stripe keys configured — until then only free ticket types show the buy button, and a free checkout completes without a card step.

## Theming

There are no per-embed style parameters. Embeds follow your venue's global appearance settings (public site theme and custom CSS, configured in the Platypus admin), so they match your Platypus pages everywhere they're shown. The selector contract for styling embedded pages is documented in [Appearance & custom CSS](/api/appearance-css).

## Prefer data over iframes?

If you want full control of the markup, fetch the same event data as JSON from the [public API](/api/events) and render it yourself. The [CORS allowance](/api/#cors) uses the same Site Domain setting.

---

---
url: /api/appearance-css.md
description: >-
  The stable CSS selector contract for styling embedded Platypus pages — page
  IDs, layout hooks, repeating classes, and the disableCustomCss debugging
  switch.
---

# Appearance & custom CSS

[Embedded pages](/api/embeds) carry **no per-embed style parameters**. They follow the venue's global appearance settings: the public theme, plus the venue's **Custom CSS** configured in the Platypus admin under **Settings → Appearance**. If you are integrating Platypus into a venue's website, that one stylesheet is how you make the embedded events grid, event detail, and in-frame checkout match the surrounding site.

## The Custom CSS field

* One stylesheet, up to **20,000 characters**, entered on the Appearance tab.
* Platypus injects it into every public page **after** the theme's own styles, so its rules win over the defaults without reaching for `!important`.
* The embed layout gets the same stylesheet: one set of rules styles the pages standalone and inside your iframe.
* The literal sequence `</style` is rejected on save. The stylesheet is rendered inside a `<style>` block, so a closing tag can't be smuggled in; everything else is CSS, verbatim.

## Seeing a page without the custom CSS

To see a page without the venue's custom CSS, add `?disableCustomCss=1` to any public page URL. It affects that single request and stores nothing: remove the parameter and the CSS is back. Use it to tell "the custom CSS did this" apart from "the theme did this".

## The selector contract

These IDs and classes are **stable hooks**: they carry no styling of their own and won't be renamed, so integration CSS keeps working across Platypus updates.

### Page identifiers

The outer wrapper of every public page carries `id="page-<slug>"`, so a rule can be scoped to one page — including that page's nav and footer:

| Page | ID |
| --- | --- |
| Home | `#page-home` |
| Events listing | `#page-events` |
| Event detail | `#page-event-detail` |
| Subscribe / confirmation | `#page-subscribe`, `#page-subscribe-confirmed` |
| Unsubscribe / confirmation | `#page-unsubscribe`, `#page-unsubscribe-confirmed` |
| Contact | `#page-contact` |
| Checkout | `#page-checkout` |
| Ticket terms | `#page-terms` |
| Embedded cards | `#page-embed-details`, `#page-embed-tickets` |

```css
/* A different footer on the home page only */
#page-home #site-footer {
    background: #1d3a2a;
}
```

### Layout hooks (every full page)

| Hook | Element |
| --- | --- |
| `#site-nav` | Navigation bar |
| `#site-brand` | Brand / logo link |
| `#site-main` | Main content region |
| `#site-footer` | Footer |
| `.site-nav-link` | Each navigation link |

The two card embeds carry no chrome, so inside them only the page ID and the card hooks below match.

### Unique page elements

| Hook | Element |
| --- | --- |
| `#home-intro`, `#home-links` | Home intro copy and link-card block |
| `#events-header` | Events listing header |
| `#event-main`, `#event-sidebar`, `#event-description` | Event detail columns and description |
| `#tickets-card`, `#event-details-card`, `#event-dates-card` | Event detail cards |
| `#buy-tickets-button` | The purchase button |
| `#ticket-office-notice` | The notice shown while online sales are closed |
| `#ticket-office-closing` | The "Online sales close …" line while a closure is scheduled |
| `#subscribe-card`, `#subscribe-form`, `#subscribe-confirmed-card` | Subscribe pages |
| `#unsubscribe-card`, `#unsubscribe-form`, `#unsubscribe-confirmed-card` | Unsubscribe pages |
| `#contact-form`, `#contact-details` | Contact page |

### Repeating elements

| Hook | Element |
| --- | --- |
| `.ticket-batch` | Each ticket-type row on an event detail page |
| `.home-link-card` | Each link card on the home page |
| `.contact-detail-item` | Each contact detail on the contact page |
| `.ev-card`, `.ev-row`, `.ev-grid`, … | The events listing's `ev-*` family (cards, rows, grid, filters, pills) |

```css
/* Round every event card and hide the category pills */
.ev-card {
    border-radius: 1rem;
}
.ev-pill {
    display: none;
}
```

## How this interacts with the theme

The public theme is fixed to light mode and scoped to public pages. Custom CSS loads after it, so anything written there overrides the theme; an empty field means pages use the theme as-is. There is no way to inject CSS from the embedding page into the iframe. The Appearance stylesheet is the supported seam.

If a rule refuses to take, load the page with `?disableCustomCss=1` to work out which stylesheet is winning. If a hook listed above is missing from the markup or has stopped matching, that's a bug in this contract — email [support@platypus.tickets](/faq/support).

---

---
url: /faq.md
description: 'What Platypus.Tickets is — who it''s for, how it''s priced, and who runs it.'
---

# About Platypus

**Platypus.Tickets sells tickets for small theatre venues.** It was built for the 50-seat end of the world: your events on your own pages, buyers who never need an account, and a flat $1 AUD per ticket sold.

## What makes it different

* **Your audience stays yours.** Platypus lives quietly under your own website — event listings and ticket cards embed straight into your pages. Around your events there are no ads, no "you might also like" suggestions, and no urgency banners: nothing competes with the show.
* **Your money goes to you.** Checkout charges the buyer through your venue's own Stripe account. Platypus never holds your funds. More detail in [Stripe and payments](/faq/stripe).
* **Flat pricing.** A fixed subscription plus $1 AUD per ticket sold — the same flat dollar whether the ticket is $15 or $50, and buyers pay the price you set. Free tickets carry no per-ticket fee.
* **No accounts for buyers.** A buyer picks the tickets they need, pays, and gets a PDF by email. There's no sign-up wall between them and the show.

## Who runs it

Platypus is small, Australian-built software, run by Platypus Tickets Pty Ltd (ACN 702 006 399, ABN 62 702 006 399); currency is AUD throughout. It's run for a short list of venues, and staying small is deliberate. Some corners are still MVP: what's built is laid out in [Features](/faq/features).

## Where are the docs for running a venue?

In the [Guide](/guide/). Developers embedding events into a venue's website want the [API reference](/api/) instead.

---

---
url: /faq/stripe.md
description: >-
  How Platypus uses Stripe — venue-owned payments, what buyers see, and what
  venues need.
---

# Stripe and payments

Every ticket payment on Platypus runs through **the venue's own Stripe account**. This page covers what that means for buyers and for venues.

## Why Stripe?

Card payments are serious infrastructure: vaulting card numbers, 3-D Secure, fraud screening, payouts. Platypus doesn't reinvent any of that. Every payment is processed by [Stripe](https://stripe.com), and specifically by **the venue's own Stripe account**.

## What that means for buyers

When you buy a ticket, your card details go to Stripe, never to Platypus. The charge is made by the venue itself: it's the venue's name on your statement, the venue's refund to give. Checkout runs on the venue's own pages (or embedded in the venue's website), card step included, with no redirect to a separate payment site; your tickets arrive by email as a PDF.

## What that means for venues

* **A Stripe account with charges enabled** — free to create; Stripe's per-transaction fees apply, as with any Stripe business.
* **Restricted API keys** — you paste these into the Platypus admin, and Platypus verifies them before anything is stored (encrypted). Setup is a five-minute guided page: [Stripe payments setup](/guide/stripe-payments).
* **Refunds** — handled in your Stripe dashboard, where you keep full merchant control.
* **Stripe's test mode** — works end to end, so you can rehearse a purchase with a test card before going live.

## Do free tickets need Stripe?

No. A free ticket type is claimable with no card step and no Stripe account — buyers confirm and their tickets arrive by email like any paid order, with no $1 AUD fee counted. Stripe is needed the moment any ticket type has a price.

## Does Platypus touch the money?

No. Ticket revenue settles from Stripe to the venue's bank account directly. Platypus bills the venue separately: a flat subscription plus $1 AUD per ticket sold, free tickets never counted ([subscription and billing](/guide/subscription-and-billing)).

Payment doing something unexpected? The setup guide's [troubleshooting table](/guide/stripe-payments#troubleshooting) covers the common failures, symptom first.

---

---
url: /faq/features.md
description: >-
  What Platypus does — the audience-facing pages and checkout, and the
  venue-side admin tools.
---

# Features

Platypus is honestly MVP: **what's listed as built is genuinely live**; what isn't, isn't dressed up to look finished.

## For audiences

* Public event pages under your venue's address — a listing plus a page per event, no account needed to buy
* Ticket checkout on the event page or embedded in your own website; paid orders settle to your venue's own Stripe account, and free tickets skip the card step entirely
* Tickets arrive by email as a PDF with QR codes; a cancelled event shows the reason plainly

## For venues

* Event management — single or multi-date events, rich descriptions, images, drafts, and private events (unlisted, with an optional password)
* Ticket types with their own pricing, surcharges, capacity, and per-order limits; capacity is enforced at checkout — free ticket types included, and a free-only order checks out without a card step or a Stripe account
* [Ticket Office](/guide/ticket-office) — online sales you can close on demand or at a set time, with a public message for buyers, and reopen while the event is upcoming
* Issue tickets yourself — comps and door sales by hand, door sheets to print, PDFs to re-download
* [QR check-in at the door](/guide/door-checkin) — a shareable link volunteers open on a phone to scan tickets and see who's arrived
* [Mailing list](/guide/mailing-list) — double opt-in, tags, and campaigns, sent through your own mail provider or by arrangement through Platypus hosted email
* [Customer segments and discounts](/guide/customer-segments) — voucher codes, open to anyone or gated by customer segments (mailing-list tags, past buyers), managed on each event's **Discounts** tab
* [Reports](/guide/reports) — ticket sales and revenue, page views (cookieless, first-party), mailout delivery, checkout issues and broken links, all exportable as CSV, plus an admin-only audit log
* [Team users](/guide/team-users) — delegated logins with roles (manager, event manager, door staff, and more)
* [Account security](/guide/account-security) — multi-factor authentication and recovery codes for every admin login
* Contact form, custom mail provider, appearance theming, and custom CSS
* Website embedding — iframe event cards and listing, plus a read-only [JSON API](/api/)

## Campaigns without a paid mail provider

Campaigns normally go out through [your venue's own mail provider](/guide/mail-settings); Platypus hosted mail covers the day-to-day transactional email (tickets, reminders, opt-in confirmations, contact-form messages) but not campaigns. A paid mail provider is a strange fit for a venue that mostly puts on free events and has no ticket revenue to fund one. If that's you, or your own provider doesn't fit for any other reason, [talk to us](/faq/support): we can configure your account to send everything, campaigns included, through Platypus hosted email.

## Missing something else?

Say so on the [ideas board](/faq/suggestions), or [email support](/faq/support).

---

---
url: /faq/suggestions.md
description: >-
  Feature suggestions — the public ideas board, voting on other venues' ideas,
  and what belongs there.
---

# Feature suggestions

Got an idea that would make Platypus better for your theatre? We keep a public ideas board where anyone can post a suggestion, comment on someone else's, and vote on what should be built next:

**[platypus.fider.io — the Platypus ideas board](https://platypus.fider.io)**

## How it works

* **Post an idea** — a sentence or two is plenty. Describe the problem you're trying to solve rather than the specific button you want; that gives us room to solve it well.
* **Vote** — if your idea is already on the board, vote for it instead of posting a duplicate. Votes tell us which ideas matter most to venues.
* **Follow along** — ideas get status updates (*planned*, *started*, *completed*, *declined*) as they progress, so you can see where things stand without asking.

## What belongs there

Anything about what Platypus *should do*: new capabilities, workflow improvements, "it would save me time if…". What's already built is on the [Features](/faq/features) page.

Something broken rather than missing? That's a bug, not a suggestion. Email [support@platypus.tickets](/faq/support) so it isn't waiting in a voting queue.

---

---
url: /faq/sign-ups.md
description: >-
  How venues join Platypus — request an account, we review it personally, and
  your admin arrives by email invitation.
---

# Sign-ups

**Short version: ask for an account at [platypus.tickets/request-account](https://platypus.tickets/request-account) and a real person sets you up.**

Platypus doesn't have an instant "create your venue" button. That's deliberate. We're a small platform growing carefully with real venues, so a person looks at every request:

1. **Tell us about your venue.** The [request form](https://platypus.tickets/request-account) asks for your name, your venue or organisation, an email address, your website if you have one, and anything you'd like us to know, plus a tick to accept the terms. No card details, no commitment.
2. **We review it.** We check that there's a real venue or producer behind the request, usually within a couple of days. We might email you a question first.
3. **Your invitation arrives.** If we're a good fit, we set up your account and email you a **welcome invitation** — a link that lets you choose your own password. The link lasts a week; if it expires, use *Forgot password?* on your venue's login page with the same email address and you're away.

From there everything is yours to drive: [first login through first sale](/guide/).

Your venue gets an address like `platypus.tickets/t/your-venue/`. We pick the short name with you during setup, so there's nothing to choose on the form.

Requested an account and heard nothing after a few days? Check your spam folder for the invitation first, then email [support@platypus.tickets](/faq/support).

---

---
url: /faq/support.md
description: >-
  How to reach Platypus support — the support inbox, what to include, and what
  we can and can't do.
---

# Contact & support

**Email <support@platypus.tickets>.** It's a monitored inbox.

## What to include

Three things save a round trip:

* Your venue address (the short name in your URLs, e.g. `platypus.tickets/t/your-venue/`).
* What you were doing, what you expected, and what happened instead.
* For order problems, the order reference — it looks like `PLTPS-…` and is on the buyer's receipt.

## Things support can do

* **MFA lockout** — if an admin has lost both their authenticator device *and* their recovery codes, we can clear MFA on the account. The clearance is logged in your venue's audit trail, and you re-enrol from the [Security page](/guide/account-security) afterwards.
* **Account recovery** — we can reset a venue admin's access when email-based reset isn't possible.
* **Payment questions** — help tracing a payment that didn't turn into tickets. Your Payments page flags these automatically ([payment exceptions](/guide/payment-exceptions)), so check there first.

## Things that aren't support

* **Feature ideas** belong on the [ideas board](/faq/suggestions), where others can vote for them.
* **Buyer refunds** are between the buyer and the venue: the venue named on the ticket is the seller. Point buyers at your ticket terms page.

Not sure where your problem fits? Email it anyway.

---

---
url: /faq/about-these-docs.md
description: >-
  How this documentation stays true to the running system — build stamps,
  test-backed examples, and coverage gates.
---

# About these docs

**This site is built and deployed from the same repository as the product itself.** It lives at `docs.platypus.tickets`, and it's reference documentation, not marketing. A few mechanics keep it honest:

* **It documents current behaviour.** Where the product has a quirk (say, [what your subscription does and doesn't control](/guide/subscription-and-billing)), the docs say so rather than describing the system we'd like to have.
* **API examples can't drift.** Every JSON example in the [API section](/api/) is a fixture file asserted byte-for-byte by the Platypus test suite against real API responses. If the API changes, the tests fail until the examples are regenerated.
* **Coverage is enforced.** Each documented feature ties back to the capability specs that define Platypus. A new capability can't ship without either a docs page or an explicit, justified exemption. The docs build fails until one exists.
* **Every build says what it documents.** The footer (and `/build-info.json`) carries the exact source commit these pages were built from.
* **AI tools can read it whole.** The full content is published as [`/llms.txt`](/llms.txt) and [`/llms-full.txt`](/llms-full.txt).

Found something that doesn't match the product? That's a bug in the docs — email [support@platypus.tickets](/faq/support).