TRCItem
The polymorphic core object that becomes an Event, Location, Venue, or Route depending on entitytype
TRCItem is the core data object in the Event Connectors API. Every event, location, venue, and route you read or write through the API is a TRCItem — differentiated by its entitytype field.
When you call GET /events, GET /locations, GET /venues, or GET /routes, you get TRCItems back. The shape is largely the same across entity types, with a few fields that only populate for certain types.
Shared Fields
Every TRCItem carries these fields regardless of entity type:
| Field | Type | Description |
|---|---|---|
id | string | Internal UUID |
trcid | string | Stable identifier across systems |
slug | string | URL-friendly name |
entitytype | string | One of EVENEMENT, LOCATIE, EVENTGROUP, ROUTE, VENUE |
wfstatus | string | Workflow status — see Workflow Status below |
trcItemDetails | array | Title, descriptions per language (see Translations) |
trcItemCategories | object | Types, categories, and data-typed values |
calendar | object | Scheduling information (see Calendar) |
contactinfo | object | Contact details and URLs |
files | array | Attached media (images, PDFs, videos) |
location | object | Geographical location with address and coordinates |
translations | object | primaryLanguage and availableLanguages |
seoMetadata | object | SEO fields including Open Graph and schema.org |
priceElements | array | Pricing per target audience (Events only) |
promotions | array | Promotional offers with validity rules (Events only) |
performers | array | Performer list (Events only) |
Workflow Status
wfstatus is the single source of truth for a TRCItem's lifecycle. The legacy boolean fields (published, deleted, offline) are derived from wfstatus automatically — never read those directly, and never write them without also updating wfstatus.
The wfstatus enum
| Value | Meaning |
|---|---|
draft | Being phased out — see note below |
readyforvalidation | Submitted (e.g. via a feed) and waiting for an editor to review. Not visible to consumers. |
approved | Reviewed by an editor; visible to consumers. The only status that produces a published item. |
rejected | Reviewed and explicitly rejected. Not visible to consumers. |
deleted | Soft-deleted. Hidden from normal queries but still in the store. |
archived | Archived (e.g. past event kept for reference). Not visible to consumers. |
draft is being phased out
Saving a TRCItem with wfstatus: draft (or with no wfstatus at all) is normalised on the server to readyforvalidation. Don't write draft in new integrations — it has no separate downstream behavior.
Derivation of the legacy boolean fields
Whenever a TRCItem is saved, the server runs StatusUtil.updateFlagfieldsByWfStatus to keep the boolean fields in sync with wfstatus. Only approved produces a published / non-deleted / online item; every other status produces the same "not visible" combination.
wfstatus | published | deleted | offline |
|---|---|---|---|
approved | true | false | false |
readyforvalidation | false | true | true |
rejected | false | true | true |
archived | false | true | true |
deleted | false | true | true |
draft | (normalised to readyforvalidation on save) |
A few consequences worth flagging:
deleted: truedoes not mean "deleted" in the obvious sense. It means "the item is not currentlyapproved" — which includes ready-for-validation items, rejected items, archived items, and actually-deleted items alike. Usewfstatusto tell them apart.offline: trueis identical topublished: false. The two booleans always carry the same information; there's no case where one is true and the other isn't.- A new TRCItem submitted via a feed comes in as
wfstatus: readyforvalidation, which means it haspublished: false,deleted: true,offline: true. That's expected — it becomes published only after an editor approves it.
Deprecated fields
published,deleted,offline— deprecated. Returned for backwards compatibility; derived as shown above. New integrations should readwfstatus.isprivate— fully deprecated. Not maintained byStatusUtil. Ignore on read; do not set on write.
If you write published, deleted, or offline directly without also setting a matching wfstatus, the server's normalisation will overwrite your booleans on the next save based on wfstatus. To take an item offline, set wfstatus to a non-approved value; to publish, set it to approved.
Per-Entity-Type Variants
EVENEMENT (Event)
The most feature-rich entity type. Events have priceElements, promotions, performers, and support child/parent link types for event series.
LOCATIE (Location)
A geographical point of interest — a museum, park, or monument. Locations do not have priceElements, promotions, or performers. Link types are limited to alias and comment.
VENUE
A business-oriented location — a restaurant, hotel, or conference center. Structurally similar to Location but semantically distinct. The entitytype is always VENUE. See Location vs Venue for when to use which.
EVENTGROUP
A container for grouping related events (e.g., a festival that contains multiple sub-events). Uses child/parent links to connect the group to its member events.
ROUTE
A geographical path with waypoints. Carries a routeInfo object with route type, distance, duration, coordinates, and points of interest.
Feed Ingestion and Update Behavior
When events are submitted via an inbound feed (a partner's HTTPS endpoint), Event Connectors polls the feed approximately every 4 hours. Each event in the feed is matched to an existing TRCItem using the externalId — a composite of the feed name and the id you provide.
New events are created with wfstatus: readyforvalidation. An editor must review and approve the event before it becomes published.
Existing events follow different update rules depending on their status:
| Status | Behavior on feed update |
|---|---|
Not yet published (readyforvalidation, draft) | All fields are overwritten by the feed version |
Published (approved + published: true) | Only calendar and priceElements are overwritten; editor changes to title, descriptions, media, and other fields are preserved |
This means editors can refine text and media for published events without risk of those changes being overwritten by the next feed sync. Calendar and pricing always stay in sync with the source.
Minimal Example
{
"trcid": "e_abc123",
"entitytype": "EVENEMENT",
"wfstatus": "approved",
"published": true,
"trcItemDetails": [
{
"lang": "nl",
"title": "Koningsdag Festival",
"shortdescription": "Jaarlijks festival op Koningsdag",
"longdescription": "..."
}
],
"translations": {
"primaryLanguage": "nl",
"availableLanguages": ["nl", "en"]
}
}Realistic Example
{
"trcid": "e_abc123",
"entitytype": "EVENEMENT",
"wfstatus": "approved",
"published": true,
"trcItemDetails": [
{
"lang": "nl",
"title": "Koningsdag Festival",
"shortdescription": "Jaarlijks festival op Koningsdag",
"longdescription": "Het grootste Koningsdag festival van de regio..."
},
{
"lang": "en",
"title": "King's Day Festival",
"shortdescription": "Annual King's Day festival",
"longdescription": "The largest King's Day festival in the region..."
}
],
"translations": {
"primaryLanguage": "nl",
"availableLanguages": ["nl", "en"]
},
"calendar": {
"singleDates": [
{
"date": "2025-04-27T00:00:00",
"when": [{ "timestart": "10:00", "timeend": "23:00" }]
}
],
"calendarType": "SINGLEDATES"
},
"location": {
"address": {
"city": "Amsterdam",
"zipcode": "1012 AB"
}
},
"priceElements": [
{
"description": {
"value": "Adults",
"priceDescriptionValue": "Adults"
},
"from": 15.0,
"till": 15.0
}
]
}See the API Reference for the full schema definition.