NFC templates

An NFC templateThe setup that decides what is written to a badge's NFC chip during check-in, such as the attendee's details or a link. NFC templates are created separately; check-in uses them to write the right data to each badge. decides what is written to the chip in an attendee’s badge when they check in. Check-in uses the template to write the right data to each badge. This page covers setting one up. For how encoding happens at the desk, see NFC badges.

Create an NFC template

Registration → NFC Templates

Choose the card formats, pick a write mode, define what gets written, and save.

Card formats

Choose which chip types this template supports. Each has a different usable capacity:

Format	Usable capacity
NTAG213	144 bytes
NTAG215	504 bytes
NTAG216	888 bytes
Ultralight	48 bytes
Classic 1K	768 bytes
Classic 4K	3456 bytes

If a template supports several formats, what you write has to fit the smallest one. Writing more than the card holds is reported as an error rather than silently truncated.

Two ways to write

A template writes in one of two modes:

• NDEF (recommended). A standard, self-describing format that phones and readers understand out of the box. Choose this unless you have a specific reason not to.
• Hex (advanced). You control the exact bytes written to the chip. Use it only when you need a precise byte layout, for example to work with an existing access-control system.

NDEF records

In NDEF mode a template is a list of records, each written to the chip in order. The record types are:

• EventDrake ticket. The record EventDrake reads back to identify the attendee. The ticket id is filled in for you, so there is nothing else to set. See The EventDrake ticket record.
• URI. A web address, such as a link to the attendee’s profile. You can pick a URI prefix (for example https://) so the common part is not stored on the card.
• Text. A plain text value, with a language tag (the default is English).
• External. A custom record with a type name you choose, for your own integrations.

Each record other than the EventDrake ticket takes a field value with an optional prefix and suffix.

Include the EventDrake ticket record

If you want a badge that EventDrake can recognise when it is tapped later, include an EventDrake ticket record. Without it, nothing on the card identifies the attendee to EventDrake.

The EventDrake ticket record

This is for readers who know NFC and want to understand how a badge is matched.

The EventDrake ticket record is an NFC Forum external record:

• Type name: eventdrake.net:ticket
• Payload: one version byte (currently 0x01), followed by the 16-byte ticket id (the ticket’s identifier written as raw bytes).

When a badge is tapped, EventDrake reads the NDEF message, finds the first eventdrake.net:ticket record, checks the version byte, and reads the 16 bytes back as the ticket id. That id identifies the attendee. Any other records on the card (a URI, your own external records) are ignored for matching, so you can carry both an EventDrake ticket record and your own data on the same badge.

You add it by choosing the EventDrake ticket record type. The ticket id is encoded automatically, so there is no field, prefix, or suffix to configure.

Field values and normalisation

For any record or replacement bound to a field, the value is worked out in this order:

1. Read the field from the ticket or a related record.
2. Normalise it with any normalisations you chose (see below).
3. Wrap it with the prefix and suffix.

The normalisations are:

• Trim. Remove leading and trailing spaces.
• Uppercase or Lowercase. Change the case.
• Simplify accents. Convert accented letters to their nearest plain-ASCII form, so Jäne becomes Jane.
• Strip non-ASCII. Remove any character outside plain ASCII.
• Printable only. Remove non-printable characters.

Hex encoding

Hex mode is for expert use. You provide a base image of the card’s memory, then define one or more replacements that write a value into a fixed region.

Each replacement sets:

• Field, prefix, and suffix. The value to write, resolved as above.
• Offset and length. Where in the card’s memory the value goes, and how many bytes it occupies. The value must fit the length, or it is reported as an error.
• Encoding. How the value becomes bytes:
  • ASCII / UTF-8: the characters as written.
  • ASCII hex: the value’s characters as their hex digits.
  • Raw binary: the value read as hex or a UUID and written as raw bytes (16 bytes for a UUID). The value must be valid hex.
  • Length-prefixed UTF-8: a length byte followed by the UTF-8 bytes.
• Pad byte. What to fill the rest of the region with when the value is shorter than the length.

The finished image must fit the card, so keep the total within the capacity of the smallest supported format.

Which template applies

Each template has a priority and a rule that decides which tickets it applies to. When more than one template could apply to a ticket, the highest priority wins. Because the rule matches on ticket fields, it is a ticket rule.

How it is used at check-in

During check-in the operator taps the badge and the template’s data is written. The write is confirmed, so a failure is reported at the desk. See NFC badges.