> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apinn.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Prematch & live

> How prematch and in-play are modeled, and the parent_id link.

A match first appears in **prematch** with its `event_id`. At kickoff, Pinnacle creates a **separate live event** (its own `event_id`), linked to the prematch by **`parent_id`**.

* Prematch odds live under the prematch `event_id`.
* The in-play series (with `score_home`, `score_away`, `red_cards_*` on each line) lives under the live child's `event_id`.

## Finding a match's live child

```bash theme={null}
# from a prematch event_id, fetch the live child
curl "https://api.apinn.io/api/fixtures?parent_id=1630436278&live=1" \
  -H "X-API-Key: YOUR_KEY"
```

The main match is the line where `resulting_unit = "Regular"`.

## live\_status

A fixture's `live_status` field is:

| Value | Meaning                                 |
| ----- | --------------------------------------- |
| `0`   | Prematch (kickoff upcoming).            |
| `1`   | Live (in-play).                         |
| `2`   | Ended (kickoff passed, no longer live). |

## Corners, cards & variants

Corners and Bookings are **separate fixtures** pointing to the main match via `parent_id`. With `parent_id=X` (without `live`), you fetch these variants; with `live=1`, the live child.

```bash theme={null}
curl "https://api.apinn.io/api/fixtures?parent_id=1630436278" \
  -H "X-API-Key: YOUR_KEY"
```