Uso de APIs Senior X (públicas x privadas)

[Lucas Lagasse de Almeida]

# 2 anos, 6 meses atrás

Devido a última mudança nas APIs públicas (uso do clientId nas requisições), nosso time de desenvolvedores da WeDo Tecnologia levantou algumas dúvidas. São elas:

– Uso das APIs por aplicações externas (projetos desenvolvidos por nós): Atualmente usamos as APIs identificadas na documentação como privadas, por exemplo a https://platform.senior.com.br/t/senior.com.br/bridge/1.0/rest/platform/user/queries/getUser. Esse tipo de API é destinada apenas ao uso interno (ecossistema Senior X)?
Para nós desenvolvedores, o uso dessa API é incorreto?
Quais os impactos além de não ser informado sobre possíveis alterações?

– Uso do clientId nas requisições (APIs públicas): Já foi virada a chave?
Ainda conseguimos realizar requisições sem o clientId. Caso a chave não tenha sido virada, qual a previsão?

E, sobre o e-mail disponibilizado para dúvidas (ecossistema@senior.com.br), este tem rejeitado informando que não estamos cadastrados na lista de remetentes autorizados.

Abrimos um ticket #114715, mas este foi finalizado sem solução ou resposta satisfatória. Já que o não funcionamento do ecossistema@senior.com.br é um problema e deveria ser analisado.

• Este tópico foi modificado 2 anos, 6 meses atrás por Lucas Lagasse de Almeida.

[roque.possamai]

# 2 anos, 6 meses atrás

Olá Lucas, tudo bem?

A Senior tem o conhecimento de que, atualmente, a diferenciação das APIs públicas/privadas não está adequada e acaba gerando muitas dúvidas dos desenvolvedores externos.
Justamente por isso estamos pensando em uma forma de facilitar essa identificação e consumo. Uma delas é termos todas as APIs abaixo de um único endpoint, que será o api.senior.com.br. Esperamos em breve ter uma solução adequada e, quando a tivermos, iremos comunicar novamente sobre estas mudanças.

Quanto aos questionamentos:

– Uso das APIs por aplicações externas (projetos desenvolvidos por nós): Atualmente usamos as APIs identificadas na documentação como privadas, por exemplo a https://platform.senior.com.br/t/senior.com.br/bridge/1.0/rest/platform/user/queries/getUser. Esse tipo de API é destinada apenas ao uso interno (ecossistema Senior X)?
Resposta: Recomendamos a utilização da “versão pública” da API sempre que esta estiver disponível. Neste caso, o ideal seria utilizar a versão cujo swagger está exposto neste endereço: https://api.xplatform.com.br/api-portal/pt-br/content/apis-senior. Note que o endpoint da versão pública acaba simplificando bastante:
http://api.senior.com.br/platform/user/getUser

Para nós desenvolvedores, o uso dessa API é incorreto?
Resposta: Não é incorreto, até mesmo porque não temos todas as APIs expostas abaixo da URL api.senior.com.br – pelo menos por enquanto. Este é um dos intuitos do trabalho que comentei no início, de unificar o local das APIs públicas e privadas. Quando isto ocorrer, há uma possibilidade (que ainda é pequena) da Senior rever a abertura da chamada de APIs externas diretamente para o endpoint da plataforma (platform.senior.com.br). Assim sendo, o ideal é que sempre que for possível, o desenvolvedor externo deveria optar pela versão pública da API.

– Uso do clientId nas requisições (APIs públicas): Já foi virada a chave?
Resposta: Ainda não. Isto deverá ocorrer de fato a partir de amanhã (06/05/22). Estamos dando um tempo extra pro pessoal conseguir se ajustar.

– Sobre o e-mail disponibilizado para dúvidas (ecossistema@senior.com.br), este tem rejeitado informando que não estamos cadastrados na lista de remetentes autorizados.
Resposta: Vamos verificar com o nosso time de infra. Assim que tiver um retorno, comento aqui.

Até mais.

[Lucas Lagasse de Almeida]

# 2 anos, 6 meses atrás

Perfeito! Muito obrigado pela atenção e pelo rápido retorno.

[roque.possamai]

# 2 anos, 6 meses atrás

Lucas, o envio de e-mail para ecossistema@senior.com.br está normalizado.

Até mais.

[Luan Tavares]

# 2 anos, 6 meses atrás

Bom dia,

Temos um fluxo no BPM que usa uma fonte de dados que se baseia em uma entidade publica. (https://platform.senior.com.br/t/senior.com.br/bridge/1.0/rest/hcm/payroll/entities/person)

Devido a esta exigência do client_id não estamos mais conseguindo realizar a consulta na fonte de dados, já gerei o client_id e via postman tudo certo, porém onde informo o client_id na fonte de dados do BPM?

[roque.possamai]

# 2 anos, 6 meses atrás

Bom dia Luan, tudo bem?

Fizemos um ajuste na forma de efetuar o repasse do client_id há uns dias, justamente para tratar este caso.

Agora é possível informar o client_id também via query param.
Ex: https://api.senior.com.br/platform/user/getUser?client_id=xhxhxhxhxhxhx

Sugerimos repassar sempre o client_id através do header. Nos casos em que isso não é possível, pode-se utilizar o formato do query param.

[Luan Tavares]

# 2 anos, 6 meses atrás

Bom dia Roque,

Deu certo, muito obrigado.

[Lucas Lagasse de Almeida]

# 2 anos, 3 meses atrás

Boa tarde!
Durante a migração de APIs privadas para públicas notamos uma diferença nos links gerados durante o processo de upload de arquivos na AWS.
A API privada gera um link que ao ser clicado, abre o PDF na própria aba do navegador.
Já pela API pública, o link gerado realiza o download do PDF de forma automática.

Parece ser algo “bobo”, mas essa rotina é muito usada por nossos usuários/clientes. O download automático acaba gerando uma enorme quantidade de arquivos desnecessários no computador.

Existe algum parâmetro na API pública para possibilitar a geração do link, da mesma forma que é gerado na API privada?