developers · Aug 12, 2025

A Visão de um Desenvolvedor Sobre Como Criar uma Sincronização Bidirecional com a API Quire

Traduzido por IA
· Ver em inglês

Diagrama de arquitetura de sincronização bidirecional do Quire mostrando o fluxo de dados entre o Quire e aplicações externas

Última atualização: 20 de julho de 2026

TL;DR

A sincronização bidirecional entre o Quire e outra aplicação exige um servidor intermediário que receba webhooks de ambos os lados e chame cada API para espelhar a alteração. Arquitetura: Quire ↔ A Sua Aplicação ↔ Outra Aplicação. Quatro passos de implementação: criar o servidor de webhooks, registá-lo no Quire (adicioná-lo como seguidor do projeto), registá-lo na outra aplicação e, por fim, tratar os eventos usando os tipos de atividade da documentação da API Quire. Duas regras de segurança: marcar a origem de cada alteração para evitar loops infinitos e manter um mapeamento entre os IDs das tarefas do Quire e os da outra aplicação. A aplicação de Sincronização Bidirecional com o Calendário Google é um exemplo prático.

Quando os dados vivem em duas aplicações, cada ação acaba por ser feita duas vezes ou perde a sincronização silenciosamente. A sincronização bidirecional resolve esse problema de dupla introdução, fazendo com que o Quire e a outra aplicação troquem atualizações automaticamente através de webhooks. A API Aberta do Quire foi criada exatamente para este padrão.

O custo das ferramentas desligadas entre si está bem documentado. Segundo a investigação da McKinsey sobre a economia social, os trabalhadores do conhecimento passam quase 20% da semana à procura de informação interna em vez de fazerem o seu trabalho real. Uma sincronização fiável elimina automaticamente uma boa parte dessa sobrecarga.

A aplicação de Sincronização Bidirecional com o Calendário Google é o exemplo canónico: as tarefas do Quire e os eventos do Calendário Google mantêm-se alinhados sem qualquer reconciliação manual. Este artigo explica como criar o mesmo padrão com a API de qualquer outra aplicação.

A Sincronização Bidirecional com o Calendário Google está disponível a partir do nível de Assinatura Premium, inclusive. Encontra mais informações na nossa página de preços.

Componentes de uma sincronização bidirecional do Quire

Componente Função
Aplicação Quire Fornece as credenciais de API; registada como seguidora do projeto para receber webhooks
Servidor intermediário (a sua aplicação) Recebe webhooks de ambos os lados; chama cada API para espelhar a alteração
Outra aplicação (por exemplo, o Calendário Google) Origem dos eventos do seu lado; destino das escritas via API
URL de webhook nas definições da aplicação Quire Para onde o Quire envia (POST) os eventos de atividade
Tabela de mapeamento de IDs Associa os IDs das tarefas do Quire aos IDs dos itens da outra aplicação
Marca de origem em cada alteração Impede loops infinitos de atualização

Como funciona o fluxo de sincronização bidirecional?

Pense na sincronização bidirecional como uma conversa entre duas aplicações. Quando atualiza uma tarefa no Quire, esta informa a outra aplicação sobre a alteração. E, quando algo é atualizado nessa outra aplicação, esta informa o Quire. Isto mantém a sua informação consistente em todo o lado.

Diagrama do fluxo de sincronização bidirecional a ilustrar a passagem de eventos entre o Quire, o middleware e a aplicação externa

Quais são os passos de implementação?

Configurar a sua Aplicação Quire é o primeiro passo. Vai precisar de criar uma para obter as credenciais necessárias para aceder ao seu projeto Quire através da API.

Para um guia passo a passo sobre como criar a sua própria aplicação com a API Quire, visite o nosso artigo do blog.

Para implementar uma sincronização bidirecional, vai precisar de desenvolver uma aplicação intermediária (a sua aplicação) que faça de ponte entre o Quire e a aplicação de destino (como o Calendário Google). Pense nela como um tradutor: recebe informação de um lado, processa-a e depois envia os comandos certos para o outro. O fluxo é este: Quire ↔ A Sua Aplicação ↔ Outra Aplicação.

Como o construir passo a passo?

1. Preparar uma aplicação para tratar eventos

Para ativar a sincronização bidirecional, primeiro precisa de configurar o seu próprio servidor para funcionar como camada intermediária. Esta aplicação será responsável por receber pedidos POST de webhook tanto do Quire como da outra aplicação. O seu servidor deve conseguir:

  • Aceitar pedidos HTTP POST recebidos (eventos de webhook) do Quire e da outra aplicação.
  • Analisar as cargas úteis dos eventos e determinar que ações são necessárias.
  • Usar as respetivas APIs para atualizar dados no Quire ou na outra aplicação, conforme necessário.

Pode construir este servidor com a tecnologia que preferir, como Node.js, Python ou Ruby. Nas secções seguintes, vamos usar Node.js para demonstrar um exemplo simples de como receber e tratar eventos de webhook. Certifique-se de que o seu servidor está acessível a partir da internet, para que o Quire e a outra aplicação lhe possam enviar eventos de webhook.

Eis um exemplo simples em Node.js usando o Express:

const express = require('express');
const app = express();
app.use(express.json());

app.listen(3000, () => {
  console.log('Server is running on port 3000');
});

2. Configurar um webhook no Quire para enviar atualizações de tarefas para a sua aplicação.

De seguida, vai precisar de criar uma rota no seu servidor para receber os eventos de webhook do Quire.

app.post('/webhook', (req, res) => {
  console.log('Received webhook event:', req.body);
  // TODO: Handle the event and update Quire or other app via API
  res.status(200).send('Event received');
});

Neste exemplo, a rota do webhook é /webhook, pelo que o URL completo será ${your-host}/webhook.

Copie este URL de webhook e cole-o nas definições da aplicação Quire, para que o Quire saiba para onde enviar as notificações de eventos para a sua aplicação.

Definições da aplicação Quire a mostrar o campo de configuração do URL do webhook

Além disso, vai precisar de registar a sua aplicação Quire como seguidora do projeto que pretende sincronizar. Isto garante que a sua aplicação recebe as notificações das atualizações relevantes.

Para um guia passo a passo sobre como receber notificações através da API Quire, visite o nosso guia.

3. Configurar um webhook na outra aplicação para enviar as suas atualizações para a sua aplicação.

Para sincronizar as atualizações da outra aplicação com o Quire, também vai precisar de criar uma rota no seu servidor para receber os eventos de webhook dessa aplicação. O processo de registo é semelhante ao exemplo mostrado acima para o Quire.

Basta configurar a outra aplicação para enviar as suas notificações de eventos para o ponto de extremidade de webhook da sua aplicação intermediária, e garantir que o seu servidor consegue tratar e processar corretamente estes eventos recebidos.

4. Tratar os eventos recebidos e atualizar os dados no Quire e na outra aplicação através das respetivas APIs.

Assim que a sua aplicação começar a receber eventos de webhook tanto do Quire como da outra aplicação, vai precisar de implementar a lógica para processar esses eventos e sincronizar os dados entre as duas plataformas. Isto envolve normalmente:

  • Analisar as cargas úteis dos eventos para identificar o que mudou (por exemplo, tarefa criada, atualizada ou eliminada). Para mais detalhes sobre a estrutura dos eventos, pode consultar o Documento da API Quire - Eventos de Notificação.
  • Determinar que chamadas de API são necessárias para refletir estas alterações na outra aplicação.
  • Enviar os pedidos de API adequados para o Quire ou para a outra aplicação, para manter os dados sincronizados.
  • Manter um mapeamento entre os IDs das tarefas do Quire e os IDs dos itens da sua aplicação, para garantir que as atualizações ficam corretamente associadas.

Ao tratar cuidadosamente os eventos recebidos e ao atualizar os dados através das APIs, a sua aplicação garante que as alterações ficam refletidas com precisão em ambos os lados, mantendo uma sincronização bidirecional fiável.

Eis um exemplo usando Node.js e axios:

const axios = require('axios');

app.post('/webhook', (req, res) => {
  const { type } = req.body.data;
  // Reference of activity types: 
  // https://github.com/quire-api/quire-api/blob/master/docs/activity_types.md
  switch (type) {
    case 0: //Quire task created
      onQuireTaskCreate();
      break; 
    case 1: //Quire task deleted
      onQuireTaskDelete();
      break;
  }
  res.status(200).send('Event received');
});

// Route for handling events from another app to Quire
app.post('/anotherwebhook', async (req, res) => {
  const { isCreate, id, name, projectId } = req.body;
  if (isCreate) {
    // Create a task in the Quire project
    await axios.post(`https://quire.io/api/task/${projectId}`, { name });
    // Optionally, store the mapping between your app's id and Quire's task id
  } else {
    // Retrieve the corresponding Quire task id using your mapping logic
    const taskOid = getTaskIdByAppEventId(id, projectId);
    // Delete the task from the Quire project
    await axios.delete(`https://quire.io/api/task/${taskOid}`);
  }
  res.status(200).send('Event processed successfully');
});

Este exemplo demonstra como tratar eventos de criação e eliminação vindos de outra aplicação e sincronizá-los com o Quire. Certifique-se de que implementa um tratamento de erros adequado e mantém o mapeamento de IDs para garantir uma sincronização fiável.

Quais são as considerações principais?

Duas regras de segurança cobrem os modos de falha que afetam quase todas as primeiras implementações:

  • Registe a origem de cada alteração. Marque as atualizações desencadeadas pelo seu processo de sincronização e ignore-as quando estas voltarem sob a forma de webhook. Sem isto, o Quire envia a alteração para a outra aplicação, esta dispara um webhook de volta, o seu servidor volta a enviar a alteração, e o ciclo repete-se indefinidamente.
  • Mantenha os formatos de dados consistentes. Um campo que significa uma coisa no Quire (uma descrição em Markdown) pode precisar de conversão explícita antes de chegar sob a forma de descrição de um evento de calendário, nota de incidência em texto simples ou outro formato de destino.

Qual é o próximo passo?

A API Aberta combinada com webhooks transforma o Quire e as suas outras ferramentas numa única fonte de verdade, em vez de duas versões concorrentes. Comece pela sincronização mais pequena possível (um tipo de evento, uma direção) e confirme que o ciclo funciona de ponta a ponta antes de o expandir.

Relacionado: Integre Ferramentas Externas com o Quire através da API Quire — Usando o n8n como Exemplo — um exemplo prático caso prefira começar por uma ferramenta de automação sem código em vez de um servidor personalizado.

Software de gestão de tarefas para dividir grandes objetivos no próximo pequeno passo

Perguntas Frequentes

O que é a sincronização bidirecional entre o Quire e outra aplicação?

Uma ligação nos dois sentidos, em que as atualizações fluem em ambas as direções: as alterações no Quire são enviadas para a outra aplicação, e as alterações aí feitas voltam para o Quire. A aplicação de Sincronização Bidirecional com o Calendário Google é um exemplo prático.

O que preciso para criar uma sincronização bidirecional com a API Quire?

Uma aplicação Quire com credenciais de API, um servidor intermediário acessível a partir da internet para receber webhooks, e lógica para traduzir eventos entre as duas APIs. Qualquer linguagem de backend serve.

Que papel desempenha a aplicação intermediária?

Funciona como tradutora entre o Quire e o outro serviço, recebendo eventos de webhook, decidindo que chamadas de API fazer e mantendo o mapeamento entre os IDs das tarefas do Quire e os IDs dos itens da outra aplicação.

Como evito loops infinitos de sincronização?

Registe a origem de cada alteração e ignore as atualizações desencadeadas pelo seu próprio processo de sincronização. Sem esta proteção, cada atualização vai e volta indefinidamente entre as duas aplicações.

Que plano do Quire é necessário para a Sincronização Bidirecional com o Calendário Google?

Premium, inclusive. Consulte os limites atuais de cada nível na página de preços.

Whiter
Software Engineer