Acesso à API Necessário do Operador
Os operadores são obrigados a fornecer endpoints específicos à Plataforma de Engajamento da Gamanza para facilitar a integração fundamental. Mais detalhes sobre esses endpoints podem ser encontrados abaixo.
Integração
Para fornecer uma integração de API adequada, a plataforma dos Operadores deve fornecer os endpoints solicitados pela Plataforma de Engajamento da Gamanza. A Plataforma de Engajamento da Gamanza suporta os seguintes métodos de autenticação que devem ser implementados pela plataforma dos Operadores:
- Chave da API
- OAuth2.0 client_credentials
As opções de configuração para esses métodos de autenticação são fornecidas no site de administração.
Fluxos:
-
O PEP autentica-se no Servidor de Autorização dos Operadores Auth0 usando seu ID de Cliente e Segredo do Cliente ( endpoint /oauth/token).
-
O Servidor de Autorização dos Operadores Auth0 valida o ID de Cliente e o Segredo do Cliente.
-
O Servidor de Autorização dos Operadores Auth0 responde com um Token de Acesso.
-
O PEP pode usar o token de acesso para chamar uma API em nome de si mesmo, usando o cabeçalho HTTP
x-authorization. -
A API responde com os dados solicitados.
Configuração de Autenticação da API da Plataforma de Operadores
Para registrar seu método de autenticação de plataforma no Gamanza Engage, siga as próximas etapas:
- Faça login no seu Painel de Administração e navegue até as Configurações do Sistema. Encontre o menu chamado Integração de Plataforma, clique nele e então encontre a Configuração de Autenticação da API da Plataforma de Operadores:
- Atualize sua configuração, escolhendo o método de autenticação e adicionando as informações necessárias. Dois métodos de autenticação são suportados:
- Chave da API
- Credenciais do Cliente OAuth
E é isso!! Agora a Plataforma de Engajamento da Gamanza pode enviar solicitações aos seus Sistemas.
Pontos de Extremidade da API Necessários do Operador
Os pontos de extremidade relevantes para a API do Operador são:
Bônus de Crédito
O Operador precisa fornecer o ponto de extremidade da API de Bônus de Crédito para garantir que a Plataforma de Engajamento Gamanza possa automatizar o crédito de bônus.
O jogador deve se tornar elegível para o bônus imediatamente após a ativação. No entanto, se o Operador está processando interações de bônus com seus jogadores, isso determinará isso.
Para mais detalhes, confira a Especificação da API Aberta aqui.
Para atribuir um bônus aos jogadores, leve em consideração que você, como operador, precisa validar essa solicitação como idempotente. Enviamos uma propriedade especial chamada eventDate e requestId para ajudá-lo a identificar solicitações duplicadas.
Por exemplo, se sua API retornar um erro (timeout, econnreset, rate-limit, 400, 500, etc), nossa plataforma realiza uma nova tentativa usando um mecanismo de recuo e enviamos a solicitação inteira novamente até que uma das seguintes condições seja atendida:
- A solicitação é bem-sucedida
- O número máximo de tentativas é atingido -> a plataforma realiza até 5 operações de nova tentativa
Sempre enviamos a solicitação inteira de volta e esperamos que você processe o bônus em segundo plano, pois essa API espera um código de status 202 (código de status 202 Aceito significa que a solicitação foi aceita para processamento, mas o processamento ainda não foi concluído).
Aqui está alguma documentação sobre os códigos de status HTTP e seus significados: Códigos de status de resposta HTTP
Lista de Bônus
Para garantir uma experiência perfeita para os operadores de cassino e agentes de marketing, você deve fornecer uma API de Lista e Filtro de Bônus. Habilitar essa API permite que os bônus apareçam como menus suspensos amigáveis ao usuário na plataforma, minimizando erros humanos ao configurar novas recompensas no PEP.
Se você não implementar a API da Lista de Bônus, seus Operadores de Cassino terão que usar uma entrada de texto para adicionar o ID da Oferta de Bônus.
Para mais detalhes, confira a Especificação da API Aberta aqui.
Considerações Importantes dos Filtros da Lista de Bônus
As propriedades de filtro devem oferecer suporte a vários valores para acomodar integrações que exigem informações adicionais. Esses filtros permitem que a interface de usuário administrativa do PEP exiba as opções apropriadas com base nos requisitos específicos da integração.
Para clientes que têm um mecanismo de bônus padrão/simples onde apenas o nome é necessário, a API solicita os dados com base em filtros simples, como:
HTTP GET: https://your-api.customer-server-domain.com/api/bonus/v1/get-bonus/all?page=1&perPage=10&filterBy=name&filterValue=BonusWelcome
| Parâmetros de Consulta | Valor |
|---|---|
| page | 1 |
| perPage | 10 |
| filterBy | nome |
| valorDoFiltro | BonusVinda |
Quando precisamos passar filtros extras, uma abordagem comum seria permitir vários valores para os parâmetros filterBy e filterValue, usando uma lista na string de consulta.
HTTP GET: /api/bonus/v1/get-bonus/all?page=1&perPage=10&filterBy[]=name&filterValue[]=BonusVinda&filterBy[]=currency&filterValue[]=CRC
| Parâmetros da Consulta | Valor |
|---|---|
| page | 1 |
| perPage | 10 |
| filterBy[] | name |
| filterBy[] | currency |
| filterValue[] | BonusVinda |
| filterValue[] | CRC |
No lado do seu backend, dependendo do framework que você está usando, você precisará iterar pelos parâmetros da consulta e coletar os pares filterBy e filterValue. Em muitos frameworks web, os parâmetros de consulta com a mesma chave podem ser tratados como uma matriz ou lista. Por exemplo:
filterBy[]=name&filterValue[]=BonusVinda&filterBy[]=currency&filterValue[]=CRC
Construindo a lógica de consulta:
Após capturar os critérios de filtro, você pode então construir sua consulta ao banco de dados ou lógica de filtragem de dados para aplicar cada filtro.
Por exemplo:
const filterBy = req.query.filterBy || [];
const filterValue = req.query.filterValue || [];
// Criar um objeto para armazenar os filtros
const filters = {};
for (let i = 0; i < filterBy.length; i++) {
filters[filterBy[i]] = filterValue[i];
}
Please take into consideration that even if you support multiple filters; if in the request there is only one filter
criteria, our system performs the request sending only one key and one value like so: filterBy=name&filterValue=BonusWelcome
Somente se detectarmos um filtro extra, enviamos a solicitação no formulário de matriz: filterBy[]=name&filterValue[]=BonusVinda&filterBy[]=currency&filterValue[]=CRC
Isso é para manter a compatibilidade com as integrações existentes
Os filtros desempenham um papel fundamental no aprimoramento da interface administrativa, tornando mais fácil para sua equipe de marketing trabalhar de maneira eficiente. No mínimo, o filtro de nome deve ser implementado. Com base em seus requisitos de integração, você é responsável por adicionar quaisquer filtros adicionais necessários para dar suporte ao seu caso de uso.
Verificação da Sessão do Jogador
Um dos principais e necessários endpoints é o Processo de Verificação da Sessão do Jogador. Como você pode ver na seção de introdução, nossas Widgets UI precisam autenticar os jogadores para proteger as solicitações dos jogadores da sua interface de cassino para nossa plataforma.
Como não temos acesso para validar ou verificar a autenticação de seus jogadores, dependemos de você para verificar a sessão atual do jogador e sua validade. Este endpoint funciona como um "SSO", onde você atua como um Provedor de Identidade.
Nossa configuração de widgets requer algo chamado de token de identidade. Precisamos que você implemente uma API para receber esse valor e validar se o jogador tem uma sessão válida e ativa. Assim que recebermos sua confirmação, adicionando o ID do jogador na resposta, podemos criar nosso próprio processo de autorização.
For more details check the Open API Specification here.
Confira nosso Fluxo da API do Cliente de Widgets para mais detalhes.
Este pedido é realizado apenas uma vez, na primeira vez que os Widgets são inicializados na sua Interface do Usuário do Casino ou quando a sessão entre os widgets e nosso servidor expira.
API de Reconciliação
Se você está usando o CRM e por regulamentação há informações que seus jogadores precisam atender para receber Campanhas de Marketing, o PEP pode identificar se há informações faltantes para os jogadores que você registra em nossa plataforma.
Para garantir o alinhamento de dados entre sua plataforma e o PEP, é essencial desenvolver um processo de reconciliação. Este processo serve como uma falha segura para garantir que, se o PEP detectar alguma informação de jogador ausente, você (o operador) será notificado para sincronizar as informações ausentes usando as operações CRUD de jogador do PEP. Para evitar problemas de regulamentação, os pedidos de reconciliação são armazenados em um log de auditoria.
For more details check the Open API Specification here.