Encurtador de URL do IFTTT: applets de Webhooks para links curtos do Elido

Um encurtador de URL do IFTTT no Elido é criado a partir do serviço genérico Webhooks do IFTTT, porque não existe um serviço nativo do Elido no IFTTT. Um applet envia POST /v1/workspaces/{workspace_id}/links com um cabeçalho Authorization: Bearer elido_... e um corpo JSON contendo domain_id e destination_url, e o Elido cria o link. No sentido inverso, um webhook do Elido envia eventos de links para sua URL pessoal do IFTTT Webhooks, onde eles se tornam gatilhos de applets. Os Webhooks exigem o IFTTT Pro. Ler o link criado de volta exige o Pro+.

Essa é a forma honesta da integração. Você pode encurtar links com o IFTTT a partir de qualquer gatilho que ele ofereça e reagir a eventos do ciclo de vida dos links. O que você não pode fazer em um plano barato é pegar o novo link curto e usá-lo no mesmo applet, algo que surpreende a maioria das pessoas no primeiro dia.

Este guia se aprofunda mais no IFTTT do que nossas receitas de Make e IFTTT, que cobrem as duas plataformas lado a lado. Está começando com a API do Elido? O guia rápido da API e dos SDKs explica primeiro as chaves, os workspaces e os domínios.

O que a integração com o IFTTT realmente é

São duas URLs coladas, uma para cada direção, sem um app OAuth entre elas. O serviço Webhooks do IFTTT fornece as duas partes. Sua ação "Make a web request" chama a API do Elido. Seu gatilho "Receive a web request" escuta em uma URL que contém sua chave Maker pessoal, e um endpoint de webhook do Elido pode apontar para ela.

Qual parte você pode usar depende do plano do IFTTT. Isto é o que a página de planos do IFTTT listava quando verifiquei em 21 de setembro de 2026:

As contas Free recebem dois applets e nenhum Webhooks, portanto uma conta gratuita do IFTTT não consegue falar com o Elido. O Pro estava listado a 2,99 USD por mês e o Pro+ a 8,99 USD. Os preços mudam, então confie na página, não neste parágrafo.

Applet 1: encurte links com o IFTTT a partir de um feed RSS

O applet útil mais simples transforma cada nova publicação do blog em um link curto com tags, para que o link já exista quando você for compartilhá-lo. Ele funciona no Pro.

Antes de abrir o IFTTT, reúna três coisas no Elido. Crie uma chave em API keys no dashboard; ela começa com elido_ e é exibida uma única vez. Copie o ID do seu workspace da URL do dashboard. Depois execute GET /v1/workspaces/{workspace_id}/domains uma vez e anote o id e o hostname do domínio em que os links devem ficar.

No IFTTT, escolha RSS Feed como o serviço "If This" com o gatilho New feed item e cole a URL do seu feed. Em "Then That", escolha Webhooks e Make a web request:

URL:                https://api.elido.app/v1/workspaces/1/links
Method:             POST
Content Type:       application/json
Additional Headers: Authorization: Bearer elido_xxxxxxxx
                    Idempotency-Key: {{EntryUrl}}
Body:               {"domain_id": 7,
                     "destination_url": "{{EntryUrl}}",
                     "title": "{{EntryTitle}}",
                     "tags": ["ifttt", "rss"]}

Não informe slug e o Elido gerará um. O cabeçalho Idempotency-Key é a linha que eu nunca deixaria de incluir. Se o IFTTT enviar o mesmo item duas vezes, o Elido reproduz a resposta original por 24 horas em vez de criar um link duplicado, porque a chave é simplesmente a URL da publicação.

A ação é fire-and-forget, porém. A página da ação Make a web request do IFTTT não lista ingredientes de resposta, portanto o novo slug nunca chega à próxima etapa. O link existe no Elido, com a tag rss, e você o copia de lá. Para muita gente, isso está ótimo. Se quiser que o link seja publicado automaticamente em algum lugar, continue lendo.

Applet 2: leia o slug de volta com uma consulta e código de filtro

O Pro+ muda o cenário. A opção Make a web request with JSON response do IFTTT é uma consulta, não uma ação, e devolve dois ingredientes: Status Code e Response Body. O código de filtro pode analisar esse corpo, extrair o slug e escrever a URL curta final na ação seguinte do applet, antes de o IFTTT executar essa ação.

Crie o applet com o mesmo gatilho RSS. Adicione a consulta com a mesma URL, os mesmos cabeçalhos e o mesmo corpo acima. Depois adicione uma ação, por exemplo Notifications, e abra o editor de código de filtro:

const res = MakerWebhooks.makeWebRequestQueryJson;
if (res.StatusCode != "201") {
  IfNotifications.sendNotification.skip("Elido returned " + res.StatusCode);
} else {
  const link = JSON.parse(res.ResponseBody);
  IfNotifications.sendNotification.setMessage(
    "Short link ready: https://go.example.com/" + link.slug,
  );
}

Dois detalhes importam. O Elido responde a uma criação bem-sucedida com 201, não 200, então teste esse valor. E a resposta de criação não tem um campo de URL completa: você recebe id, slug, destination_url, domain_id e timestamps. Você combina o hostname do seu domínio com o slug por conta própria, por isso ele foi anotado antes. Os caminhos dos ingredientes acima são os documentados pela página de consulta do IFTTT; o preenchimento automático do editor mostra os mesmos nomes, então confie nele se algum dia houver uma diferença.

Troque a notificação por um e-mail ou uma linha no Sheets. O padrão continua válido. Qualquer coisa que aceite texto pode receber o link curto.

Applet 3: alertas de links curtos do IFTTT Webhooks a partir de eventos do Elido

A direção inversa começa no Elido. Os webhooks do Elido são disparados por eventos do workspace, e um applet do IFTTT pode escutá-los. São eventos do ciclo de vida: link.created, link.updated, link.deleted, link.expired, link.cap_reached e alguns eventos de workspace e de membros. Não há evento de clique, portanto "me mande uma mensagem a cada clique" não é possível e, sinceramente, em qualquer volume real você não iria querer isso.

O evento útil é link.cap_reached. Defina max_clicks em um link com PATCH /v1/workspaces/{workspace_id}/links/{link_id}, e o Elido emitirá o evento quando o link atingir o limite. Uma verificação em segundo plano é executada a cada poucos minutos. Espere o alerta com algum atraso.

Entre os eventos de links, o formulário de webhooks do dashboard lista apenas created, updated e deleted. Para link.cap_reached e link.expired, registre o endpoint pela API:

curl -X POST https://api.elido.app/v1/workspaces/1/webhooks \
  -H "Authorization: Bearer $ELIDO_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://maker.ifttt.com/trigger/elido_cap/json/with/key/YOUR_MAKER_KEY",
       "events": ["link.cap_reached"],
       "description": "IFTTT cap alert"}'

O nome do evento fica na URL do IFTTT, então um endpoint do Elido corresponde a um evento do IFTTT. Registre um segundo endpoint se também quiser alertas de expiração.

No lado do IFTTT, o formato do payload determina o plano. O gatilho simples Receive a web request expõe apenas value1, value2 e value3. O payload do Elido é um envelope com type, workspace_id, data e timestamp, portanto esses três valores chegam vazios. No Pro, isso ainda funciona como um ping simples: "um link atingiu o limite, vá conferir." O gatilho de payload JSON, observe o /json/ na URL acima, entrega todo o corpo como um único ingrediente. Analise-o no Pro+:

const evt = JSON.parse(MakerWebhooks.jsonEvent.JsonPayload);
IfNotifications.sendNotification.setMessage(
  "Link " + evt.data.slug + " hit its cap at " + evt.data.clicks + " clicks",
);

O Elido faz retry de uma entrega com falha até três vezes, com intervalos de alguns minutos, e o IFTTT responde 200 assim que aceita a solicitação. Falhas de entrega são raras aqui. As falhas do applet acontecem depois, dentro do IFTTT, onde o Elido não consegue enxergá-las.

Quer um alerta de limite no seu próximo link de sorteio? Comece um workspace gratuito do Elido, defina um limite de cliques e configure o applet acima em cerca de dez minutos.

Segurança: chaves, URLs Maker e entregas não assinadas

As duas direções colocam um segredo nas mãos do IFTTT. Elas não merecem o mesmo nível de preocupação.

A chave de API do Elido fica no campo de cabeçalhos do applet. Qualquer pessoa que possa editar esse applet consegue lê-la. Dê a ela uma chave própria, com um nome que indique IFTTT, o papel mais baixo que ainda consiga criar links e uma data de expiração. Revogá-la depois não afetará mais nada. Perder uma chave compartilhada com seus scripts de faturamento seria um problema muito maior.

A URL Maker é o risco maior. O Elido assina cada entrega: um cabeçalho X-Webhook-Signature: v1=<hex> carrega um HMAC-SHA256 sobre o timestamp e o corpo bruto, e um receptor que você controla pode rejeitar falsificações. O IFTTT não tem uma etapa que verifique isso. O applet é disparado por qualquer pessoa que conheça a URL, com assinatura ou sem ela.

Por isso, eu manteria os applets do IFTTT alimentados por eventos do Elido limitados a notificações e logs. Uma solicitação falsificada pode fazer seu telefone vibrar. Nada pior. Se um evento deve alterar algo importante, como pausar uma campanha ou editar um registro de CRM, envie-o para um receptor que verifique as assinaturas. O artigo sobre eventos de webhook mostra a verificação. O n8n auto-hospedado é um lugar para executá-la.

Quando o IFTTT deixa de ser a ferramenta certa

O IFTTT vence nos gatilhos que ninguém mais oferece. Localização, um widget de telefone, um sensor de casa inteligente, um assistente de voz: eles são nativos ali e pouco práticos em qualquer outro lugar. Se a tarefa é "quando eu chegar ao local, crie o link curto desta noite", essa é a ferramenta certa e eu a usaria sem pensar duas vezes.

Ele deixa de se encaixar em quatro situações:

• Qualquer coisa com um loop. Um applet processa um evento de gatilho por vez. Encurtar 300 linhas de uma planilha é tarefa para a importação em massa do Google Sheets, não para 300 execuções de applet.
• Lógica de retry. Quando a API do Elido responde 429 ou 5xx, a ação simplesmente falha e o applet segue em frente. O nó HTTP Request do n8n permite fazer retry com espera e encaminhar os erros para algum lugar visível.
• Tratamento de resposta com orçamento limitado. Ler o slug de volta custa Pro+. Make e Zapier fornecem a resposta em todos os planos pagos, e o passo a passo do Zapier mostra esse caminho de ponta a ponta.
• Ramificações. O código de filtro pode ignorar uma ação, mas um if/else real entre vários serviços pertence ao Make ou ao n8n.

Se você escreve código, pule as ferramentas visuais e chame a API a partir de um pequeno script. O guia sobre limites de taxa e idempotência cobre as regras de retry que qualquer cliente deve seguir, inclusive o IFTTT. Para ver a lista completa de endpoints, consulte a API e os SDKs do Elido.

Leia o artigo principal → guia rápido da API e dos SDKs de encurtamento de URL

Relacionados no blog

• Automação de links curtos com Make e IFTTT - as duas plataformas comparadas de uma só vez.
• Encurtador de URL n8n - o nó HTTP Request com retries e idempotência.
• Automação de encurtador de URL com Zapier - o caminho hospedado com dados de resposta em todos os planos pagos.
• Webhooks para eventos de links - payloads, verificações de assinatura e retries.
• Encurte uma URL no iPhone - o caminho manual quando um applet é exagero.
• Cenários de encurtador de URL do Make.com - fluxos com várias etapas, roteadores, tratadores de erros e custos de créditos.