Saltar al contenido principal

Endpoint Get User Data

Este endpoint debe entregar a menta tech la lista de boletos que posee un usuario, dado su identificador (generalmente, el correo electrónico o su número de telefóno).

Los códigos de respuesta deben respetar los estándares HTTP; SuperSwap Lite los utilizará para interpretar los distintos estados que puede tener (o no) un usuario.

URL de ejemplo: https://tusistema.com/api/getUserTickets?email=useremail@gmail.com

HTTP 200 (OK)​

Si la respuesta es 200, el usuario existe en el sistema y posee boletos. En el cuerpo (body) de la respuesta, incluya los boletos que posee el usuario siguiendo la siguiente estructura:

[
    {
        "eventId": 7704,
        "showId": 7704,
        "paidPrice": 165000,
        "ticketType": 33,  // Gradas Delanteras
        "seating": {
            "row": "D",
            "seat": 10,
            "section": "Grada A1"
        },
        "properties": {
            "orderId": 77089031,
        }
    },
    {
        "eventId": 7704,
        "showId": 7704,
        "paidPrice": 165000,
        "ticketType": 33,  // Gradas Delanteras
        "seating": {
            "row": "D",
            "seat": 11,
            "section": "Grada A1"
        }
    }
]

Si el boleto no tiene información de seating o planimetría, no incluya los campos row ni seat.

Los campos eventId, showId, paidPrice y ticketType son mandatorios.

Referencias:

  • eventId -> identificador UNICO del evento.
  • showId -> identificador de la performance. Si trabajan con eventos con una sola performance, es una buena práctica usar el mismo valor para showId.
  • paidPrice -> precio final abonado por el usuario para este boleto. Incluir, en lo posible, cargos adicionales al boleto.
  • ticketType -> identificador del TIPO/CATEGORÍA DE BOLETO que adquirió; si la "PLATEA SUR" corresponde al ID 442, enviar 442.
  • seating (opcional) -> si la performance trabaja con planimetría, enviar la mayor cantidad de datos posibles. La propiedad section se puede omitir si no está disponible o no aplica.

HTTP 204 (No Content)​

Con este código de respuesta, se entiende que el usuario está registrado en la plataforma pero no posee boletos. Esto es útil para permitir a los compradores acceder a la compra sin pasar previamente por el flujo de registro de boletas, en caso de que el registro de usuarios sea obligatorio.

HTTP 404 (Not Found)​

El usuario no existe en la boletera. Este estado es crucial si se requiere registro de usuario para comprar. Bajo este código, menta tech obligará al usuario a registrarse para poder comprar boletos en el mercado secundario.

Seguridad​

Un factor importante a tener en cuenta es la seguridad del endpoint para prevenir accesos no autorizados.

En este sentido, menta tech ofrece dos alternativas que incluso se pueden combinar:

Token de autenticación​

Al igual que en la comunicación vía Webhook, menta tech venía un encabezado en la petición (Header) con una clave secreta compartida entre ambas partes. El encabezado se llama X-Shared-Secret. De esta forma, se puede verificar que la petición viene de menta tech.

IP Allowlist​

Otra forma de asegurar la seguridad es mediante una lista habilitada de IPs. Todas las peticiones que haga menta tech a su endpoint serán desde la siguiente dirección de IP:

Dirección de IP: 23.21.128.177

ACERCA DE LA IP

Por el momento la única dirección de IP de salida es la mencionada anteriormente. En caso de que la IP de salida cambie o se agreguen nuevas, nos comunicaremos a fines de informar este cambio.

Consideraciones​

Tenga en cuenta lo siguiente al momento de crear el endpoint y su respuesta.

Boletos dados de baja​

menta tech necesita conocer cuándo un usuario deja de tener en su poder un boleto. Esto puede deberse a que:

  1. El usuario utilizó una funcionalidad nativa de transferencia y deja de poseer el boleto.
  2. El boleto se cancela por un contracargo, por compra errónea o por cualquier otra razón.
  3. El boleto se intercambió en el mercado secundario provisto por menta tech.
  4. Cualquier otra razón no enumerada que provoque que el usuario deje de tener en su poder el boleto.

En cualquiera de estos casos, es imperativo que en la respuesta del endpoint no figure el boleto dado de baja en cuestión.

Frecuencia e instancias de consulta​

Este endpoint será consultado por menta tech en tres escenarios:

Al iniciar el flujo de venta​

Cuando el usuario vendedor inicia el flujo de venta, menta tech consultará el endpoint para conocer qué boletos posee el usuario. Con base en esa información, se le permitirá vender esos boletos siempre y cuando correspondan a eventos y funciones registrados en menta tech. Este endpoint puede devolver información de eventos que por alguna razón no trabajen con menta tech; sin embargo, solo se permitirá vender aquellos donde el mercado secundario esté habilitado y se respeten las reglas de publicación.

Al momento de comprar el boleto​

Justo antes de confirmar la compra de los boletos, menta tech solicitará nuevamente información acerca de los boletos con el fin de recibir cualquier actualización que haya ocurrido desde la última consulta. Esto evitará que boletos que hayan sido dados de baja por alguna razón puedan ser vendidos en el mercado secundario.

Cada 12 horas, luego de la publicación​

Se ejecutará un proceso automático que actualizará cualquier cambio de estado cada 12 horas, siendo la primera consulta 12 horas después de la publicación. Esto se realiza de esta forma para capturar cualquier cambio antes de la compra y no ofrecer falsas expectativas a los usuarios. El período de consulta siempre se cuenta 12 horas desde la última consulta. A modo de ejemplo:

Boleto A -> Se publica 3:00 AM -> Su próxima consulta es a las 3:00 PM del mismo día.

Boleto B -> Se publica 7:00 PM -> Su próxima consulta es a las 7:00 AM del día siguiente.

De esta forma se evita sobrecargar el sistema, distribuyendo las consultas cada 12 horas.