> For the complete documentation index, see [llms.txt](https://help.runonrufus.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.runonrufus.com/public-api/getting-started/overview.md).

# Overview

At the heart of the timing layer are **devices**, **sessions**, and **passings**:

* A **device** is any hardware or software capable of detecting a competitor at a specific point—typically by reading a bib number or chip and assigning it a timestamp.
* A **session** is created by a device to group a set of passings during a specific timing operation.
* A **passing** represents a single recorded event: a competitor identifier and a timestamp generated by a device.

The typical flow is simple:\
a device authenticates using an API key → creates a session → sends passings to that session.

On top of this ingestion layer, the API now exposes an **event and participant data model**, enabling deeper integrations:

* An **event** represents a race or competition managed within the RUFUS ecosystem.
* **Participants** are the competitors registered in an event, including their identifiers (bib, chip, etc.) and associated data.

This allows external systems not only to send timing data, but also to **consume and manage event-related information**, such as listing events, retrieving participants, or creating new participant records (depending on API key permissions).

Before interacting with any of these resources, access must be granted through an **API key**, which defines the level of permissions (read, write, or both) available to your integration.

Together, these components provide a complete workflow—from capturing raw timing data in the field to integrating structured event information in the cloud.