Templates

What ends up in an event's configuration comes from a template. Each event is matched to exactly one, and the template decides which features are on, how they are configured, and what the defaults are before any per-event override.

Metadata is what makes a configuration

Templates match on fields from your feed. Three fields are required on every event, and anything else you emit can be carried into the configuration and used for matching:

• A unique, stable identifier. This becomes the key your SDK fetches by.
• A display name, what a viewer would recognise the event as.
• A start time, ISO 8601, with an explicit timezone or offset.

Commonly carried alongside them: league, competition round, home and away team, venue, broadcast network, end time, event status, blackout or rights flags.

A template can only key on a field your feed actually emits. If every event carries nothing but an ID, a name, and a start time, then every event gets the same settings; there is nothing to distinguish them by. Sport, league, and one free-form tier or flag field is cheap insurance, even if you launch with a single template for everything. Adding a matching key later means a change on your side and a redeploy of your feed; carrying a field you have not used yet costs nothing.

How matching works

A template declares the field values it matches on, and a priority that settles which one wins when several could apply:

{
  "title": "NFL",
  "priority": 10,
  "externalIdentifiers": [
    { "key": "leagueId", "value": "nfl" }
  ]
}

Templates are checked highest priority first, and the first one whose identifiers all match the event wins. That gives you a layered scheme, from broad defaults up to narrow special cases. Emit a new field and it becomes something a template can key on.

Granularity you want	Match on	Typical priority
Everything, as a floor	a field present on every event, e.g. identifierType	0
Per sport	sportId = "football"	5
Per league	leagueId = "nfl"	10
Per competition stage	round = "playoffs"	15
Anything you flag yourself	a field you invent, e.g. tier = "marquee"	as needed

A worked layering

Three templates, covering a sports schedule from the general case up to one you want treated differently.

Narrowest, a flag you set in your own feed:

{
  "title": "NFL — Marquee",
  "priority": 20,
  "externalIdentifiers": [
    { "key": "leagueId", "value": "nfl" },
    { "key": "tier",     "value": "marquee" }
  ]
}

Per league:

{
  "title": "NFL",
  "priority": 10,
  "externalIdentifiers": [
    { "key": "leagueId", "value": "nfl" }
  ]
}

Catch-all floor:

{
  "title": "All events",
  "priority": 0,
  "externalIdentifiers": [
    { "key": "identifierType", "value": "event" }
  ]
}

Event in your feed	Gets	Why
NFL game, tier: "marquee"	NFL — Marquee	Highest priority whose identifiers all match
NFL game, no tier	NFL	The marquee template needs both fields, so it falls through
NBA game	All events	Only the catch-all matches
Anything with no identifierType	nothing	No template matches, so no configuration is published

Always keep a catch-all

An event matching no template gets no configuration document, and your SDK's fetch for that ID returns nothing. A floor template matching a field every event carries is the cheapest way to make that impossible.

What matching can and cannot do

• Exact values only. No wildcards, ranges, or partial matches. Pick field values you are happy to state literally.
• Values compare as text. A boolean true in your feed matches the value "true". Numbers behave the same way.
• Several identifiers on one template are combined with "and". All of them must match.
• There is no "or". Covering two leagues with one set of settings means two templates pointing at the same configuration.
• One template per event. Matching stops at the first hit; templates do not merge or cascade into one another.
• Give overlapping templates distinct priorities. Two that could match the same event at the same priority resolve in no guaranteed order.

Templates are set up with you during onboarding and your team edits them in the Admin afterwards. Changing one changes every event configured from it going forward, which is what makes it the right home for anything that should be uniform. The setup conversation is described in Ingestion rules and templates.