# Changelog público

## 0.44.0 — Data · Bonos (2026-10-03)

- La tabla de packs ahora parte por los más recientes (selector Recientes / Más usados) y suma la columna Último canje. Un buscador sobre la tabla encuentra un pack por las palabras de su nombre, en cualquier orden y sin importar mayúsculas ni tildes: «halloween nivel» encuentra «Halloween - Nivel 5».
- Un admin de Data puede marcar un pack como descartado (con una nota opcional) y quitar la marca. Un pack descartado deja de contar en Emitidos y en los totales; el filtro «Estado del pack» (Activos, Descartados o Todos) lo muestra cuando se necesita. Si el pack tiene canjes, su dinero sigue contando.
- Para revisar suma dos avisos: «Posible pack descartado» (sin canjes y con la campaña terminada o creado hace más de 7 días) y «Pack descartado con canjes».
- Contrato OpenAPI 0.67.0: GET /data/bonuses/promo/packs suma sort y status, y cada pack trae last_used_at, discarded, discarded_at y discard_note; nuevos PUT y DELETE /data/bonuses/promo/packs/{id}/discard.

## 0.43.0 — Data · Depósitos (2026-10-03)

- La pestaña Indicadores de Depósitos muestra la efectividad real del cobro. Salud del cobro suma cuatro cifras: Efectividad real (pagados sobre pagados, fallidos, rechazados y pendientes que siguen abiertos 10 minutos después, con la diferencia en puntos contra la informada), Atascados ahora, Atascados en el período y Monto no cobrado.
- Efectividad real por método compara, para cada método, los intentos, la efectividad informada y la real, los atascados de ahora y su estado: Alerta abierta, Bajo el piso o Normal. Cada método también tiene su gráfico por hora (hora de Santiago) con el piso de efectividad y las horas bajo él en rojo, y la efectividad real diaria marca los días en que se abrió una alerta.
- El embudo de intentos muestra cuántos intentos terminaron pagados, fallidos, rechazados, cancelados, atascados o aún abiertos, con su porcentaje sobre los intentos. Para revisar avisa cuántos depósitos siguen abiertos hace más de 48 horas y lleva a Transacciones con los estados abiertos.
- Indicadores deja de mostrar Aprobación por método, Fallidos por hora, Fallidos por día de la semana, Frecuencia, ARPU, Mix y Promedio diario y proyección. Quedan, en «También en este período», los reintentos de jugadores, nuevos y recurrentes, los depositantes activos y el ticket promedio. La curva «¿Cuándo se pierde un pendiente?» y la columna «Centrivo vence a» llegan en el próximo corte.
- Contrato OpenAPI 0.66.0: GET /data/deposits/insights agrega real_effectiveness (as_of, stuck_minutes, floor_rate, totals, stuck_now, stale_open, by_method, by_hour y daily). Es opcional: una respuesta sin él sigue siendo válida.

## 0.42.0 — Data · Bonos (2026-10-02)

- Bonos suma la búsqueda por código: en Filtros, «Código promocional» busca un promo code exacto (sin distinguir mayúsculas) y la pestaña Promo codes muestra si se canjeó (cuántas veces, quién, cuándo, en qué pack y qué bono generó, con su estado: activo, cobrado, sin cobro, vencido o cancelado) y si la campaña de su pack está vigente, programada o vencida, con su fecha de fin. Aplicarlo desde otra pestaña lleva a Promo codes, y la búsqueda queda en la URL (?codigo=) para compartirla.
- Un código de un pack Single aparece aunque nadie lo haya canjeado. Un código de un pack Multiple o External solo aparece cuando alguien lo canjeó: sus códigos sin usar no se leen en Data.
- Contrato OpenAPI 0.65.0: nuevo GET /data/bonuses/promo/code con status, validity, uses, players, packs (vigencia de su campaña) y una página de canjes.

## 0.41.0 — Data · Cierre del día (2026-09-30)

- El Resumen de Data muestra cómo cierra cada día: la tabla Día a día suma Retiros pendientes (los retiros creados ese día que siguen sin resolver: pendiente, pago pendiente, en proceso o inicializado), Net cash si se pagan (el net cash del día si todos esos retiros terminan pagados; si se cancelan, vale la columna Net cash) y Hold (net cash sobre depósitos pagados del día).
- El CSV de Día a día agrega al final las columnas retiros_pendientes_clp, q_retiros_pendientes y net_cash_si_se_pagan_clp.
- Depósitos suma el indicador Depósitos fallidos: cuántos depósitos del período quedaron en estado Fallido y el monto que se intentó depositar.
- Retiros suma el indicador Retiros pendientes: el monto y la cantidad de retiros del período que siguen sin resolver.
- Alertas VIP se ordena por tipo de transacción: un bloque de Retiros y otro de Depósitos, cada uno con cuántas alertas, jugadores y monto tiene, filtros por tipo y por regla (retiro alto pendiente, retiro alto rechazado, depósitos fallidos seguidos e intento con autoexclusión) y una línea por alerta con el monto y el resultado del aviso.
- Integraciones pasa a ser una sola pantalla: una tarjeta por servicio conectado (Telegram, SendGrid, Twilio SMS, Intercom Fin, API de retención y códigos de premio), con su marca, estado, quién y cuándo la integró y la actualizó, un lápiz para editar la credencial y, en mensajería, el interruptor de encendido y apagado con confirmación al apagar. Las pestañas separan Mensajería, Soporte y Juegos; cada persona ve solo lo que puede administrar. Integraciones de soporte y API de retención se abren desde su tarjeta. Las tarjetas de Soporte y Juegos tienen además su interruptor: apagar una es una pausa (la API responde 503 integration_paused y los tokens se conservan; al encenderla vuelven a funcionar sin reemitir nada), y muestran quién y cuándo la integró y la actualizó. La pestaña Datos suma la tarjeta del conector de Centrivo.
- En Jugadores ya se puede buscar a una persona por su ID exacto desde Filtros: el campo «ID del jugador» acota el listado con sus indicadores, los rankings y los totales por jugador. El mismo filtro llega a Riesgo, Cohortes, Recuperación VIP, Bonos, Alertas VIP y Potencial VIP, y en Depósitos, Retiros, Apuestas casino y Apuestas deportes acota también los indicadores, no solo la tabla. El campo de Depósitos y Retiros ahora dice «ID exacto del jugador»: la búsqueda por correo que prometía nunca existió.
- La auditoría de la API de retención se recorre de a 20 llamadas por página, con el total del servidor; la página ya no crece con cada llamada.
- Contrato OpenAPI 0.64.0: GET /data/resumen agrega withdraw_pending_amount_minor, withdraw_pending_count y net_cash_if_pending_paid_minor en cada fila de daily; GET /data/retention/audit acepta offset (0 a 100000) para paginar con limit; nuevos GET y PUT /data/support/integration y GET /data/retention/integrations con PUT /data/retention/integrations/{integration} para pausar y reanudar; los listados de tokens suman created_by y revoked_by; las API de soporte y de retención responden 503 integration_paused mientras su integración está en pausa.

## 0.40.0 — API de retención · Administración y códigos de premio (2026-09-29)

- La página Data → API de retención se rehízo con el diseño Ledger: indicadores de hoy en una sola ventana (tokens vivos, llamadas de hoy contra ayer a la misma hora, porcentaje con error y cuántas fueron del servidor, tiempo de respuesta p95 y hasta cuándo están al día los depósitos), tokens con pestañas Vivos, Vencidos, Revocados y Todos, y el detalle del token elegido con sus llamadas de cada una de las últimas 24 horas en barras.
- Emitir un token se hace en un panel lateral con el cuerpo desplazable y el pie fijo: ¿para qué es? (juego, códigos de premio o pruebas), nombre, desde cuándo lee depósitos en hora de Chile (no aplica a los códigos de premio), vigencia de 1, 14 o 45 días u otra, packs como chips, IP opcional, un resumen «Así quedará» y cuántos tokens vivos quedan para la integración. Los ejemplos van en la ayuda bajo cada campo y ya no se leen como valores cargados.
- El token emitido se muestra una sola vez con Copiar, los pasos para cargarlo y una advertencia; «Listo» se habilita solo al marcar «Ya lo guardé». Revocar pide confirmación y avisa si es el único token vivo de la integración.
- La auditoría queda en hora de Chile, con pestañas Todas, Correctas y Con error, y columnas Consulta, Resultado, Motivo y Tiempo en español: cada error se explica con un motivo legible (por ejemplo «Cursor inválido» o el tope que se alcanzó) y la verificación de correo dice si coincidió. Filtrar por token, consulta, resultado o período lo resuelve el servidor, no las filas cargadas.
- El juego de retención de Juégalo recibe, servidor a servidor, todos los códigos de premio de sus packs de Centrivo (Multiple y External cuyo nombre contiene el patrón del token, por ejemplo «halloween»), sin cargarlos a mano: el conector lee cada pack nuevo completo una vez y lo vuelve a leer solo si su lista no coincide con la cantidad de códigos que declara Centrivo o si esa cantidad cambia.
- Nuevo GET /retention/promo/packs: los packs de la campaña con cuántos códigos declara Centrivo, cuántos tiene Convray y si el pack está completo. No entrega códigos.
- Nuevo GET /retention/promo/codes: feed por cursor cifrado que entrega cada código una sola vez, con cualquier tamaño de página, junto con si ya se canjeó, quién lo canjeó y cuándo. La fecha de cada código es la primera vez que Convray lo vio, porque Centrivo no la entrega.
- Los códigos son premios: Convray los guarda cifrados, los cruza con los canjes por un hash con clave sin descifrarlos y nunca los escribe en la auditoría, en los logs ni en la evidencia del conector.
- Credencial aparte: la integración nueva juego-codigos tiene su propio permiso (retention.codes) y solo lee packs y códigos. Un token juego-octubre no ve códigos y un token juego-codigos no ve depósitos, jugadores ni canjes; los dos responden 403 fuera de lo suyo y queda en la auditoría.
- El token de códigos se emite con las mismas reglas que el del juego: al menos un patrón de pack, 45 días como máximo sin lista de IP y dos tokens vivos para rotar sin corte. El piso de depósitos (deposits_from) no aplica: el token guarda el instante de emisión.
- Tope diario de 50.000 códigos por token (día UTC): cada página se acota a lo que queda del día, el exceso responde 429 con Retry-After hasta las 00:00Z y el servidor deja una alerta de volumen al llegar al 80 %.
- Contrato OpenAPI 0.62.0: nuevo GET /data/retention/summary (indicadores de hoy y actividad por hora de cada token); GET /data/retention/audit suma los filtros token y result, lee from y to en formato AAAA-MM-DD como días de Chile (to exclusivo) y devuelve totals con los conteos por resultado; nuevos GET /retention/promo/packs (pack_pattern) y GET /retention/promo/codes (cursor, limit, pack_pattern y pack_id); POST /data/retention/tokens acepta la integración juego-codigos, en la que deposits_from es opcional, y la auditoría suma los endpoints promo_packs y promo_codes.

## 0.39.0 — API de retención · Corte 2 (2026-09-29)

- Nueva verificación de correo sin PII: el consumidor manda el SHA-256 del correo que escribió el jugador y recibe solo si coincide o no con el correo de su cuenta. Convray nunca entrega el correo; un jugador inexistente, de otro tenant o sin correo responde igual que un correo distinto, y si Convray no puede leer el dato responde 503 en vez de un falso “no”.
- La verificación tiene topes propios (10 por jugador y día y 5.000 por día por token, además de 20 por minuto por jugador) que cuentan también las solicitudes inválidas. La auditoría registra si hubo coincidencia, sin guardar el hash ni el correo.
- Cada token admite como máximo 8 solicitudes en curso a la vez y toda la superficie 12; el exceso responde 429 con Retry-After, para que la API de retención no le quite conexiones al resto de Convray.
- La lista de IP de un token no admite rangos más anchos que /24 en IPv4 o /48 en IPv6.
- Cada token tiene un piso de fecha para los depósitos (deposits_from), fijado al emitirlo y que no cambia: los feeds nunca entregan depósitos creados antes de ese instante, aunque se pida un created_from menor o un since anterior. Un created_from menor se ajusta en silencio al piso.
- Nuevo feed de reversos (deposits/reversed): entrega cada depósito cuando Convray ve que dejó de estar pagado, con el mismo cursor, filtros y piso que el feed de pagados y el estado actual de cada depósito (un depósito que volvió a pagado sale como paid, para cerrar la alerta). Un cursor de un feed no sirve en el otro.
- Nueva consulta por jugador para el SAC (players/{ref}/deposits): lista solo los depósitos que llegaron a pagado, incluidos los revertidos después con su estado actual, desde el piso del token y con 500 consultas por día como máximo. Un jugador que existe sin depósitos pagados en la ventana responde con sus marcas y una lista vacía; el 404 queda solo para un jugador inexistente o de otro tenant.
- Nuevas marcas por jugador (players/flags): eligible, staff y test_player de hasta 100 jugadores por llamada, en el orden pedido, solo para jugadores con depósitos pagados desde el piso del token (el inicio de la campaña); los demás se cuentan en unknown sin nombrarlos. Un ref inválido rechaza toda la llamada, y el tope diario de 50.000 refs y el de 20 por minuto por jugador responden 429 para toda la llamada sin consumir cupo.
- El owner o un admin de Data emite, revisa y revoca los tokens de la API de retención desde Data → API de retención (juegos), sin usar la línea de comandos.
- Al emitir se elige la integración (juego-octubre para el juego, qa-retencion para las pruebas de aceptación), el nombre, desde qué fecha lee depósitos (hora de Chile), la vigencia, los patrones de pack (halloween por defecto) y, si se quiere, las IP o rangos CIDR permitidos. El token del juego sin lista de IP vence a los 45 días como máximo.
- El token completo se muestra una sola vez, con botón para copiarlo, y se descarta al cerrar el diálogo. Se permiten dos tokens vivos por integración para rotar sin corte; revocar pide confirmación y corta el acceso en la siguiente llamada.
- La lista muestra prefijo, integración, patrones, IP, desde, creación, vencimiento (con aviso cuando vence pronto), último uso y estado. La auditoría muestra las últimas llamadas con fecha, token, endpoint, status, código y filas devueltas, sin IP ni datos de jugadores.
- El juego de retención de Juégalo recibe, servidor a servidor, cada código de premio canjeado en el casino: qué código, de qué pack, qué jugador y cuándo, sin correos ni nombres. Un canje que entregó varios bonos llega una sola vez, con el estado de cada bono.
- El alcance lo fija el token: cada token de retención lee solo los packs cuyo nombre contiene sus patrones (para el juego, «halloween»). Pedir otro patrón responde 403 y un patrón vacío o de solo espacios, 400; los dos quedan en la auditoría.
- Los packs de código único (Single) salen sin el texto del código, porque sigue sirviendo para otros jugadores. Solo salen los códigos ya canjeados de packs Multiple y External.
- Convray guarda la primera vez que ve cada canje y ese instante no cambia: el feed avanza con un cursor cifrado y nunca repite ni salta canjes al paginar. Cada página dice hasta cuándo están completos los canjes de esos packs, sin adelantarse a lo ya entregado.
- El conector de Centrivo distingue las lecturas de packs a las que les faltan canjes de las que traen de más, y puede releer primero los packs de una campaña para que sus canjes lleguen antes.
- Contrato OpenAPI 0.61.0: nuevos POST /retention/players/{ref}/email-check, GET /retention/deposits/reversed, GET /retention/players/{ref}/deposits, GET /retention/players/flags y GET /retention/promo/redemptions (cursor, since, limit y pack_pattern, con la frescura del patrón en promo_data_through y promo_backlog_packs); POST /data/retention/tokens exige deposits_from y rechaza rangos de IP anchos; los tokens emitidos y listados muestran deposits_from.

## 0.37.0 — Data · Integraciones y alertas por Telegram (2026-09-28)

- El super_admin carga las credenciales de SendGrid, Twilio SMS y del bot de Telegram desde Data → Integraciones. Se guardan cifradas, no vuelven a mostrarse y cada proveedor se prueba, se activa y se apaga sin tocar el servidor.
- Activar un proveedor exige una prueba correcta en los últimos 30 minutos. Apagarlo corta los envíos al instante.
- Equipos de alertas (Riesgo, Operaciones, SAC y Pagos al inicio): cada uno se vincula a su grupo de Telegram con un enlace de un solo uso que vence en 15 minutos.
- Las alertas de pagos VIP, intento de depósito de un autoexcluido, Potencial VIP, caída de efectividad por método de pago y calidad de datos llegan al grupo de cada equipo según sus rutas, sin datos personales y con enlace a Convray.
- Muchas alertas del mismo tipo se juntan en un solo mensaje; cada equipo puede fijar un horario silencioso que las alertas críticas ignoran.
- Contrato OpenAPI 0.60.0: GET /integrations, PUT /integrations/{code}, POST /integrations/{code}/test, /enable y /disable, DELETE /integrations/{code}/secret, GET /integrations/audit, /alert-teams (listar, crear, editar, borrar, enlace de vinculación y prueba), GET/PUT /alert-routes y GET /alert-deliveries.

## 0.36.0 — Data · Efectividad de pagos con historial (2026-09-28)

- Nuevas cifras de efectividad de hoy, ayer, el mes en curso, el mes anterior y los últimos 12 meses, con la diferencia en puntos contra el período de comparación.
- Nuevo gráfico por día (últimos 30 días) y por mes (últimos 12 meses) para cada método de pago, con el porcentaje en cada barra.
- Las barras de las últimas 24 horas rotulan cada hora y muestran el porcentaje dentro de cada barra.
- Contrato OpenAPI 0.59.0: GET /data/payment-methods/health suma history con la efectividad por día y por mes del total y de cada método.

## 0.35.0 — Acceso: código por correo al iniciar sesión e invitaciones por correo (2026-09-27)

- Al iniciar sesión con correo y contraseña, Convray pide además un código de 6 dígitos que llega a tu correo. El código vence en 10 minutos, admite 5 intentos y sirve una sola vez.
- Puedes pedir un código nuevo un minuto después del anterior, hasta 3 veces por inicio de sesión; cada código nuevo invalida el anterior.
- Si marcas “Confiar en este dispositivo”, ese navegador no vuelve a pedir el código durante 30 días. Cambiar tu contraseña anula todos los dispositivos de confianza.
- Las invitaciones de equipo ahora llegan por correo al crearlas o al regenerar el enlace. El enlace de un solo uso sigue disponible para compartirlo a mano si el correo no llega.
- Contrato OpenAPI 0.58.0: POST /auth/sessions puede responder 202 con el desafío del código; nuevos POST /auth/sessions/email-otp y POST /auth/sessions/email-otp/new-code; las invitaciones de equipo agregan email_sent.

## 0.34.0 — Data · Bonos por vertical (2026-09-27)

- Cada bono entregado tiene su vertical: los FreeBet de deporte son Deporte, los FreeBet
  de casino y los giros son Casino, el saldo real queda aparte y los bonos con rollover
  (Wager) toman la del producto que les asigna Centrivo. Una campaña que entregó bonos de
  casino y de deporte es Mixta.
- El resumen, las campañas y el rollover se pueden filtrar por vertical (Todas, Casino o
  Deporte). El filtro es por bono: una campaña Mixta aparece en las dos verticales con
  solo sus bonos de cada una.
- El resumen suma lo regalado y lo cobrado por vertical y lo regalado por día, semana o
  mes, repartido por vertical y en días civiles de Chile. El rollover compara Casino y
  Deporte, y cada bono de una campaña Mixta se ve junto a sus hermanos.
- La ficha del jugador muestra sus bonos por vertical y tipo (Free Spins, Free Bet, bono
  con rollover y saldo real) y la vertical de cada bono.
- Contrato OpenAPI 0.57.0: `GET /data/bonuses/summary`, `/data/bonuses/campaigns`,
  `/data/bonuses/rollover` y `/data/bonuses/rollover/bonus/{bonusId}` aceptan
  `vertical=all|casino|sport`; el resumen acepta `granularity=day|week|month` (día hasta 92
  días de período, semana hasta 1.092 y mes hasta 3.653; más largo responde 422) y suma
  `by_vertical` y `series`; las campañas suman `vertical` y `vertical_grants`; el rollover
  suma `by_vertical`; el bono suma `vertical` y `siblings`; y
  `/data/players/{ref}/profile/bonuses` suma `by_vertical` y la `vertical` de cada fila.
  Sin operaciones nuevas.

## 0.33.1 — Data · Bonos: Campaña Sportsbook (2026-09-27)

- Toda campaña con al menos un FreeBet de deporte (Sportsbook) tiene el propósito
  "Campaña Sportsbook", diga lo que diga su nombre: sale de misiones, regalías, registro,
  ruletas y el resto de los propósitos por nombre, se filtra y se suma aparte en Bonos y
  se muestra en la ficha del jugador. Una marca manual sigue ganando, y la marca de prueba
  no cambia.
- Contrato OpenAPI 0.56.0: `DataBonusPurpose` suma `campana_sportsbook` (resumen por
  propósito, listado y ficha de campañas, filtro `purpose` y bonos de la ficha del
  jugador). Sin operaciones ni campos nuevos.

## 0.33.0 — Data · módulo Bonos (2026-09-26)

- El módulo Bonos, en Jugadores y apuestas, muestra lo regalado y lo cobrado a dinero
  real en el período (por defecto los últimos 45 días), cuántos bonos se cobraron,
  terminaron sin cobro, vencieron, se cancelaron o siguen activos, y cómo se reparte por
  propósito y por tipo de bono (Free Spins, Free Bet, bono con rollover y saldo especial).
- Cada campaña, regalía cross-platform o campaña normal, tiene su ficha: qué pasó con sus
  bonos, cuántos jugadores recibieron más de uno, lo que depositaron sus receptores los 7
  días antes y después del inicio, y los receptores con más cobrado.
- Rollover muestra los bonos que activó un depósito: cuánto se depositó, el bono, el
  rollover exigido y lo que quedó en dinero real. Promo codes muestra los packs y, por
  cada uso, el jugador y el bono que generó. Para revisar reúne las campañas con muchos
  vencidos, las recreadas, los códigos usados sin bono y las campañas de prueba.
- La ficha del jugador suma la sección Bonos: lo que recibió y cobró, por tipo de bono,
  lo que jugó con bono en casino y deportes, y sus últimos bonos, en histórico o este mes.
- Las cuentas de prueba y el staff no suman salvo que actives "Incluir pruebas y staff",
  y cada bono entregado se cuenta una sola vez. Solo se muestra el Player ID de Centrivo,
  sin nombres ni correos de jugadores.
- Contrato OpenAPI 0.55.0: nueve lecturas nuevas, `GET /data/bonuses/summary`,
  `/data/bonuses/campaigns`, `/data/bonuses/campaigns/{kind}/{id}`,
  `/data/bonuses/rollover`, `/data/bonuses/rollover/bonus/{bonusId}`,
  `/data/bonuses/promo/packs`, `/data/bonuses/promo/packs/{id}/uses`,
  `/data/bonuses/review` y `/data/players/{ref}/profile/bonuses`.

## 0.32.5 — Data · Regalías: campañas normales con depósito disparador y promo codes (solo lectura) (2026-09-26)

- En cada corrida, el reporte "Regalías (bonos)" de Cargas lee además las campañas
  normales de Centrivo, como los bonos VIP por depósito, con sus fechas y su disparador.
  Sus bonos entregados se releen con las mismas reglas que las regalías cross-platform:
  campañas recientes, con bonos abiertos o con bonos cerrados hace poco, y la historia
  completa de madrugada.
- Cuando un depósito activó el bono, Data guarda el monto y el ID de esa transacción, la
  fecha en que se activó y el turnover exigido, y lo enlaza con el depósito que ya tiene
  cuando el ID coincide.
- Los packs de promo codes (Single, Multiple y External) quedan con su campaña y cuántos
  códigos se usaron; por cada uso, el código, el jugador, la fecha y el bono que generó,
  si generó uno. Los usos se releen solo en los packs que cambiaron. No se guardan
  correos ni nombres de jugadores.
- Un bono entregado cuenta una sola vez: Centrivo muestra el mismo bono en las
  Statistics de la campaña, en las del bono y en los usos del código, y Data lo guarda
  por su ID y solo enlaza las otras vistas; nunca se suman por separado.
- Nada se modifica en Centrivo: el conector solo lee, por una lista cerrada de rutas
  `GET`. Todavía no hay una vista de Bonos en Data; estos datos quedan listos para ella.
- Contrato OpenAPI 0.54.1: solo cambia la descripción del reporte `bonuses` en
  `GET /data/connector/centrivo` y `POST /data/connector/centrivo/run`. Sin operaciones
  ni campos nuevos.

## 0.32.4 — Data · Regalías desde Centrivo (solo lectura) (2026-09-26)

- En cada corrida (según el intervalo configurado en Cargas), el conector de Centrivo
  lee las campañas cross-platform (regalías como Giros Diamante y Zafiro) con su nombre,
  estado y creador, y la lista de jugadores de prueba de Centrivo. Los bonos entregados
  por jugador, con su estado, montos, giros y lo canjeado, se releen en las campañas
  recientes, con bonos abiertos o con bonos cerrados hace poco; la historia completa se
  trae de madrugada.
- Cargas suma la fila "Regalías (bonos)" en Centrivo automático, al final de los
  reportes, con el resultado de su última corrida y el botón "Correr ahora". No baja
  archivo, así que Filas y Tamaño se muestran con "—".
- Nada se modifica en Centrivo: el conector solo lee, por una lista cerrada de rutas
  `GET`, y no guarda nombres ni correos de jugadores. Las campañas y cuentas de prueba
  quedan marcadas como tales.
- Contrato OpenAPI 0.54.0: `GET /data/connector/centrivo` suma la fila `bonuses` y
  `POST /data/connector/centrivo/run` acepta `report` `bonuses`. Sin operaciones nuevas.

## 0.32.3 — Eliminar notificaciones de la campana (2026-09-26)

- La campana y la bandeja de notificaciones suman "Eliminar todas", junto a "Marcar
  todas": después de confirmar, vacía la bandeja de una vez, con las notificaciones
  leídas y no leídas, y avisa cuántas eliminó.
- `POST /notifications/dismiss-all` elimina todas las notificaciones visibles de la
  cuenta en el casino en uso y devuelve cuántas (`{"dismissed": n}`).
- Es un borrado lógico: las notificaciones eliminadas dejan de listarse y de contar
  como no leídas, no se marcan como leídas y no se borran del registro. Solo alcanza
  tus propias notificaciones. Contrato OpenAPI 0.53.0.

## 0.32.2 — GGR por día de un juego con los filtros de la vista (2026-09-26)

- `GET /data/casino-bets/games/{gameId}/daily` aplica las mismas dimensiones que el
  ranking de juegos: proveedor, categoría, dispositivo, sus exclusiones y los filtros
  por jugador `tag`, `flag` e `isp`.
- El juego es siempre el del path, aunque la consulta traiga otra lista de juegos;
  así la serie cuadra con los totales del juego en esa vista.

## 0.32.1 — Rol de equipo en la sesión y enlaces de la campana (2026-09-25)

- `GET /me` incluye en cada membresía `team_role_code` y `team_role_label` (por
  ejemplo `finanzas` / "Finanzas"); son `null` para el owner y para los accesos
  personalizados. El menú de perfil muestra el cargo real de la persona.
- La etiqueta del rol se resuelve para la membresía activa; las demás membresías
  traen el código con la etiqueta en `null`.
- Las alertas de calidad de datos enlazan a `/{casino}/calidad` y las Alertas VIP a
  `/{casino}/alertas-vip` en Data; el aviso de ticket resuelto abre en el producto
  desde el que se reportó, y el de ticket nuevo, en el producto desde el que lo abres.
  Las notificaciones anteriores con enlaces rotos quedan corregidas.
- El contrato OpenAPI 0.50.0 documenta en `/me` los campos que la API ya devolvía
  (`display_name`, `notification_preferences`, `products`, entre otros).
- Data, Work y CRM suman Perfil de cuenta (`/{casino}/cuenta`) y una bandeja de
  notificaciones (`/{casino}/notificaciones`), también disponible en Afiliados; el
  menú de perfil enlaza a la página de la puerta en uso.

## 0.32.0 — Efectividad de pagos por método (2026-09-25)

- Data suma la vista Efectividad de pagos: por cada método de pago (Tarjeta,
  Transferencia, Mach…) muestra la efectividad de la última ventana, la efectividad
  normal de los días cerrados y barras por hora de las últimas 24 horas
  (`GET /data/payment-methods/health`, de 1 a 72 horas).
- La efectividad es pagados / (pagados + fallidos + rechazados); los pendientes y los
  cancelados por el operador quedan fuera del denominador. No reemplaza el KPI
  "Conversión de depósitos".
- Cuando un método aprueba muy por debajo de lo normal, Convray abre una alerta (a lo
  sumo una abierta por método), avisa en la campana, crea tareas en Work y envía un
  correo según los ajustes del casino, y la cierra sola cuando el método se recupera
  (`GET /data/payment-method-alerts`).
- El admin de Data marca una alerta como revisada con una nota
  (`PATCH /data/payment-method-alerts/{id}`) y ajusta umbrales, métodos silenciados y
  canales (`GET/PUT /data/payment-method-alert-settings`). Las alertas solo llevan
  agregados, sin datos de jugadores. Contrato OpenAPI 0.50.0.

## 0.31.1 — Estado de Ray y cambio de modo (2026-09-24)

- El estado de Ray (`GET /assistant/status`) indica el motivo cuando no responde
  (desactivado, sin proveedor, sin modelo, sin llave o llave ilegible), y cambiar de
  modo o editar el perfil ya no consume el límite de intentos de inicio de sesión.

## 0.31.0 — Configuración de Ray desde Data (2026-09-24)

- El super_admin administra Ray desde Data → Asistente → Configuración: activa o apaga
  el asistente, elige proveedor y modelo, carga la llave de API y prueba la conexión.
- La llave se guarda cifrada y nunca se vuelve a mostrar completa; solo se ven sus
  últimos cuatro caracteres, la fecha de carga y quién la cargó.
- Los topes de gasto mensuales (plataforma, base y excepción por departamento, base y
  excepción por usuario) se administran en la misma pantalla; un departamento puede
  compartir su tope con otro.
- Un mensaje se bloquea al alcanzar cualquiera de los topes e indica cuál. El gasto se
  registra con el departamento de la persona al momento del mensaje.
- La configuración aplica al siguiente mensaje, sin reiniciar el servidor; cada cambio
  queda en un registro que nunca incluye la llave.

## 0.30.2 — Sesión y baseline de seguridad

- Volver o recargar la landing conserva la identidad y ofrece el dashboard que
  corresponde a la sesión vigente.
- Las renovaciones se coordinan entre pestañas; una respuesta de refresh obsoleta
  no borra una cookie rotada más recientemente.
- Toda respuesta `/api/v1` incluye `Cache-Control: private, no-store`,
  `Pragma: no-cache` y `X-Content-Type-Options: nosniff`.
- Next.js, Sharp, Nano ID, PostCSS y Go se actualizan a versiones corregidas.

## 0.30.1 — Enlace privado de invitación

- Casino Admin copia una URL de entrega única para incorporar al Account
  Manager sin compartir una contraseña temporal.
- El token viaja en el fragmento `#token`, no se envía en solicitudes HTTP y la
  página lo retira del navegador antes de aceptar la invitación.
- La persona invitada define su propia contraseña; el endpoint continúa
  recibiendo token y contraseña exclusivamente en el body.

## 0.30.0 — Equipo casino

- Casino Admin puede invitar múltiples Account Managers con tokens opacos de
  entrega única.
- Account Manager recibe dashboard, deals y tracking en modo solo lectura.
- Suspender o revocar incrementa la autoridad de la membresía e invalida sus
  sesiones anteriores.
- El tenant se deriva exclusivamente de la sesión; los cuerpos no aceptan un
  `tenant_id` elegido por el cliente.

## 0.29.0 — Piloto con acceso privado

- El registro público queda cerrado por defecto en la web y en la API.
- `POST /partner-registrations` responde `public_registration_closed` antes de
  leer el body o crear entidades, y deja evidencia de denegación.
- Login, sesiones existentes, landing y Streamer Sites continúan disponibles.
- `PUBLIC_REGISTRATION_MODE=open` es el único valor que vuelve a habilitar el
  alta pública; `closed` e `invite_only` fallan cerrados.

## 0.28.0 — Partner administrado exclusivo

- Un partner puede operar exclusivamente con un casino principal sin perder su
  Streamer Site ni las capacidades de comunidad.
- API y PostgreSQL rechazan deals con otro casino.
- El perfil expone `operating_model` y `home_casino_tenant_id` como solo lectura.
- La actividad social no se presenta como conversión del casino; el match
  viewer-jugador requerirá un marcador inequívoco devuelto por el proveedor.

## 0.23.1 — APC-4 Tracking

- APC-4 queda limitado a tracking opaco.
- Destinos versionados y allowlisted, links con al menos 128 bits de entropía,
  click ledger durable previo al redirect y visitor keys con retención máxima de
  90 días.
APC-1 Identity, APC-2 programas/ofertas, APC-3 Relationship y la extensión
histórica Streamer Sites se conservan.