Registration software for marathons and running events in India

Last checked 20 September 2026

A road race sells one event four ways, so the thing that has to be right is the category, not the race. Thrivia is India's booking and ticketing platform for tour operators, trek leaders, and retreat & fest hosts to sell tickets, take bookings, and manage guests. For a race director that means the 5K, 10K, half and full sitting on one race page as four ticket types, each with its own price and its own count, a field limit held on the dated edition, the questions you ask a runner stored on the booking rather than in a form responses tab, and a start line where every ticket carries its own QR and the mobile scanner keeps working with no signal. There is no bib numbering, no timing chip integration and no results or splits anywhere in the product, so you still need a timing partner.

What this does not do, before anything else

There is no bib numbering, no timing chip integration, and no results, splits or leaderboard. Nothing in the product assigns a number to a runner, talks to a chip reader, or holds a finish time. A race director needs a timing partner for all of that and this does not replace one.

What is here is the half a timing partner does not sell you: taking entries for four distances on one page, holding a field limit, asking each runner the things you need before you let them start, and getting a few thousand people through a start line on a Sunday morning. Those are the parts that are usually a spreadsheet and a WhatsApp group.

The 5K, the 10K, the half and the full are four ticket types on one race

A race is one event with one date, one venue and one set of registration terms, and four products inside it that sell at different prices to different people at different speeds. The 5K fills with families in the last fortnight, the half fills first and the full barely moves after the early rate closes.

Each category is a ticket type on the race, carrying its own name, its own price and its own capacity, and going sold out on its own. The half closing does not touch the 10K. An early-bird rate on the full is a second ticket type with its own count rather than a discount somebody has to remember to stop honouring in November.

If you run the same race in two cities, or the same course twice a year, the race is built once and each dated edition carries its own field limit. That is the same machinery a fixed-departure trip uses, covered from that angle in booking software for trek organisers.

The field limit, and what actually holds it

A field limit on a road race is rarely a preference. It is the police permission, the width of the road at the first turn, the number of hydration points you have staffed, and on a few courses the municipal cap written into the permission itself.

Capacity is held on the dated edition, is required, cannot be less than one and defaults to 50 if you never set it, which is a number worth changing before you open entries. Alongside it the edition keeps a sold count that confirmed bookings increment, and the guard on the edition record rejects a save where the sold count has gone past capacity.

Be precise about what that guard is, because the honest version is more useful than the confident one:

• The guard runs when the edition document itself is saved. It is what stops you cutting the field limit to 800 in the dashboard after 900 people have already entered. Confirmed bookings raise the sold count with an atomic increment that does not pass through that guard at all, so it is not the thing standing between you and an over-full field.
• On hosted gateway checkout, availability is counted and compared, not reserved. Two runners taking the last place in the same few seconds can both pass the check. The service that does it is described as atomic and the read underneath is a count then compare, and the payment code says so in as many words.
• Manual UPI is the stronger path here. It materialises the hold first and then re-reads availability, and a writer that finds itself to be the entry that broke the limit backs itself out. It cannot oversell. The documented residual is the opposite failure, where two simultaneous entries both back out and a place is briefly released.

What you ask a runner, asked once

Every race in India collects more from an entrant than a name and a distance, and almost every one collects it twice, because the first copy is in a form responses tab and the second is on a sheet somebody prints on Saturday night.

Custom questions are set on the race and the answers are stored against the individual booking, one answer per question per booking, with a uniqueness rule that enforces exactly that. The same runner entering twice, once for themselves and once alongside a friend, gets two independent sets of answers rather than one overwriting the other. Answers can be free text, a single option from a list, a checkbox, a terms acceptance, or one of the typed fields for an email address, a website, a company or a social profile, and a signature can be attached where you are taking a declaration.

The set that earns its place on a road race:

• Date of birth, and the category the runner is entering. Age group placings are decided on the first and the second is already on the ticket type, and you want them in the same row.
• T-shirt size. It is the one number your merchandise order is built from and the one you cannot recover later without asking four thousand people again.
• Emergency contact name, relationship and a number that works in India. This is the field that justifies the whole exercise.
• Blood group. Your medical team will ask for it and it costs one question at entry.
• Any diagnosed heart condition, blood pressure medication or asthma, and current medication. Ask about medication in the same question or half the answers leave it out.
• Previous finish time at this distance, and where. It is how you seed the start pens, and it separates the runner who has done three halves from the one who has read about them.
• Acceptance of the race terms, as a terms question rather than a line of small print. The acceptance then sits on the booking record with everything else.

When you open the entrant list for the race, those answers are on the row. They are also what you hand your timing partner and your medical team, which is the point of asking them at entry rather than at collection.

The start line

Race morning is the one hour a year where the software either holds or embarrasses you in front of four thousand people standing in the dark.

Every ticket in a booking carries its own QR code, its own index within that booking and its own state, and a check-in stamps the time on that ticket rather than on the booking. A family entering three 5K places arrives as three scannable tickets, so two can start and the third can be marked absent without anyone editing anything.

The mobile scanner keeps a queue on the device. A scan taken with no usable connection is written to that queue and treated as a success, because the runner is already past you, and the queue survives the app being killed. The read is deliberately forgiving: a missing file, a half written row from a crash mid flush, or a shape from an older build all resolve to an empty queue instead of throwing, on the principle that the gate has to open even when device storage is unhappy. Replay to the server is idempotent, so a runner scanned offline and again online is checked in once.

Running several arches, or a separate lane per category, is its own problem and has its own page. QR entry with multiple gates covers the device set-up, the queue and what to load before you lose signal.

The people scanning are usually volunteers you met for the first time on Saturday, and the permission bucket for them holds two capabilities and nothing else: read the guest list and check someone in. No leads, no contact details, no event edit form, no money. Door members also sit outside the plan's seat allowance, so putting twenty volunteers on the gate does not cost you twenty seats.

What the runner pays and what reaches you

On gateway checkout there is a handling fee of 4.9%. Two things about it that are usually got wrong elsewhere: it already contains its own tax, so nothing adds 18% on top of it, and it is applied last, on the tax-inclusive subtotal, because that is the amount the gateway bills on.

Who carries it is set per race. With the attendee bearing it, a ₹999 half marathon entry shows the fee added at checkout. With the race bearing it, the runner pays ₹999 and the fee comes out of what reaches you. Races that print an entry fee on a poster in September and open entries in October usually pick the second, because the number on the poster is the number people expect to pay.

Manual UPI is the third shape and the one a lot of smaller races run on. The runner pays a UPI QR that resolves to your own VPA, for the exact amount, and uploads proof that waits in a verify queue until someone on your team accepts it. There is no platform handling fee on that path at all. Collecting UPI payments for events has the mechanics.

The sheet, the form and the Saturday night printout

A first or second edition runs like this. A Google Form takes entries with a dropdown for the distance, the fee goes to a UPI QR on the poster, screenshots arrive on WhatsApp, and someone reconciles the two lists on a Sunday. The entry count per category is a filter on a sheet. Race morning is a printed list at a table by the arch, and an announcement that the queue for the half starts on the left. This genuinely works, and the Indian race calendar is forgiving about it because entries open three or four months before a winter race and the pressure arrives all at once near the end.

The work in moving is writing the question set out properly, because most races have never had one list of what they ask and building it surfaces the three fields that two different forms asked differently. That is an afternoon. Then you open one edition on it, because nobody trusts a screen with four thousand emergency contacts until they have watched it hold them once.

Why a race page keeps earning after the race

Keep the page for an edition that already happened. People search the race by name all year, mostly to find out when the next one opens, and a live page with last year's distances, last year's prices and a way to be told about the next edition catches all of it. Deleting it each year and building a new one throws that away.

Which is an argument for building the race once and adding an edition per year rather than a fresh event each time. The page keeps its address, and the entries for the next edition open on something search engines already know about. Booking software for event organisers covers what else sits on that page.

What it costs

Thrivia is a monthly subscription with an included booking allowance, not a commission per entry. Plans start at ₹2,999 a month plus 18% GST at the entry rung and rise with bookings and admin seats, with better effective rates on six-month and annual terms. Payment gateway charges are separate. The live catalogue is on pricing, and that page is the one to trust.

Running events are the case where a commission per entry and a flat fee diverge hardest, because a road race is high volume and low ticket. Four thousand entries averaging ₹800 is ₹32 lakh through the race. A 5% commission on that is ₹1.6 lakh for one Sunday. Door volunteers not counting against the seat allowance matters for the same reason: a race puts more people on the gate for one morning than it has staff all year.

When Thrivia is the wrong choice

• You want one system that does entries and timing. There is no bib numbering, no chip integration and no results. If a single vendor for both is the requirement, this is not it.
• You want to publish an overseas entry fee in the entrant's own currency. Foreign cards work, but the order is created in rupees and their bank sets the rate.
• You want the entrant list flowing automatically into a timing platform. There is no public API, no Zapier and no calendar sync, so the hand-off is a manual one.
• You run acquisition on email. Email here is transactional and operational only: confirmations, balance reminders and a blast to the people already on an event. There is no list building, no newsletter and no drip to a cold audience. WhatsApp re-engagement exists behind the AI DM add-on, up to ten approved template messages to a filtered audience of your own leads.
• You need permissions scoped to one edition. A door member can read the guest list across your account, not just the race they are working.