1. Flowlu
  2. Flowlu Central de ajuda
  3. Guia de desenvolvimento de aplicativos do Marketplace
  4. Perguntas frequentes do Marketplace do Flowlu

Perguntas frequentes do Marketplace do Flowlu


Autenticação e autorização

Quais métodos de autenticação são suportados para apps do Marketplace?

A autenticação identifica o usuário atual da conta e funciona apenas por meio de um token de acesso obtido via OAuth 2.0.

Em nome de quem uma solicitação de API é executada?

Uma solicitação é executada em nome de qualquer usuário cujo token de acesso você passar no cabeçalho (header).

Se seu aplicativo estiver incorporado na interface e usar o JS SDK para fazer solicitações, essas solicitações sempre serão executadas com o token de acesso do usuário atualmente autorizado. Seu aplicativo também pode fazer solicitações com o token de qualquer usuário a partir de seu backend, de acordo com sua própria lógica.

Quando devo usar o OAuth 2.0 em vez de uma chave de API?

Uma chave de API é emitida por conta. Instalar um app público em muitas contas significaria emitir uma nova chave para cada conta, e seu aplicativo teria que rastrear qual chave pertence a qual conta. Além disso, uma chave de API não está vinculada a um usuário, portanto, você não pode autenticar um usuário específico com ela.

O OAuth 2.0 evita tudo isso: os tokens de acesso não estão vinculados a uma conta, mas ao usuário e ao aplicativo.

Posso fazer solicitações de API a partir do código frontend ou as operações sensíveis devem passar pelo backend?

Você pode chamar a API tanto pelo backend quanto pelo frontend, mas pelo frontend, use sempre o token do usuário atual. Os dados da solicitação, incluindo o token, ficam visíveis no navegador por meio das ferramentas de desenvolvedor, portanto, um usuário poderia ler o token de outro usuário e reutilizá-lo livremente.

Quando seu aplicativo usa o JS SDK, o token do usuário atualmente autorizado é sempre usado, e as solicitações de frontend são executadas em nome dele.

Como as permissões do manifesto correspondem ao acesso à API?

O manifesto do aplicativo declara uma lista de escopos (scopes). Cada escopo representa um conjunto de modelos (entidades) dentro de um módulo, além de um nível de acesso a eles. Existem dois níveis de acesso: apenas leitura (read) e acesso total (full). Cada escopo possui um código.

Os escopos controlam:

  • os webhooks que seu aplicativo pode registrar,
  • as configurações do aplicativo vinculadas aos modelos do módulo (usuários, contas de CRM, faturas e assim por diante),
  • as solicitações de API que seu aplicativo está autorizado a fazer contra os modelos do módulo.

Escopos disponíveis:

Scope (Escopo)O que concede
usersO modelo Usuário
user.meO modelo Usuário, restrito ao usuário atualmente autorizado
crmTodos os modelos no módulo CRM
crm.accountscrm.account, crm.company, crm.contact, crm.phone, crm.email
crm.dealscrm.leads, crm.leadsitems 
productsTodos os modelos no módulo de produtos
finTodos os modelos no módulo financeiro (fin)
fin.invoicesfin.invoices , fin.items, fin.itemsrelation
stTodos os modelos no módulo de gestão de estoque (st)
taskTodos os modelos no módulo de tarefas
agileTodos os modelos no módulo agile
calendarTodos os modelos no módulo de calendário
timetrackerTodos os modelos no módulo de controle de tempo
knowledgebaseTodos os modelos no módulo de base de conhecimento
workspaceTodos os modelos no módulo de espaço de trabalho
orgchartTodos os modelos no módulo de estrutura organizacional
customlistsTodos os modelos no módulo de listas personalizadas

Precedência de escopo: Duas regras decidem o que se aplica quando os escopos se sobrepõem:

  • Mesmo escopo, níveis diferentes. Se você declarar um escopo com read e full, apenas o nível mais alto (full) será usado.
  • Geral e específico juntos. Se você declarar tanto um escopo de módulo quanto um mais restrito do mesmo módulo (por exemplo, crm e crm.accounts), apenas o escopo geral (crm) será usado, e o específico será ignorado.

Apps privados e públicos

A moderação é necessária para apps privados?

Não. Apps privados não exigem moderação.

A nova moderação é necessária para cada atualização de um app público?

Alterações na descrição do aplicativo, informações de suporte, banners e logo do aplicativo não exigem nova moderação.

Toda nova versão do aplicativo exige. Revisamos a funcionalidade declarada, se o aplicativo funciona conforme descrito, a segurança e se os escopos solicitados são suficientes e justificados.


Ciclo de vida do aplicativo

Quais ações de ciclo de vida estão disponíveis?

No Console do desenvolvedor, você pode:

  • criar um aplicativo,
  • editar um aplicativo,
  • desativar ou ativar um aplicativo,
  • publicar ou ocultar um aplicativo no catálogo do Marketplace,
  • excluir um aplicativo,
  • criar uma nova versão,
  • editar uma versão,
  • enviar uma versão para moderação,
  • publicar ou ocultar uma versão alterando seu status,
  • instalar uma versão em outra conta através de um link,
  • instalar uma versão na conta atual.

Para um aplicativo já instalado em uma conta, um administrador pode:

  • desinstalá-lo,
  • configurar acesso para funções de usuário e grupos,
  • alterar configurações em nível de aplicativo,
  • alterar configurações em nível de usuário.

O aplicativo instalado é incorporado em várias partes da interface e pode usar o JS SDK.

Quais dados o aplicativo recebe durante a instalação, atualização ou exclusão?

O framework genérico de miniapps não entrega eventos de instalação, atualização ou exclusão para o próprio aplicativo. Tipos de integração específicos, como telefonia ou canais de comunicação, definem seus próprios hooks de ciclo de vida, abordados em seus respectivos guias.

Assim que o aplicativo estiver rodando em uma conta na interface de um usuário, o endpoint do aplicativo no ponto de integração recebe:

  • o protocolo (http/https),
  • o domínio da conta (por exemplo, minhaempresa.flowlu.com),
  • o código do idioma da interface (en/pt/es),
  • o código de incorporação e seu ID exclusivo (do manifesto),
  • o código exclusivo do aplicativo,
  • o número da versão (por exemplo, 1.0.0).

Usando o JS SDK, o aplicativo também pode:

  • obter os tokens de acesso e de atualização do usuário atual,
  • obter configurações do aplicativo,
  • obter configurações do usuário,
  • fazer solicitações de API dentro dos escopos e permissões declarados no manifesto, para o usuário atual,
  • exibir elementos de interface (notificações, alertas, janelas modais, painéis laterais, navegação e assim por diante).

O que acontece com a configuração e os dados de um aplicativo quando ele é excluído?

Quando um aplicativo é desinstalado de uma conta, o Flowlu remove:

  • os valores de configurações do aplicativo e do usuário,
  • arquivos das configurações do aplicativo,
  • webhooks que o aplicativo registrou,
  • configurações de funções de usuário e grupos para o aplicativo.

O aplicativo deixa de estar incorporado na interface.

Quando um aplicativo é excluído do Console do desenvolvedor, tudo o que foi mencionado acima acontece para cada conta onde ele está instalado, uma conta de cada vez. Os tokens de acesso e de atualização do aplicativo para todos os usuários também são excluídos.

O que acontece em uma atualização de aplicativo?

O Flowlu compara os manifestos da versão instalada e da nova versão, e então atualiza os webhooks registrados para corresponder ao novo manifesto: webhooks do manifesto antigo são removidos, e webhooks recém-especificados são registrados.

Configurações do aplicativo, funções de usuário e arquivos são preservados em uma atualização. O aplicativo deixa de ser incorporado em qualquer local removido do novo manifesto e passa a ser incorporado em qualquer local que o novo manifesto adicionar.

Previous Desenvolvimento de um aplicativo de módulo de comunicações