Introduction to the Firehose

How does it work?

Unlike the imin Events API, the Firehose is not a search API. It is a “feed” that is compatible with the OpenActive Modelling Specification and published using the OpenActive Paging Specification.

The Firehose has two “types” of data, each of which has ‘parent’ and ‘child’ feeds:

• Events are split into SessionSeries and ScheduledSessions. These concepts are explained here.
• Facilities are split into FacilityUses and Slots. These concepts are explained here.

Caution

Terms of use for access to the imin Firehose differ from the standard terms. Please see Firehose Usage Policy & Restrictions.

The Firehose @id will not resolve

The @ids found in Firehose (e.g. https://firehose.imin.co/firehose/facility-uses/pulsedursley-FacilityUse-PULSEGYM) are merely an identifier that is guaranteed to be unique.

Caution

The Firehose @id does not need to actually resolve to an object.

Cross-Referencing Endpoints

A SessionSeries will have one or more ScheduledSessions and a FacilityUse will have one or more Slots. Additionally some Slots relate to an IndividualFacilityUse within a FacilityUse. In order to link the data together:

• ScheduledSession <-> SessionSeries
  • The ScheduledSession’s data.superEvent must match the SessionSeries’ data["@id"].
• Slot <-> FacilityUse
  • For FacilityUses with the individualFacilityUse property, then:
    • The Slot’s data.facilityUse must match one of the FacilityUse’s data.individualFacilityUse[]["@id"] IDs. This Slot will relate to a single court (e.g. Badminton Court 3).
  • For FacilityUses without the individualFacilityUse property, then:
    • The Slot’s data.facilityUse must match the FacilityUse’s data["@id"]. This Slot will represent an aggregation of courts (e.g. 6 badminton courts available)