The imin Platform
2.0.0
2.0.0
  • Introduction to the imin Platform
  • Using the Platform
    • imin's Platform Products
    • Authentication
    • Our Platform Data
      • Understanding Responses
      • Namespaces and Extensions
      • Defensive Data Consumption
      • Mocking the Interface
  • platform products
    • Search
      • imin Events API
        • Events API Reference
        • Virtual & Physical Sessions
        • Concepts
          • EventSeries
          • ScheduledSessions and eventSchedules
          • Activities and Collections
            • Activities
            • Activity Concept Collections
          • Accessibility Support
          • Prices
        • Filters
          • Modes
          • Age Ranges
          • Dates and Times
          • Activities and Concept Collections
          • High Frequency Sessions
      • imin Facilities API
        • Query Parameter Search
          • Mandatory Query Parameters
            • mode=discovery-geo
            • mode=upcoming-slots
          • Optional Query Parameters
        • ByID Search
          • FacilityUse By-ID
          • Slot By-ID
        • FacilityUses and IndividualFacilityUses
        • Slots
        • Facilities Slot Booking
      • imin Places API [BETA]
        • Example Request & Response
    • Firehose
      • Introduction to the Firehose
      • Accessing the Firehose
      • Firehose Usage Policy & Restrictions
      • Firehose and Search
      • Bookable Firehose Feeds
      • Bookable Sellers Feed
      • Attribution Catalog Endpoint
    • Live Timetables
      • Pre-Requisites: Open Data Feeds
      • The Onboarding Process
        • 1. Ensuring your Data Offers the Best User Experience
        • 2. Setting up and Embedding your First Timetable
        • 3. Setting up the Rest of your Timetables
        • 4. Activating Booking via Guest Checkout
      • Features Available Upon Request
      • Styling the Live Timetables
      • FAQs
    • Data Dashboard
  • incorporating book and pay
    • imin Branded Checkout
      • Introduction
      • Setup
        • Information We Require From You
        • Actions You Need to Complete
      • Authenticated Checkout
        • Testing [BETA]
        • 👪Group Booking [BETA]
      • Standalone Checkout
      • Firehose and Checkout [BETA]
        • Loading the Checkout via Firehose
    • imin Booking Platform
      • Customer Account Management
        • Create Customer Account
        • Update Customer Account
        • Get Customer Account
        • Delete Customer Account
        • Example Scenario
        • Payment Card Management
        • Linked Accounts
        • Entitlement
          • Evidence Requests
          • Entitlement Pricing in Search
          • Entitlement Pricing in Checkout
        • Access Pass
        • Webhooks
      • Orders
        • Order History
        • Order (by ID)
        • Cancellations & Refunds
      • Upcoming OrderItems
      • Receipt (by ID)
  • imin and booking systems
    • Seller Onboarding
      • API
  • HINTS & TIPS
    • Get the Best Out of Search
      • Displaying Schedule Information
      • URLs and Offering a Call to Action
      • Searching by Activity
      • Your Search Results and HighFrequencySessions
      • Customer Specific Images
  • Info for Data Publishers
    • Your RPDE Feed & the imin Platform [BETA]
      • Providing Places Data [BETA]
      • Providing Schedule Information [BETA]
Powered by GitBook
On this page
  • Comparison to OpenActive Source Data
  • Augmented Fields
  • imin:totalItems
  • 2-week API Lookahead Window
  • Maximum URL Length
  • null Values and Empty Arrays
  • Archiving of EventSeries and FacilityUses
  • Parameters and the Number of Items Returned
  • Identifying Data Sources
  1. Using the Platform
  2. Our Platform Data

Understanding Responses

PreviousOur Platform DataNextNamespaces and Extensions

Last updated 2 years ago

Comparison to OpenActive Source Data

The imin responses are compatible with the , and even pass using the .

Augmented Fields

The imin search results have additional properties added to them for convenience. For example imin:fullAddress reliably contains the full address, regardless of the components present. All the fields in the response can be found documented in the .

imin:totalItems

imin:totalItems appears in all Search API calls across the Events, Facilities and Places APIs. It is the number of items that match the search request across all pages and may be an approximation.

When there is a small number of results (e.g. just one page of results), this number will be precisely accurate and reflect the exact number of items that match the search request.

However, this is not the case when there are a larger number of results. The reason for this is that our Platform will make an approximation in order to improve the performance of the search.

If you are communicating imin:totalItems to the end user, please note that it may be an approximation depending on the number of items returned by a search request.

2-week API Lookahead Window

The API will only return information about events that are due to take place within the next 14 days. This is to ensure that the amount of data returned is manageable (by reducing the EventSeries object size) and relevant (our research shows that the bookable window for most leisure operator members is 2 weeks in advance).

Maximum URL Length

Each API call should be limited to a maximum of 2,048 characters.

null Values and Empty Arrays

Across all of our APIs, we will remove any field if:

  • The value is null; or

  • The array is empty.

Archiving of EventSeries and FacilityUses

We archive ScheduledSessions and Slots that are in the past (startDate < now). If an EventSeries' ScheduledSessions are all archived, the EventSeries will no longer appear in By-ID search routes. This is also the case for a FacilityUse when all its Slots are in the past.

EventSeries/FacilityUse By-ID routes do not persist when all associated ScheduledSessions/Slots are in the past.

Parameters and the Number of Items Returned

The more parameters you add, the more specific you are being about what data you want the Platform to provide and so the less items an API call will return.

  • 0 parameters included in an API call = X thousand items^ returned;

  • 2 parameters included in an API call = X hundred items^ returned.

  • 6 parameters included in an API call = X hundred items^ returned.

^ These numbers are for illustrative purposes only.

Identifying Data Sources

However, identifier may not necessarily be simply an organisation's name. This is because, over time, feeds can be deprecated and replaced by a newer versions. As a result of this, we can end up with multiple identifiers from the same organisation in our Platform. To distinguish between them, we include the year the new feed is released, e.g. everyoneactive2020.

This is a general principle set out in the OpenActive Specification .

The data our Platform originates from a variety of organisations that publish open data, e.g. . These organisations, many of which are listed on OpenActive’s and , can be identified in our API by looking at "imin:dataSource": "identifier", e.g. activenorthumberland.

OpenActive modelling specification
OpenActive validator
API Reference
here
Status Page
Supplemental Status Page
Active Northumberland