> For the complete documentation index, see [llms.txt](https://docs.lsports.eu/u/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lsports.eu/u/engage/hyper-livescore/enumerations/incident-kinds.md). # Incident Kinds ## Overview The Incidents Queue delivers messages categorized by **Kind**. Each Kind represents a different type of event and has its own message structure and timing rules. All incident messages share common fields (MessageId, Timestamp, Fixture, Decision Info, etc.) but each Kind has unique conditional fields that define its specific behavior. *** ## Kinds Summary | Kind | Description | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Score** | Reports a scoring event (goal, point, run, etc.) when it occurs. Each Score message represents one scoring play, with `seconds` capturing the in-period time the play occurred (not a continuous clock value). | | **Period** | Reports period state changes when a period starts (Status = "Started") or ends (Status = "Finished") for halves, quarters, sets, etc. | | **Statistic** | Reports in-game team statistics such as corners, yellow cards, attacks, shots, fouls, and offsides. Updates continuously as statistics change during the match. | | **Player Statistic** | Reports individual player statistics such as shots on target, tackles, passes, and goals. Sent when player-specific events occur and accumulates throughout the match. | | **VAR** | Reports Video Assistant Referee review processes and decisions. Sent when VAR review begins or when a VAR decision is made. | | **Timer** | Reports the match clock. This is the continuous in-period clock you should use to reconstruct game-time progression. | | **Possession** | Reports ball possession percentage for each team. Updates continuously during the match, typically every few seconds. Match-wide statistic with no period breakdown. | | **Status Description** | Reports fixture-level status changes that are not tied to specific game events. Provides period-specific status updates. | | **Fixture Status** | Reports overall fixture status changes such as NSY, In Progress, Finished, Cancelled, Postponed, Interrupted, Abandoned, AboutToStart, etc. Status codes range from 0–10. | | **Turn** | Reports which team currently has the turn, i.e. the team on the offensive (e.g. serving side, batting side, team in possession). Sent when the turn changes between teams. | | **Stoppage Time** | Reports the added time announced for a period (for example +5), as its own message. Sent when added time is announced or revised. Football only. | *** ## Core Incident Kinds ### 1. Score Reports a scoring event (goal, point, run, etc.) when it occurs. Each Score message represents one scoring play. The `seconds` field on a Score message is the in-period time at which the scoring play occurred, as captured at the moment that message was generated. It is **not** a continuous clock value and should not be used to reconstruct game-time progression. To track the live match clock, use the [Timer](#id-6-timer) incident. A single real-world scoring play may be republished with an updated confidence value as the incident is confirmed. Successive messages for the same play can carry slightly different `seconds` readings as the in-period time is refined, not the match clock moving backwards. The latest message at the highest confidence represents the best-known view of that play. Each period starts at 0-0 and position IDs remain constant throughout the match (Position 1 = Home, Position 2 = Away). The period score resets to 0-0 at the start of each new period. *** ### 2. Period **Purpose:** Reports period state changes (start/end of halves, quarters, sets, etc.) **When sent:** * When a period starts (Status = "Started") * When a period ends (Status = "Finished") *** ### 3. Statistic **Purpose:** Reports in-game statistics (corners, yellow cards, attacks, shots, etc.) **When sent:** * Continuously throughout the match as statistics change * Frequency varies by statistic type *** ### 4. Player Statistic **Purpose:** Reports individual player statistics. **When sent:** * When player-specific events occur * Accumulates throughout the match *** ### 5. VAR **Purpose:** Reports VAR review processes and decisions. **When sent:** * When VAR review begins * When VAR decision is made *** ### 6. Timer Reports the match clock. This is the continuous in-period clock you should use to reconstruct game-time progression. Sent periodically during the match. Announced added time is not part of the Timer. It arrives as its own [Stoppage Time](#id-11-stoppage-time) incident. The Timer is monotonic within a period in the direction dictated by the sport: * Sports with a count-up clock (e.g., Football): the value increases. * Sports with a count-down clock (e.g., Basketball): the value decreases. When you need "the current game time," read `seconds` from the Timer incident, not from any other incident kind. *** ### 7. Possession **Purpose:** Reports ball possession percentage. **When sent:** * Continuously updates during match, typically every few seconds *** ### 8. Status Description **Purpose:** Reports fixture-level status changes not tied to specific game events. **When sent:** * When overall match status changes *** ### 9. Fixture Status **Purpose:** Reports overall fixture status changes. **When sent:** * When match status changes (NSY, InProgress, Finished, Cancelled, etc.) *** ### 10. Turn **Purpose:** Reports which team currently has the turn — the team on the offensive (e.g. serving side, batting side, team in possession). **When sent:** * When the turn passes from one team to the other *** ### 11. Stoppage Time Reports the added time announced for a period, for example +5 at the end of the first half. Because added time arrives as its own message instead of being folded into the match clock, you can keep markets open through added time and close them when the period actually ends. **When sent:** * When added time is announced for a period * When the announced added time is revised (for example, from +5 to +6) A repeat of the same value for the same period is not resent. **How to read it:** * `seconds` is the announced added time in seconds (for example, `300` for +5). It is not the match clock. For the current game time, use the [Timer](#id-6-timer) incident. * `period` is the period the added time belongs to: 1st Half, 2nd Half, OT 1st Half, or OT 2nd Half. * `values` is `null`. * The latest Stoppage Time message for a period is the current value. It applies until that period finishes. You won't receive a separate "stoppage time ended" message. Treat the period as over when you receive a [Period](#id-2-period) incident with Status = "Finished", or a [Fixture Status](#id-9-fixture-status) update to Finished. **Coverage:** Football only. Values range from 0 to 1200 seconds (20 minutes). **Example** ```json { "header": { "MessageId": "5b0e2f61-9a7c-4c1e-b6f3-2d8e4a1c7f90", "Timestamp": "2026-10-04T19:46:10Z", "MessageType": 2 }, "body": { "status": null, "id": 2661, "fixtureId": 123456, "name": "StoppageTime", "kind": "StoppageTime", "values": null, "seconds": 300, "period": { "id": 10, "name": "1st Half" }, "confidence": 1.0 } } ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.lsports.eu/u/engage/hyper-livescore/enumerations/incident-kinds.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.