Ticket types and capacity

A ticket type is a thing someone can buy: a price, a capacity, and the rules around both.

The fields

What each one does

Name — what the buyer picks from. It also prints on the ticket.
Group — optional heading the type sits under on your event page. Leave it blank and the type is listed on its own. See below.
Price — in rupees. Use 0 for a free ticket; a free order skips payment entirely and issues immediately.
Capacity — how many exist. Sold and held seats count against it. Leave it blank for unlimited.
Min / max per order — a minimum is for things that only make sense in pairs; a maximum is the usual defence against one person taking the room.
Sales start / end — optional, and per ticket type. Outside the window the type shows as not yet on sale, or as closed, rather than disappearing. To close everything at once, set Registration closes on the event instead — one date rather than one per type.
Minimum age — optional, in whole years. See below.
Includes a meal — mints a separate meal coupon alongside each ticket, collected at a food counter in the scanner's FOOD mode.
Invitation only — nobody can buy this type, even with a direct link. You issue seats on it yourself, from Invite someone. See below.

Grouping the list

An event with a handful of ticket types reads fine as a flat list. One with twenty does not — and a running event with a Defence rate, a civil rate, a VIP rate and a spectator ticket for each of four distances gets there quickly.

Fill in Group and matching types are collected under that heading on your event page. Groups start collapsed, each showing how many options it holds and what they cost, so a buyer picks the category first and the distance second instead of reading twenty rows.

Groups match on the exact words

VIP and Vip are two groups, not one. The Group box suggests the names you have already used on this event — pick from the list rather than retyping, and they will always land together.

Types with no group are listed last, under no heading. You do not have to group everything.

Tickets for hosts, volunteers and guests

Your co-host, the photographer, the two people a sponsor sends, the volunteer working the gate — none of them are buying a ticket, and all of them need one. Invite someone, on the event page, issues a real ticket to a name and an email: signed QR, wallet link, and the same scan at the door as everybody else. Nothing marks them out as a guest afterwards.

Set it up as its own ticket type:

Price ₹0. An invite is refused on a paid type on purpose. Comping a ₹699 seat would record a ₹699 sale that never happened, and that type's takings would be wrong for good.
Its own capacity. Twenty crew on their own type means your sale still has the numbers you put on it. Crew coming out of the same pool as buyers is how an event sells out twenty seats short.
Tick Invitation only. Then nobody can buy it, and you do not have to rely on the type simply not being listed.

You can invite before you publish

Invites work on a draft event, and after Registration closes has passed. Both of those are rules about buyers — they have never been rules about who you can put on the door list. What an invite still cannot do is issue a seat that does not exist, or a seat for an event that has already finished.

The invite asks the same registration questions a buyer answers, because they are your questions and a volunteer with no emergency contact is the same gap as an attendee with none. If a question is required, fill it in — the invite is refused without it.

Check whether the email actually sent

Issuing the ticket and sending the email are two things, and the card tells you about both. If the email did not go, the ticket is still real and still valid — open the order and re-send it, or forward the link yourself. What you should not do is tick somebody off your list on the strength of "invited" alone.

Invite one person at a time. Every refusal — a duplicate, a missing answer, a full type — is about that one person, and a batch that stops halfway leaves you guessing which name it stopped on.

Closing registration for the whole event

Registration closes, in Event details, is a single cutoff for every ticket type. After it passes nothing on the event can be bought, whatever each type's own sales window says.

It has to be on or before the event's end — selling stops then regardless, so a later date would be a setting that does nothing.

Leave it blank and each ticket type is governed only by its own sales window, which is how every event worked before this existed.

Age limits

A race with a 21 km, a 10 km and a family walk usually has a different minimum age for each. Put the number in Minimum age on the ticket type and checkout refuses anybody below it.

Two things about how it is measured:

Age is counted on the day of the event, not the day of purchase. Somebody who is 17 in August and 18 by your September race day is eligible, and buys without trouble. Counting at checkout would sell them a ticket you then have to refuse at the gate.
It needs a date of birth to check against. Add a Date question and set its What this is to Date of birth — see Registration questions about registration questions. Without one there is nothing to compare, so nobody is refused; the ticket type editor warns you when that is the case.

The refusal names the ticket type and the limit, so a buyer who picked the wrong distance can change it rather than give up.

How capacity actually behaves

When someone starts a checkout, their seats are held — counted against capacity but not yet sold. If they do not pay, the hold expires and the seats come back automatically. You do not have to do anything, and you will sometimes see availability move without a sale.

Holds last longer on the direct-UPI rail

A gateway checkout holds seats for 10 minutes, which is plenty for a card. A direct UPI order holds them for up to 3 hours, because a human has to read a bank statement before the ticket exists. Either way the hold never outlives the event.

What "unlimited" really means

Leaving capacity blank does not remove the limit — it sets a very large one. Every ticket type has a number behind it, and an unlimited one is created at the highest number we accept.

Two things follow, and neither will matter for a normal event:

An unlimited type is already at the ceiling, so it cannot be raised any further. If you ever genuinely need more, you are far past the point where a second ticket type is the better answer.
Exports and the API report the number. Only the screens say Unlimited.

Archive, never delete

A ticket type is archived, not deleted. Archiving takes it off sale and leaves it out of the picker; every order that already used it keeps working, and every export still names it.

Deleting would orphan the orders that reference it — an attendee list with a blank tier column, and a ticket that scans green with nothing printed on it. Archived types can be restored.

Changing a type that has already sold

You can edit price, name and description at any time. Existing orders are unaffected: what a buyer paid is recorded on their order, not recomputed from the current price. Lowering capacity below what is already sold is refused rather than silently oversold.

Next: Choosing how buyers pay about choosing how buyers pay.