Procedimento de Atendimento de Suporte – API Parceiros

Procedimento de Atendimento de Suporte – API Parceiros

1. Objetivo

2. Escopo

3. Classificação dos Atendimentos

3.1 Dúvidas sobre a API

• Respondidas com base na documentação oficial
• Sempre direcionar o parceiro para o trecho específico da documentação
• Evitar interpretação fora do escopo documentado

3.2 Erro de API Key Inválida

• Se a API Key existe
• Se está ativa
• Se pertence ao ambiente correto:
  • Homologação
  • Produção

• Orientar o parceiro sobre uso correto
  

3.3 Problemas de Token de Acesso

• Token expirado (validade de 12 horas)
• Aplicação não renovou o token
• Token inválido gerado

• Confirmar horário de geração do token
• Validar fluxo de autenticação
• Caso necessário, acionar apoio do time de Code

3.4 Erros em Rotas Fora do Horário Comercial

• Execução de rotinas do sistema CrefazOn fora do horário comercial
• Possíveis indisponibilidades temporárias

• Validar data e hora da requisição
• Confirmar existência de rotinas programadas
• Orientar parceiro a reprocessar a requisição

3.5 Dúvidas sobre Produtos

Produto Consignado

• Disponível somente na API V2
• Validar versão utilizada pelo parceiro

Produto Luz em Dia

• Operação não disponível via API
• Processo realizado apenas via interface do CrefazOn

• Esclarecer corretamente o comportamento esperado
• Direcionar para o canal correto quando aplicável

3.6 Erros sem Causa Aparente

• Sem erro de sintaxe
• API Key válida
• Usuário não bloqueado

• Coletar evidências obrigatórias:
  • Payload da requisição
  • Endpoint utilizado
  • Data e hora
  • API Key
  • Usuário
• Encaminhar para o time de Code

3.7 Confusão entre API Key e Usuários

• Parceiros com múltiplos usuários (ex: corban)
• Associação incorreta entre usuário e API Key

• Validar vínculo entre usuário e API Key
• Esclarecer funcionamento de autenticação

3.8 Solicitação de API Key

• Parceiro não possui API Key de homologação ou produção

• Informar que a solicitação deve ser feita via time comercial
• Direcionar para o fluxo correto

3.9 Problemas Técnicos e Bugs

• Possíveis falhas após release
• Comportamento inesperado

• Usuário ativo
• API Key existente
• Ambiente correto
• Versão da API utilizada
• Sintaxe correta da requisição

• Coletar evidências completas
• Escalar para o time de Code

4. Metodologia de Atendimento

4.1 Recebimento

• Registro do chamado
• Identificação do parceiro
• Classificação do tipo de demanda

4.2 Análise Inicial

• Verificação de erros básicos
• Validação de credenciais
• Checagem de ambiente

4.3 Investigação

• Análise de logs (quando aplicável)
• Validação técnica do cenário
• Coleta de evidências

4.4 Resolução

• Resposta direta ao parceiro quando aplicável
• Orientação técnica
• Ação corretiva

4.5 Escalonamento

• Encaminhamento para time de Code quando necessário
• Inclusão de todas as evidências coletadas

4.6 Encerramento

• Confirmação com o parceiro
• Registro da solução
• Classificação final do atendimento

5. Evidências Obrigatórias

• API Key
• Usuário
• Ambiente (Homologação/Produção)
• Endpoint
• Payload
• Data e hora da requisição
• Mensagem de erro

6. Pontos de Atenção

• Diferença entre ambiente de homologação e produção
• Expiração de token
• Uso incorreto de versão da API
• Associação incorreta de usuário e API Key
• Execuções fora do horário comercial
• Falta de evidências no chamado

7. Boas Práticas

• Sempre responder com base em evidência
• Evitar suposições
• Padronizar respostas
• Documentar decisões
• Manter comunicação clara com o parceiro

8. Disposições Finais

• Todo escalonamento deve conter análise prévia
• Chamados sem evidência não devem ser escalados
• Este procedimento deve ser revisado periodicamente