> ## 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.

# Prepartido y en vivo

> Cómo se modelan prepartido e in‑play, y el vínculo parent_id.

Un partido aparece primero en **prepartido** con su `event_id`. Al pitido inicial, Pinnacle crea un **evento en vivo separado** (con su propio `event_id`), vinculado al prepartido mediante **`parent_id`**.

* Las cuotas prepartido viven bajo el `event_id` de prepartido.
* La serie in‑play (con `score_home`, `score_away`, `red_cards_*` en cada línea) vive bajo el `event_id` del hijo en vivo.

## Encontrar el hijo en vivo de un partido

```bash theme={null}
# a partir de un event_id de prepartido, obtener el hijo en vivo
curl "https://api.apinn.io/api/fixtures?parent_id=1630436278&live=1" \
  -H "X-API-Key: TU_CLAVE"
```

El partido principal es la línea cuyo `resulting_unit = "Regular"`.

## live\_status

El campo `live_status` de un fixture vale:

| Valor | Significado                                       |
| ----- | ------------------------------------------------- |
| `0`   | Prepartido (pitido inicial por venir).            |
| `1`   | En vivo (in‑play).                                |
| `2`   | Terminado (pitido inicial pasado, ya no en vivo). |

## Córners, tarjetas y variantes

Córners y Bookings son **fixtures separados** que apuntan al partido principal mediante `parent_id`. Con `parent_id=X` (sin `live`), obtienes esas variantes; con `live=1`, el hijo en vivo.

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