{"id":2941,"date":"2026-10-05T02:39:11","date_gmt":"2026-10-05T02:39:11","guid":{"rendered":"https:\/\/whitelotto.com\/?p=2941"},"modified":"2026-10-05T23:42:46","modified_gmt":"2026-10-05T23:42:46","slug":"lottery-api-integration-guide","status":"publish","type":"post","link":"https:\/\/whitelotto.com\/es\/lottery-api-integration-guide\/","title":{"rendered":"Gu\u00eda de integraci\u00f3n de API de loter\u00eda: qu\u00e9 debe especificar el operador"},"content":{"rendered":"\n

Una integraci\u00f3n de API de loter\u00eda no est\u00e1 terminada cuando la primera solicitud devuelve una respuesta satisfactoria. Lo est\u00e1 cuando el operador puede seguir una transacci\u00f3n entre sistemas, resolver un resultado incierto sin generar una segunda compra y atender al jugador sin adivinar qu\u00e9 sistema es la autoridad.<\/p>\n

Esta gu\u00eda de integraci\u00f3n de API de loter\u00eda sirve como documento para compradores e implementadores. Explica qu\u00e9 especificar antes de elegir una modalidad de entrega y qu\u00e9 pruebas solicitar antes de aceptar el trabajo. No es documentaci\u00f3n de la API de WhiteLotto: los ejemplos describen requisitos que deben acordarse, no endpoints, m\u00e9todos de autenticaci\u00f3n, integraciones ni funciones incluidas confirmados. Empiece por la descripci\u00f3n de la soluci\u00f3n WhiteLotto<\/a> y acuerde despu\u00e9s el alcance real de las interfaces con el equipo de entrega.<\/p>\n

Empiece por los l\u00edmites de la integraci\u00f3n, no por una lista de endpoints<\/h2>\n

Identifique qu\u00e9 sistema controla la cuenta del jugador, el registro de movimientos del monedero, el registro del boleto, la informaci\u00f3n del sorteo, la decisi\u00f3n de verificaci\u00f3n y la comunicaci\u00f3n con el cliente. Una interfaz independiente, un back office existente del operador y un servicio de pagos externo crean l\u00edmites distintos. Una API puede exponer una funci\u00f3n sin transferir la responsabilidad operativa correspondiente.<\/p>\n

Dibuje el recorrido de una transacci\u00f3n y marque cada traspaso. Para cada l\u00edmite, registre el sistema que llama, el registro autoritativo, la acci\u00f3n permitida, la respuesta esperada y el responsable de un estado no resuelto. Incluya acceso al back office e informes: una integraci\u00f3n que permite comprar pero impide a finanzas conciliar est\u00e1 incompleta.<\/p>\n

Incluya este mapa en el documento de evaluaci\u00f3n de proveedores<\/a>. Clasifique cada capacidad solicitada como disponible y acreditada, configurable, personalizada, dependiente de terceros o fuera de alcance. No trate una funci\u00f3n de la hoja de ruta como una interfaz comprometida.<\/p>\n

Prepare un registro de requisitos al que los proveedores puedan responder<\/h2>\n

Utilice una fila por interfaz u operaci\u00f3n de negocio, en lugar de una sola fila titulada \u00abintegraci\u00f3n de API\u00bb. A\u00f1ada responsable, prioridad, dependencia, referencia de evidencia y decisi\u00f3n de aceptaci\u00f3n a estas preguntas.<\/p>\n

\n
Requisitos de API de loter\u00eda que deben resolverse antes de implementar<\/caption>
\u00c1rea<\/th>Requisito que debe definirse<\/th>Evidencia que debe solicitarse<\/th><\/tr><\/thead>
Contrato de interfaz<\/th>Operaciones, campos, identificadores, errores, versi\u00f3n y entorno admitido.<\/td>Especificaci\u00f3n versionada y ejemplos representativos de solicitudes y respuestas con datos sint\u00e9ticos.<\/td><\/tr>\n
L\u00edmite de acceso<\/th>Clientes, roles, marcas y recursos permitidos; emisi\u00f3n, rotaci\u00f3n y revocaci\u00f3n del acceso.<\/td>Matriz de acceso y pruebas de acciones denegadas para el despliegue acordado.<\/td><\/tr>\n
Dinero y boletos<\/th>Registros autoritativos, transiciones de estado, cierre de ventas y tratamiento de duplicados.<\/td>Traza que conecte las referencias del boleto, monedero y proveedor.<\/td><\/tr>\n
Eventos as\u00edncronos<\/th>Autenticaci\u00f3n, duplicados, orden, reintentos y recuperaci\u00f3n tras una interrupci\u00f3n.<\/td>Contrato de eventos documentado y resultados de casos de fallo.<\/td><\/tr>\n
Capacidad y l\u00edmites<\/th>Picos previstos, concurrencia, tiempos de espera, l\u00edmites de solicitudes y respuesta a sobrecargas.<\/td>Hip\u00f3tesis de carga acordadas y pruebas del alcance correspondiente.<\/td><\/tr>\n
Datos e informes<\/th>Campos necesarios, conservaci\u00f3n, permisos de exportaci\u00f3n, marcas de tiempo y vistas de conciliaci\u00f3n.<\/td>Diccionario de datos y muestra de exportaci\u00f3n utilizable, sin registros personales.<\/td><\/tr>\n
Cambios y soporte<\/th>Compatibilidad, aviso de retirada, responsabilidad en incidentes y condiciones de salida.<\/td>Proceso de publicaci\u00f3n, escalado y alcance contractual.<\/td><\/tr>\n<\/tbody><\/table><\/div>\n

La especificaci\u00f3n OpenAPI<\/a> ofrece una forma est\u00e1ndar de describir interfaces HTTP. Pregunte si la interfaz propuesta dispone de una descripci\u00f3n actualizada, qu\u00e9 versi\u00f3n utiliza y qu\u00e9 comportamientos requieren documentaci\u00f3n adicional. Un contrato legible por m\u00e1quinas facilita la revisi\u00f3n; no demuestra la correcci\u00f3n de las transacciones, la seguridad ni el soporte operativo.<\/p>\n

Acuerde el modelo de datos y el sistema de registro<\/h2>\n

Mapee los identificadores entre el operador, la plataforma y el servicio externo. Distinga el identificador de solicitud del identificador de boleto, la referencia de pago y el asiento del registro de movimientos. Decida c\u00f3mo puede soporte relacionarlos sin introducir informaci\u00f3n personal en URLs o registros de acceso irrestricto.<\/p>\n

Especifique importes, monedas, precisi\u00f3n, zonas horarias, significado de las marcas de tiempo y definiciones de estado. \u00abAceptado\u00bb puede significar recibido para procesamiento, no boleto confirmado. \u00abPagado\u00bb puede describir un evento del procesador, no la liquidaci\u00f3n definitiva. Documente qui\u00e9n puede cambiar cada estado y c\u00f3mo se registran las correcciones.<\/p>\n

Para datos de sorteos y resultados, defina la fuente autoritativa, la actualidad, la pol\u00edtica de correcciones y qui\u00e9n liquida los boletos afectados. Especifique la zona horaria del cierre de ventas y la regla para solicitudes pr\u00f3ximas a ese l\u00edmite; una cuenta atr\u00e1s en la interfaz no determina la aceptaci\u00f3n del boleto.<\/p>\n

Solicite \u00fanicamente la informaci\u00f3n del jugador que necesita cada integraci\u00f3n. Defina acceso, conservaci\u00f3n, exportaci\u00f3n y uso permitido con los responsables adecuados. La gu\u00eda sobre titularidad de datos del jugador<\/a> distingue el acceso operativo \u00fatil de las cuestiones contractuales y de privacidad m\u00e1s amplias. La conectividad t\u00e9cnica no establece el derecho a transferir o reutilizar registros.<\/p>\n

Dise\u00f1e para resultados inciertos y mensajes repetidos<\/h2>\n

Considere una compra sint\u00e9tica en la que el servicio receptor acepta la solicitud, pero la conexi\u00f3n se cierra antes de que llegue la confirmaci\u00f3n al emisor. Un tiempo de espera agotado no demuestra que no haya ocurrido nada. La especificaci\u00f3n necesita un mecanismo admitido para establecer el resultado original y evitar que un reintento produzca un segundo efecto financiero.<\/p>\n

La sem\u00e1ntica HTTP de RFC 9110<\/a> distingue las operaciones idempotentes y desaconseja reintentar autom\u00e1ticamente solicitudes no idempotentes sin saber que es seguro. Para compras y cambios en el monedero, acuerde la pol\u00edtica de duplicados de la aplicaci\u00f3n, la duraci\u00f3n de su protecci\u00f3n y qu\u00e9 ocurre si llega la misma referencia con contenido diferente. No deduzca esas garant\u00edas \u00fanicamente del m\u00e9todo HTTP.<\/p>\n

Para eventos o callbacks, pregunte c\u00f3mo el receptor verifica el origen, detecta duplicados, gestiona entregas tard\u00edas o desordenadas y recupera el procesamiento omitido. Como referencia espec\u00edfica de un proveedor, la documentaci\u00f3n de webhooks de Stripe<\/a> aborda firmas, eventos repetidos y procesamiento as\u00edncrono. Es un ejemplo de las preguntas que debe responder el contrato, no evidencia de que WhiteLotto utilice Stripe o admita el mismo modelo de eventos.<\/p>\n

La aceptaci\u00f3n debe vincular el resultado final de negocio con sus registros: una compra prevista, el efecto acordado en el monedero, un estado de boleto trazable y una excepci\u00f3n con responsable si la confirmaci\u00f3n sigue pendiente. Aplique la misma disciplina a reembolsos, anulaciones y liquidaci\u00f3n. La gu\u00eda de la infraestructura de pagos de loter\u00eda<\/a> explica por qu\u00e9 una respuesta de pago satisfactoria y una conciliaci\u00f3n \u00fatil son requisitos diferentes.<\/p>\n

Incluya seguridad y capacidad en la aceptaci\u00f3n<\/h2>\n

Confirme el mecanismo real de autenticaci\u00f3n, los permisos de acceso, el responsable de credenciales y los procesos de almacenamiento, rotaci\u00f3n y revocaci\u00f3n. Nunca introduzca credenciales de producci\u00f3n en un documento de compra, ejemplo compartido o c\u00f3digo entregado al navegador. Separe los entornos y utilice datos sint\u00e9ticos en demostraciones.<\/p>\n

La autorizaci\u00f3n debe comprobarse para la operaci\u00f3n y el recurso solicitado, no solo para la existencia de una sesi\u00f3n v\u00e1lida. Solicite pruebas de un rol no autorizado, un l\u00edmite entre marcas o cuentas y un cliente revocado. El OWASP API Security Top 10<\/a> es una referencia \u00fatil sobre acceso a objetos, autenticaci\u00f3n, consumo de recursos e inventario. No es una certificaci\u00f3n ni demuestra que una plataforma concreta supere esos controles.<\/p>\n

Describa la carga prevista: tr\u00e1fico estable, un pico asociado a un sorteo, compras concurrentes, tareas de informes y recuperaci\u00f3n de eventos retrasados. Acuerde qu\u00e9 sucede al alcanzar los l\u00edmites y qu\u00e9 solicitudes pueden aplazarse con seguridad. Registre los l\u00edmites de medici\u00f3n de latencia y disponibilidad, incluidas dependencias, en lugar de introducir un objetivo de rendimiento sin fundamento. Utilice la lista de seguridad, disponibilidad y SLA<\/a> para ampliar la discusi\u00f3n sobre pruebas y escalado.<\/p>\n

Utilice un paquete de aceptaci\u00f3n peque\u00f1o pero completo<\/h2>\n

Registre la versi\u00f3n de interfaz, configuraci\u00f3n, entorno de prueba, datos sint\u00e9ticos, resultado esperado y evidencia real de cada prueba. Incluya emisor, receptor y responsable operativo. Una grabaci\u00f3n de pantalla por s\u00ed sola no acredita el estado resultante del registro de movimientos o del boleto.<\/p>\n