Cambios del contrato público.

0.44.0

Promo codes: los packs más nuevos primero, búsqueda por nombre y packs descartados.

• 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

Indicadores de Depósitos mide la efectividad real del cobro y señala los pendientes atascados.

• 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

Bonos busca un promo code y dice si se canjeó y si su campaña ya venció.

• 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 muestra cómo cierra el día con los retiros pendientes, cuenta los depósitos fallidos y pagina la auditoría de la API de retención.

• 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

La pantalla de la API de retención muestra el día de un vistazo y emite tokens desde un panel lateral, y el juego recibe los códigos de premio de sus packs con una credencial aparte.

• 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

La API de retención suma la verificación de correo sin PII y nuevos controles para los tokens de máquina.

• 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

Nueva pantalla Integraciones: SendGrid, Twilio SMS y un bot de Telegram que avisa a cada equipo.

• 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

Efectividad de pagos muestra hoy, el mes y los meses anteriores, además de las últimas 24 horas.

• 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

Iniciar sesión pide un código que llega a tu correo y las invitaciones de equipo se envían solas.

• 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

Bonos separa Casino y Deporte: cada bono y cada campaña tienen su vertical.

• 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

Las campañas con FreeBet de deporte se agrupan como Campaña Sportsbook.

• 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 suma Bonos: regalías, campañas, rollover y promo codes de Centrivo, y la sección Bonos en la ficha del jugador.

• 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

El conector de Centrivo suma las campañas normales, el depósito que activó cada bono y los promo codes usados.

• 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

El conector de Centrivo trae las regalías, los bonos entregados y las cuentas de prueba.

• 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

Elimina todas las notificaciones de la bandeja de una vez.

• 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.
• Es un borrado lógico: las 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

El GGR por día de un juego respeta los filtros de la vista.

• 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

El rol de equipo viaja en la sesión y los avisos abren la página correcta.

• GET /me incluye en cada membresía team_role_code y team_role_label; 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.
• 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 y alerta automática.

• GET /data/payment-methods/health muestra por método la efectividad de la última ventana, la base de los días cerrados, el estado y barras por hora UTC (de 1 a 72 horas).
• La efectividad es pagados / (pagados + fallidos + rechazados); los pendientes y los cancelados por el operador quedan fuera del denominador.
• GET /data/payment-method-alerts lista los episodios de la alerta (a lo sumo uno abierto por método) y PATCH /data/payment-method-alerts/{id} los marca revisados con una nota.
• GET/PUT /data/payment-method-alert-settings administra umbrales, métodos silenciados y canales campana, Work y correo; las alertas solo llevan agregados, sin datos de jugadores.

0.30.2

La landing reconoce la sesión y la API evita caches de datos sensibles.

• Volver o recargar la landing conserva la identidad y ofrece un enlace al dashboard autorizado.
• Las renovaciones se coordinan entre pestañas y un refresh obsoleto ya no borra una cookie más nueva.
• Toda respuesta /api/v1 incluye no-store, no-cache y nosniff.
• Dependencias web y toolchain Go se actualizan a versiones sin vulnerabilidades conocidas alcanzables.

0.30.1

Account Manager recibe un enlace de un solo uso y define su contraseña.

• Casino Admin copia una URL de invitación en lugar de compartir token y contraseña temporal.
• El token viaja en el fragmento #token, no forma parte de la solicitud HTTP y se retira de la barra del navegador al abrir la página.
• La aceptación envía el secreto exclusivamente en el body y permite que la persona invitada defina su contraseña.

0.30.0

Account Managers con acceso operacional de solo lectura.

• Casino Admin invita múltiples Account Managers mediante tokens opacos de entrega única.
• Account Manager consulta dashboard, deals y tracking sin administrar equipo, ofertas ni configuración.
• Suspender o revocar una membresía incrementa su autoridad e invalida sus sesiones anteriores.
• Los endpoints de equipo derivan siempre el casino desde la sesión y nunca aceptan tenant_id en el body.

0.29.0

Registro público cerrado, login disponible.

• La configuración fail-closed deja el registro público cerrado por defecto en web y API.
• POST /partner-registrations responde public_registration_closed antes de leer el body o crear entidades.
• El rechazo queda auditado; un fallo de auditoría impide confirmar la denegación como operación normal.
• Login, sesiones existentes, landing y Streamer Sites permanecen disponibles.

0.28.0

Partner exclusivo con Streamer Site intacto.

• El partner administrado queda ligado de forma inmutable a su casino principal.
• API y PostgreSQL rechazan relaciones con otro casino sin retirar el modelo global del producto.
• Streamer Site, YouTube, Kick, Discord, sorteos, juegos y comunidad continúan como extensión creator aislada.
• La actividad social no equivale a conversión; el match individual requiere un marcador retornado por el proveedor.

0.23.1

Tracking opaco y click ledger.

• Destinos estables, versiones inmutables, links opacos y click ledger durable antes del redirect.
• Casino y partner administran únicamente las acciones permitidas por su sesión y por el estado del deal.
• La matriz Affilka documenta interoperabilidad futura sin adelantar ingesta de eventos.
• APC-4 no calcula comisiones; redirect_issued no prueba llegada al destino remoto.

0.22.0

Aceptación, provisioning y deal partner-casino.

• El partner resuelve una oferta publicada, acepta términos versionados y crea una aplicación idempotente.
• Las rutas /partner/deals y /casino/deals aíslan ambas vistas por sesión.
• Casino Admin provisiona L0/L1, activa con mapping no secreto y administra suspensión o cierre.
• Tracking, eventos y cálculo financiero permanecen fuera de APC-3.

0.21.0

CPA, RevShare NGR e Hybrid.

• Las versiones de oferta admiten importe CPA, porcentaje RevShare sobre NGR o ambos componentes.
• El contrato agrega revshare_bps y base fija ngr.
• API y PostgreSQL rechazan combinaciones económicas incompletas.
• Cálculo, reversals y liquidación permanecen en APC-6.

0.20.0

Programa, ofertas y Casino Landing B2B.

• /casino/programs administra el programa primario con versión optimista.
• /casino/offers separa identidad estable y versiones comerciales inmutables.
• La publicación copia solo condiciones vigentes allowlisted.
• /public/casinos/{casino_slug} reemplaza la ruta pública legacy.

0.19.0

Identidad partner global.

• POST /partner-registrations reemplaza la ruta retirada POST /auth/registrations.
• creator_enabled habilita la extensión creator opcional sin redefinir la identidad partner.
• GET/PATCH /partner/profile incorpora perfil, canales y concurrencia optimista.
• GET /me lista membresías y PATCH /auth/sessions/current cambia el workspace rotando credenciales.