Venue Resolution

All Tiers

The FormFav API handles flexible venue name input so your integration doesn't have to. Pass track names as URL slugs, full names in any case, or common alternate names — the API normalizes and resolves them automatically.

The Integration Problem

If you've integrated with racing data before, you've hit this: your upstream system calls it Rosehill Gardens, your URLs use rosehill-gardens, but the canonical name is just Rosehill. Every data provider uses a different format, and you end up writing format-conversion code that shouldn't be your problem.

FormFav handles this for you. Pass whatever format you have — the API resolves it.

How It Works

When you pass a track parameter to any endpoint, the API runs a resolution pipeline before querying the database:

Normalize the input

Lowercase, strip leading/trailing whitespace, replace hyphens and underscores with spaces. This means Eagle-Farm, eagle_farm, and EAGLE FARM all become the same normalized input.

Alias lookup

Match the normalized input against a dictionary of known aliases for major tracks. This covers common alternate names (e.g. Rosehill Gardens → Rosehill, Royal Randwick → Randwick) and selected industry abbreviations for the most popular venues.

Title-case fallback

If no alias matches, the normalized input is title-cased (e.g. moonee-valley → Moonee Valley). This means any venue works with slug-format input, even venues without explicit alias entries.

Database query

The resolved name is used for an exact, case-insensitive database match. If no venue is found, you get a clear 404.

What Always Works

These input formats are handled by normalization and title-casing, so they work for every venue on the platform — no alias entry needed:

Format	Example Input	Resolves To
URL slug (hyphens)	`eagle-farm`, `moonee-valley`	Eagle Farm, Moonee Valley
Underscored	`eagle_farm`	Eagle Farm
Any case	`FLEMINGTON`, `flemington`, `Flemington`	Flemington
Mixed formats	`EAGLE-FARM`, `Eagle_Farm`	Eagle Farm

Slugs just work

If you're building a web app and your URLs already use slug-format track names, you can pass them directly to the API with no transformation needed.

Alias Resolution

Beyond normalization, the resolver maps known alternate names and common abbreviations for major tracks to their canonical names. This is particularly useful when integrating with upstream data feeds that use their own naming conventions.

You Send	Resolves To	Why
`rosehill gardens`	Rosehill	Full venue name with suffix
`royal randwick`	Randwick	Formal name with prefix
`tabcorp park menangle`	Menangle	Sponsorship name (harness)
`aquis park`	Gold Coast	Sponsorship name (thoroughbred)
`sha tin` or `shatin`	Sha Tin	Spacing variation (HK)
`meadows`	The Meadows	Missing article (greyhound)

Alias coverage is strongest for major venues. For less common venues, slug-format input (e.g. te-rapa) is the most reliable approach.

In Practice

These requests all return the same race data:

bash

# URL-friendly slug from your router
curl "https://api.formfav.com/v1/form?date=2026-01-15&track=eagle-farm&race=3" \
  -H "X-API-Key: your_api_key_here"

The response always returns the canonical venue name in the track field, regardless of what input format you used.

Race Type Disambiguation

Some venue names are shared across racing codes. The resolver uses the race_code parameter to pick the right one:

Input	race_code	Resolves To
`sandown`	`gallops`	Sandown (thoroughbred)
`sandown`	`greyhounds`	Sandown Park (greyhound)

Multi-Surface Tracks

Venues with multiple racing surfaces are handled as distinct entries. The pipeline automatically differentiates based on track condition data:

Input	Surface
`gold-coast`	Gold Coast (turf)
`gold-coast-polytrack`	Gold Coast Polytrack (synthetic)
`pakenham`	Pakenham (turf)
`pakenham-synthetic`	Pakenham Synthetic

Deterministic, Not Fuzzy

The resolver uses exact dictionary lookup after normalization. There is no Levenshtein distance or probabilistic matching — resolution is predictable and will never return a venue you didn't intend.

If an input doesn't match any alias, the title-cased fallback is used for the database query. If that doesn't match either, you get a 404 with a descriptive error message.

Discovery Endpoints

If you want to see exactly what canonical venue names are available, two endpoints give you the source of truth:

GET

/v1/form/venues

All canonical venue names on the platform, filterable by race type and country.

GET

/v1/form/meetings

Tracks racing on a specific date, with slugs ready for direct use in API calls.

Example

Your upstream feed sends the name Rosehill Gardens. Pass it straight through — the resolver maps it to the canonical name:

bash

curl "https://api.formfav.com/v1/form?date=2026-01-15&track=rosehill%20gardens&race=3" \
  -H "X-API-Key: your_api_key_here"

200

Response

json

{
  "date": "2026-01-15",
  "track": "Rosehill",
  "raceNumber": 3,
  "raceName": "Hyland Race Colours Handicap",
  "distance": "1200m",
  "numberOfRunners": 10,
  "runners": [ ... ]
}

Notice the response returns the canonical name Rosehill even though the input was rosehill gardens.

Why This Matters

Flexible input — slugs, full names, any case, underscores, hyphens all resolve correctly
Alternate name handling — common variations like sponsorship names, formal names with prefixes/suffixes, and spacing differences are mapped for major tracks
Multi-code and multi-surface aware — correctly disambiguates venues shared across racing codes and tracks with multiple surfaces
Deterministic — exact lookup after normalization means predictable, consistent behavior with no surprises
All tiers — venue resolution is built into every API request, including the free tier