> ## Documentation Index
> Fetch the complete documentation index at: https://tournaments-partners.exuratech.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Token de admin e integration key

> Qué permite cada credencial y cuál exige cada paso de una competencia.

Las competencias usan **dos credenciales bearer independientes**. Aunque ambas se envían en la cabecera `Authorization`, la API comprueba un tipo distinto en cada ruta. No son intercambiables.

| Acción | Token de admin | Integration key de esa competencia | Sin token |
| - | - | - | - |
| Crear una competencia | Sí | No | No |
| Editarla y configurar premios | Sí | No | No |
| Consultar datos administrativos, inscritos e incidentes | Sí | No | No |
| Generar o rotar la integration key | Sí | No | No |
| **Registrar un login participante en el endpoint CRM** | **No** | **Sí** | **No** |
| Consultar metadatos, ranking e historial públicos | No requerido | No requerido | Sí |

> [!WARNING]
>
> Un token de admin **no registra participantes** en `POST /api/v1/integrations/competitions/{uuid}/participants`. Ese endpoint exige la **integration key de la competencia indicada en la URL**. Enviarle el token de admin devuelve `401 Invalid integration key`. La integration key tampoco permite crear ni editar competencias.

## 1. Obtener el token de admin

Un administrador autorizado inicia sesión con `POST /api/v1/admin/auth/login` y recibe `access_token`. Su rol y compañía determinan qué competencias puede gestionar. Exura Tech debe haber creado o autorizado esa cuenta administrativa. Un `SUPER_ADMIN` puede crear un token de sistema para un administrador mediante una ruta distinta, pero ese token **sigue siendo administrativo**, no una integration key CRM.

```http theme={"theme":{"light":"github-light","dark":"github-dark"}}
POST /api/v1/competitions
Authorization: Bearer <admin-access-token>
Content-Type: application/json
```

Con el mismo tipo de token se llama `POST /api/v1/competitions/{uuid}/integration-key`. La respuesta incluye `token`: **ese nuevo valor** es la integration key, se muestra una sola vez y debe entregarse por un canal seguro al backend del CRM.

## 2. Usar la integration key desde el CRM

```http theme={"theme":{"light":"github-light","dark":"github-dark"}}
POST /api/v1/integrations/competitions/{uuid}/participants
Authorization: Bearer <competition-integration-key>
Idempotency-Key: <stable-crm-event-id>
Content-Type: application/json

{"mt5_login":12345678}
```

El CRM debe conservar una clave de idempotencia estable por evento. Reintentar el mismo evento con el mismo login devuelve la inscripción existente; usar la misma clave para otro login devuelve `409`. La clave de una competencia no sirve para inscribir en otra.

## 3. Publicar el ranking

`GET /api/v1/competitions/{uuid}`, `GET .../leaderboard` y `GET .../participants/{participant_uuid}/history` son públicos. Un frontend propio o el embed puede leerlos sin exponer ninguna de las dos credenciales. La inscripción, en cambio, debe salir del servidor del CRM, no de JavaScript público.

## Rotación y almacenamiento

El secreto CRM solo se devuelve cuando se genera o rota. `GET .../integration` indica si existe, pero no permite recuperarlo. Una rotación invalida inmediatamente la clave anterior; coordina el cambio con el CRM. Guarda el token de admin en el backend o sesión administrativa segura y la integration key en un gestor de secretos del backend CRM. No los pongas en URL, iframe, repositorio público ni logs.

> **[API administrativa](/broker/admin-api)**
>
> Inicio de sesión, roles y creación de competencias.

> **[Registrar cuentas](/broker/registro)**
>
> Cuerpo, idempotencia y ventana de inscripción.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.