Guides

Setting up an event

From an empty draft to a page people can book, in the order the console asks for it.

Organiser event work lives under Studio on the partner surface. Platform administrators use a separate back office. An event starts as a draft and stays private until you publish it, so nothing you are still deciding is visible to guests.

1. Create it

Studio → Events → new event. A name is the only thing you need to start. Capacity defaults to 100 and the dates default to a week out — both are meant to be corrected, not accepted.

2. Details

Venue, dates, capacity, and the map location. Two things are worth knowing:

  • The end date matters more than it looks. A two-day fair created today ends four hours after it starts unless you change it, and every date display on the site follows what you set here.
  • Capacity is enforced in the database, not in the page. Nothing can oversell it, including two people checking out at the same instant.

3. Tickets

Studio → your event → Tickets. Add as many types as you like, at any price.

  • RM 0 is a real ticket type, not a special case. A free ticket never touches the payment gateway, so it confirms instantly.
  • Name and price lock once one is sold. The ledger has to keep matching what people actually paid, so a tier that has sold cannot be quietly re-priced.
  • Quantity is per type, so a 50-seat VIP tier cannot outsell itself even if the venue has room.

4. Publish

Publishing needs a venue, a map location, at least one ticket type and at least one category. The console lists whatever is missing rather than greying out the button and leaving you to guess.

Renaming a draft changes its web address. Renaming a live event changes only the title — the address somebody already pasted into a group chat keeps working.

5. The rest

Migration-preview limits

The target currently has three concurrency gaps that matter when setting hard limits:

  • a burst of simultaneous entries into a free giveaway can exceed its cap;
  • simultaneous promotion-code redemptions can exceed the configured use count;
  • simultaneous bookings into sibling workshops can still overlap.

The ordinary validation remains useful, but do not treat those three limits as strict under concurrent demand until the known issues are closed.

On this page