How to send hackathon certificates to participants

The short answer

Reconcile your registration, check-in, submission, and judging lists into one recipient table, decide who gets which award, then send winners and participants as separate batches within 48 to 72 hours. Keep a correction window open for a week afterwards.

Judging finishes on Sunday night. By Monday, the certificate list exists in four places, and none of them agrees with the others: registrations on Devfolio or Unstop, check-ins in a scanner export, submissions on Devpost, and winners in a judging sheet with no email addresses.

The certificate design is the easy part. The work is deciding which list wins for which field, and doing it once rather than in five different chat threads.

This guide is the order to do that work in.

Why the certificate list is the hard part

A hackathon produces more data than most events, and each source is authoritative for exactly one thing.

Registration is the spine because it is the only list that reliably has both a name and an email. Everything else attaches to it, by email where possible and by team plus name where not.

Keep a source column in the merged table. When two people claim the same prize, or a participant says they checked in but the scan disagrees, the source column is what lets you answer without reopening four exports.

Step 1: Define the award groups before you merge anything

Write down the groups before you look at the list, or the list will decide for you. A typical hackathon has seven:

Two decisions matter more than the rest.

Highest award only, or one certificate per role? A winner who also mentored can receive one winner certificate, or a winner certificate plus a mentor certificate. Pick one rule and apply it to everyone. Verifycate skips duplicate recipient rows on import, but it cannot know which recognition should win.

Do no-shows get a participation certificate? Registration is not attendance. If you issue to everyone who registered, the certificate stops meaning anything and the people who actually built something notice. Use check-in or submission as the eligibility test.

Step 2: Build one row per person

Export every list on the same day, then stop editing them. A certificate built from a list that changed halfway through is how two versions of the truth end up in the same inbox.

1. Start with the registration export as the spine.
2. Mark attendance from the check-in export, and add walk-ins manually with source = walk-in.
3. Attach projects from the submission export, matching by email first and team plus name second.
4. Attach awards from the judging sheet, expanding team awards into one row per team member.
5. Add the columns the certificate needs: name_as_certificate, email, award, track, team, role, source.
6. Deduplicate by email before you touch the design.

Team awards are the step people skip. The judging sheet names a project and maybe a team handle; the certificate needs a person. Expand the roster, confirm who was actually on it, and decide whether every member receives the same award wording.

Walk-ins and remote participants are the other gap. A person who attended but never registered will not appear in any export. They are an Issue Request Form or a manual row, not an exception you remember at midnight.

Step 3: Check names and emails before you send

A certificate is personal. The name on it should be the name the recipient wants to see, not the one they typed into a registration form at 2am.

• Do not use Discord or platform handles. @nullpointer is not a certificate name.
• Do not put a team name in the person's name field. Keep team in its own Attribute, even when the whole team shares an award.
• Check for role emails. president@, team@, and shared club inboxes will not reach the person who needs the certificate.
• Normalise case and whitespace so the same address does not appear twice.
• Look for plus-addressing and aliases before assuming two rows are two people.
• Run validation before publishing. Duplicate rows and malformed addresses are cheaper to fix here than in a bounce report.

For next year, add one field to the registration form: the name as it should appear on the certificate. It costs ten seconds at signup and removes most of the correction traffic afterwards.

Step 4: Write an email people will open

The subject line decides whether the certificate is seen this week or buried under sponsor newsletters.

Use the event name and the outcome, not a generic congratulation:

Your HackBengaluru 2026 certificate is ready

Aditya, your HackBengaluru 2026 winner certificate

The body needs six things, in this order:

1. What the certificate is and which award it recognises.
2. One link to the recipient's certificate page.
3. A line explaining that the QR code and link can be checked by anyone.
4. How to fix a name or detail, with the correction deadline.
5. Who to contact if the link does not work or the certificate never arrived.
6. A short thank-you to sponsors or judges, if the event promised one.

Do not attach the PDF to a bulk email. Large attachments hurt deliverability, fill inboxes, and freeze the certificate at the moment it was sent. A link is smaller, updateable, and points at the verification page.

Send from the shared sender if you are on Basics. On Pro, use your own verified domain, provider, or SMTP so the email comes from the event's domain rather than a stranger's.

Step 5: Send winners and participants as separate batches

Publish one group at a time. Winners go first, within 24 hours if judging is final, because the result is still being discussed. Participants follow within 48 to 72 hours.

Separate batches are not just a scheduling choice. Winners usually need different wording and often different artwork, and a failed send to 40 winners is easier to inspect than a failed send to 800 participants. Mentors, judges, and volunteers can go with the winner batch or in their own small batch.

Before publishing, read the confirmation: it states how many certificates will be issued and how many credits the batch will use. Check the count against your list. If the number looks wrong, the merge is wrong.

If a sponsor prize is still undecided, send the confirmed groups and add the sponsor winners as a second winner batch. Holding the whole event's certificates for one late decision is how a 48-hour send becomes a three-week complaint thread.

Step 6: Run the correction and missing-people window

Delivery is not the end. Plan for three kinds of follow-up.

Bounces. Open the delivery events and look at the addresses that failed. A typo needs a corrected address; a full inbox may need a retry; a role address needs the person's real email. Fix the recipient record rather than silently dropping the person.

Missing people. Share the Issue Request Form for walk-ins, late team members, and anyone whose registration used a different address. Choose Review Before Issuing so possession of the link is not proof of eligibility. Accepting a request issues the certificate and emails the recipient.

Name errors. Enable the Correction Form and give recipients a clear deadline, usually seven days. Approving a correction updates the same certificate and public page, keeps the existing link working, and does not use another issuance credit.

Public certificate pages are excluded from search indexes, so a winner's name does not become a search result. The page is still reachable by anyone with the link or QR code, which is what verification requires.

A seven-day timeline

Common mistakes

• Sending from a personal Gmail account to 800 people. Use a sender the event owns, or a verified sending domain.
• Attaching every PDF. Send a link to the certificate page instead.
• Using registration handles as names. Ask for the certificate name, and expect a correction window either way.
• One design for every award with no award field. Winners and participants then look identical.
• Issuing participation certificates to no-shows. It devalues the certificate for everyone who attended.
• No correction path. The organiser's inbox becomes the correction form, one message at a time.
• Waiting two weeks. The project is old, the team has dispersed, and fewer people share the result.

Common questions

How do we send certificates to hackathon participants?

Build one recipient row per person from your registration export, mark who checked in or submitted a project, add award and track columns, then publish winners and participants as separate batches. Each recipient gets an email with a link to their own certificate page, where they can download the file and share a QR code that anyone can verify.

Should winners and participants get the same certificate?

Usually not. Winners, runners-up, finalists, and track or sponsor prize winners need different wording, and often different artwork. Participants, mentors, judges, and volunteers are separate groups too. Send winners first, while the result is still news, and send the larger participant batch after it.

Do we issue certificates to people who registered but never checked in?

Decide this before you export. Most hackathons issue participation certificates to people who checked in or submitted a project, not to everyone who registered. Registration alone proves intent, not attendance. Write the rule down and apply it consistently, because the exceptions will arrive in your inbox either way.

What if a participant's name is wrong on the certificate?

Enable the Correction Form on the certificate. The recipient opens it from their certificate page, confirms their email with a one-time code, and requests the change. Approving it updates the same certificate and public page without using another issuance credit.

Can we add someone who is missing from the list?

Yes. Share the Issue Request Form and choose Review Before Issuing, so holding the link is not enough to receive a certificate. Accepting a request issues the certificate and emails the recipient. Use this for walk-ins, late team members, and people whose registration used a different address.

Should we attach the PDF to the email?

No. Send a link to the recipient's public certificate page instead. A link avoids large attachments, works when the recipient changes device, and always points to the current version of the certificate. The page includes the download, the QR code, and the verification details.

How soon after the hackathon should certificates go out?

Winners within 24 hours if the judging is final, and the participant batch within 48 to 72 hours. The closer the certificate arrives to the event, the more likely people are to share it while the project is still fresh. If sponsor prizes are still being decided, send the confirmed groups first and add the rest as a second batch.

Downloadable resources

Use this file as a starting point. Replace the sample rows with your own data and check the result before issuing.