Saltar para o conteúdo principal

API de Campanhas

Os exemplos abaixo mostram o cabeçalho no formato de rede Authorization: P2S-SIGN-V1 API_KEY:TIMESTAMP:SIGNATURE. Para calcular a assinatura no seu código, use o helper signedRequest em Autenticação.
A API de Campanhas permite que o seu backend leia as campanhas de incentivo da sua empresa no SalesOS — quais estão vigentes, o que a vitrine oferece, quanto cada colaborador tem para gastar e quantos prêmios ele já alcança. Foi feita para compor as suas próprias telas antes de o usuário abrir o módulo do SalesOS. É uma API somente leitura, servidor a servidor: você consulta colaboradores por CPF ou e-mail, em lote, e o SalesOS responde com as campanhas vigentes e o estado de cada pessoa nelas.
Uma campanha é configurada pela sua empresa: nome, vitrine, preços em pontos, categorias, regras de nível e até o nome da moeda. Esta API devolve o que estiver configurado — ela não conhece nenhuma campanha específica.

Como funciona

  1. Você recebe uma API Key com o escopo campaigns:read (Admin > Integrações > API Keys)
  2. Seu backend consulta o estado de um ou vários colaboradores (por CPF ou e-mail)
  3. O SalesOS responde com as campanhas vigentes — os dados da campanha uma vez, e o estado de cada colaborador em seguida
Os metadados da campanha saem uma vez no topo da resposta, não repetidos por pessoa. Num lote de 500 colaboradores isso é a diferença entre uma resposta enxuta e uma de megabytes.
Este endpoint não resgata prêmios nem aceita termos. É leitura — combine com a página da campanha (access.url) na hora da ação — veja Abrir a página da campanha.

Autenticação

Veja a página de Autenticação para criar e gerenciar API Keys.

Ambientes

URL base: https://api.play2sell.com

Referência do endpoint

Duas ações no campo action: campaign_status e campaign_catalog. Cada colaborador é identificado por CPF (qualquer formato — os dígitos são normalizados) ou e-mail. Quando os dois vêm, o CPF prevalece.

Ação: campaign_status

As campanhas vigentes da sua empresa e o estado de cada colaborador nelas.

Esquema da requisição

string
obrigatório
Deve ser "campaign_status"
array
obrigatório
Lista de referências de colaboradores (máximo 500)
string
CPF, em qualquer formato (52998224725 ou 529.982.247-25). Deve conter exatamente 11 dígitos.
string
E-mail — usado apenas quando o cpf está ausente
string
Filtra uma campanha específica. Ausente = todas as vigentes.
string
Idioma dos textos configuráveis. Ausente = o padrão da campanha.

Exemplo

Resposta (200):

Campos da campanha

O nome da moeda é resolvido nesta ordem: o rótulo configurado na campanha, depois a moeda cadastrada para a sua empresa (com singular e ícone), depois pontos. É o mesmo nome que a página da campanha mostra.

Campos do colaborador

spendable: 0 não significa “não tem pontos”. A carteira é habilitada por empresa; enquanto não estiver, o saldo vem zerado mesmo para quem tem pontuação. Sempre leia wallet_enabled antes de escrever “sem saldo” na tela — do contrário ela vai afirmar uma ausência que não existe.
Alcançar e poder pagar são contas diferentes. Um prêmio pode estar liberado pelo nível e ainda assim custar mais do que o colaborador tem. Por isso eligible_rewards e affordable_rewards são campos separados.

Ação: campaign_catalog

O mesmo conteúdo com o recorte de catálogo. Como a vitrine cresce por colaborador, o limite de lote cai para 100.

Abrir a página da campanha

Toda campanha vem com um bloco access: onde a página dela mora no app do SalesOS e como levar o usuário até lá. É na página que o usuário vê a vitrine e resgata os prêmios, e ela exige usuário autenticado. Há dois caminhos:
Leia access.url e access.login_url da resposta — não os fixe no seu código. A URL muda por ambiente (produção e staging têm apps diferentes).
O parâmetro de retorno só aceita um caminho dentro do app do SalesOS. URL completa, outro host ou qualquer outra coisa é ignorada, e o usuário cai na tela inicial.

Entrar de novo pelo provedor da sua empresa

O guia completo desse login (os dois jeitos, o que enviar e as recusas) está em SSO (Single Sign-On). Quando a sua empresa autentica os usuários no próprio provedor de login (OAuth 2.0 / OpenID Connect) e a Play2sell liga esse provedor ao SalesOS, a resposta traz access.login_url. Use-o como o link padrão para a página da campanha. Ele resolve o caso em que o usuário precisa se autenticar de novo:
Quem entrou por esse caminho e tem a sessão vencida dentro do app também volta pelo seu provedor, na mesma página onde estava, em vez de cair na tela de senha do SalesOS.
Leia access.login_url da resposta — não monte a URL no seu código. Ela muda por ambiente e só vem preenchida quando a ligação com o seu provedor está ativa naquele ambiente. Com null, use um dos outros caminhos.
Para ativar: a sua empresa cadastra a Play2sell como cliente OAuth 2.0 no seu provedor, um cliente por ambiente, com o endereço de retorno que passamos (https://auth.play2sell.com/login/callback em produção). Precisamos dos endereços de autorização e de token, do client ID e do secret (por canal seguro) e do identificador estável de cada usuário: o id interno do seu provedor, o CPF ou CNPJ ou o e-mail. Com CPF ou CNPJ, o usuário continua sendo a mesma pessoa no SalesOS mesmo se trocar de e-mail.
O login pelo seu provedor não abre a conta de quem não é da sua empresa: uma conta do SalesOS ligada a outra empresa, uma conta da equipe Play2sell ou um acesso desativado pelo seu gestor é recusado com uma mensagem que diz o que fazer.

Modo self (token do usuário do SSO)

Com o token de um usuário que entrou pelo SSO, envie Authorization: Bearer <jwt> e omita collaborators. A resposta cobre apenas o próprio usuário do token.
Enviar collaborators com um token de usuário é rejeitado com SELF_MODE_NO_COLLABORATORS. Consultas em lote exigem uma API Key de parceiro — do contrário, qualquer usuário autenticado poderia ler o saldo de outras pessoas por CPF.

Tratamento de erros

São dois formatos, não um. O bloco acima é o erro do endpoint. Falhas na camada de autenticação respondem antes de o endpoint rodar, com error como string:
Código que assume error.code lê undefined em toda falha de autenticação. Ramifique pelo tipo — veja Convenções da API.
Corpo inválido, lote acima do limite, CPF sem 11 dígitos, item sem cpf e sem email, ou campaign_slug malformado. A lista details indica o index do item.
Uma lista collaborators foi enviada junto com um token de usuário.
API Key ausente, inválida ou expirada, ou assinatura que não confere.
API Key válida, mas sem o escopo campaigns:read.
Apenas POST é aceito.
Requisições demais nesta hora. Aguarde retry_after segundos.
Erro interno. Tente de novo com espera progressiva (2s, 4s, 8s).
Nenhuma campanha vigente não é erro. A resposta vem com campaigns: [] e status 200 — a empresa pode simplesmente não ter campanha no ar.

Limites de uso


Segurança

  • Somente leitura: esta API nunca cria resgates, nem aceita termos, nem altera saldo
  • Cada chave pertence a uma única empresa — um CPF de outra empresa responde found: false, e campanhas de outras empresas nunca aparecem
  • As requisições são assinadas por HMAC (P2S-SIGN-V1) e registradas para auditoria; documentos nunca são gravados nos logs
Nunca exponha sua API Key em código do lado do cliente. Esta API deve ser chamada apenas pelo seu servidor.

Próximos passos

API de Missões

O progresso que gera os pontos gastos aqui

Autenticação

Como criar e gerenciar API Keys