Short link automation: Make, IFTTT, and Elido recipes

Short link automation in Make.com and IFTTT turns long URLs into tracked Elido short links the second a trigger fires, with zero code. Make.com is a full visual workflow builder with routers, filters, and a native Elido app. IFTTT stays flatter, one trigger and one action, integrated through Beta webhook applets that POST to the REST API.

The choice between the two comes down to what you already pay for and what you need to do per run. Make.com is the right pick for a marketer who wants a scheduled scenario that grabs a row from Google Sheets, shortens the URL, stamps it with UTM tags, and pushes the result into Mailchimp campaign content. IFTTT fits the creator who wants a new podcast episode in their RSS feed to auto-shorten and post to Buffer the moment it goes live. This piece covers both flows step by step, then ends with the call on when each platform beats Zapier, n8n, and the raw REST API.

If you are starting from scratch with the API, the API and SDKs quickstart covers the auth model and the create-link payload that every low-code path here calls under the hood.

The Make.com scenario: Schedule, Sheets, Elido, Mailchimp#

A Make scenario is a chain of modules connected by lines, and the simplest valuable short link automation has four of them. We will build a Monday-morning campaign sender that picks the next row off a planning sheet, shortens the destination, and writes the short link into a Mailchimp campaign before it goes out.

Module 1: Schedule trigger. Add the built-in Schedule module. Set it to run every Monday at 09:00 in your team's timezone, and pick "Every day" with a day-of-week filter rather than the cron tab if you want the UI to stay readable. Make will fire this scenario once per week with no input data, which is what we want.

Module 2: Google Sheets - Get a row. Add Google Sheets and pick the action "Get a Range of Values" or "Search Rows" depending on how your sheet is structured. Point at a sheet with columns like campaign_name, destination_url, utm_source, utm_campaign, and status. Filter by status = queued and sort by row order so the oldest queued row comes back first. The output is a single row of values that the next module will reference.

Module 3: Elido - Create a short link. If you have the native Elido app installed, pick "Create a Short Link" as the action. Connect your account once with an API token from /settings/api. Map the fields:

• destination -> the destination_url column from module 2
• domain -> s.elido.me for paid tier or your custom domain
• slug -> leave blank for auto-generation, or map campaign_name with a slugify transform
• utm_source, utm_campaign, utm_medium -> map the matching columns
• tags -> a static value like mailchimp,weekly

If the native app does not expose a field you need, fall back to the HTTP module. Configure it with method POST, URL https://api.elido.app/v1/links, headers Authorization: Bearer {{token}} and Content-Type: application/json, and a body that matches the create-link schema. The Make.com HTTP module reference walks through the configuration in detail.

Module 4: Mailchimp - Update campaign content. Add the Mailchimp module with the action "Edit a Campaign" and pass the short link from module 3 into a merge tag inside your HTML template. Most teams set up a *|SHORTLINK|* merge field that the template renders inside the main CTA button. The campaign goes out an hour later via Mailchimp's normal schedule, with a tracked, branded short link inside.

The whole scenario costs about 4 operations per run on Make's billing meter, which on the Core plan (9 USD a month for 10,000 ops) is essentially free at weekly cadence. Add a fifth module that writes the short link back into the sheet's short_url column and you get a paper trail of what shipped each Monday. Filter the scenario by status = queued so the row is only picked up once, then set the last step to flip status to sent after Mailchimp confirms.

If you outgrow weekly cadence and want this running on every new row instead, swap the Schedule trigger for the Google Sheets "Watch Rows" trigger. That changes the billing model - the scenario polls every 15 minutes by default, so even an empty sheet costs ~96 ops a day. For high-volume runs, the bulk import from Google Sheets path is usually cheaper than module-by-module orchestration.

The IFTTT applets: RSS to Buffer, and click thresholds to SMS#

IFTTT is flatter. One trigger, one action, no routers, no filters past the basic "if-this-then-that" shape. The Elido integration is Beta, which here means you use the Webhooks service rather than a native action card. Two applets show what fits the model.

RSS feed item to a shortened Buffer post. Pick "RSS Feed" as the trigger service and choose "New feed item." Paste your blog or podcast RSS URL. The trigger fires for every new item with ingredients like EntryUrl, EntryTitle, and EntryPublished available downstream.

Add the Webhooks service as the action and choose "Make a web request." Configure:

• URL: https://api.elido.app/v1/links
• Method: POST
• Content Type: application/json
• Additional Headers: Authorization: Bearer YOUR_TOKEN
• Body: {"destination": "{{EntryUrl}}", "utm_source": "rss", "utm_medium": "buffer", "utm_campaign": "{{EntryTitle}}"}

The Webhooks service does not parse JSON responses, which is the practical limitation of the Beta integration. To get the short link into Buffer, you set up a return-trip: the create-link API call sends a webhook back to a second IFTTT Webhooks trigger with the short URL in the payload, and that second applet handles the Buffer step. Two applets to do what Make does in one scenario, but at IFTTT Pro+ pricing (5 USD a month for unlimited applets) it stays cheap. The IFTTT Webhooks service docs cover the request format and the per-user webhook URL you use to fire the return trip.

Click threshold to SMS via Twilio. This one uses the inverse direction - an Elido webhook becomes the trigger. Set up an Elido webhook in the dashboard at /settings/webhooks for the link.click_threshold event, and point it at IFTTT's Webhooks ingestion URL. When a short link crosses, say, 1,000 clicks, Elido fires the webhook, IFTTT's applet receives it as a trigger, and the Twilio service action sends an SMS to your phone with the link slug and current count.

The applet body is just two ingredients - the slug and the click count - because IFTTT Webhooks triggers only expose three named values. For richer payloads or multi-field routing, drop down to Make or up to n8n. The webhook event taxonomy itself is covered in webhooks for link events if you want to see the full list.

IFTTT's strength is the long tail of consumer services nothing else covers - Philips Hue, Google Assistant routines, Life360 location, iOS Shortcuts. If your short link automation has to fire when you arrive home or when your smart doorbell rings, IFTTT is the only platform that wires those triggers without custom code.

Make vs IFTTT vs Zapier vs n8n: how to pick#

Four no-code or low-code platforms can do short link automation today, and the answer changes based on your team's setup and budget. The honest decision tree:

Start with one question: do you write code? If yes, skip all four and use the API and SDKs directly. A 40-line Node.js function on a cron beats any visual scenario for cost, latency, and debuggability once you cross a few hundred links a day. The SDKs cover Go, Python, TypeScript, and Ruby.

If no code, the next question is where your scheduler lives. If you already pay for Zapier and the apps you need are on Zapier, Zapier is the path of least resistance. If you do not, Make.com costs 3-5x less for the same shape of work because its operation-based metering counts each module call rather than each task. IFTTT fits when the trigger or action is a consumer service the others lack.

If you need self-hosting for compliance or cost, n8n is the answer. It runs on your own infrastructure, has no per-task pricing, and ships with an HTTP node that calls the Elido REST API the same way Make's HTTP module does. The trade-off is you operate it yourself, which means a small EC2 instance, a Postgres for the queue, and the time to keep both patched.

The other axis is complexity. Single-trigger, single-action flows belong on IFTTT - it does exactly that, cheaply. Multi-step flows with branching and data transforms belong on Make or Zapier. Anything with conditional retries, complex error handling, or stateful counters belongs in code (or n8n with custom JavaScript nodes). The platforms are not interchangeable; the cost difference for the wrong tool is a 4x bill or a flow that breaks silently on the third edge case.

Agencies running short link automation across many client accounts usually pair Make with the Elido API: Make for the connective tissue, the API for bulk runs that would burn through Make ops. The agencies overview covers the split. Marketers running one or two campaigns ship everything on Make Core under 9 USD a month. See solutions for marketers for the team-of-one playbook.

For UTM hygiene across all of these flows, the UTM templates guide shows how to enforce a consistent source/medium/campaign convention so the analytics layer stays clean no matter which platform shortened the link.

A few practical gotchas#

Make and IFTTT both store your API token in their cloud, so rotate it on any team change and scope it to the workspaces it actually needs. Elido tokens carry per-workspace permissions, and the integrations catalog lists exactly what each connection touches.

Rate limits matter. Make's HTTP module retries on 429 by default with exponential backoff, IFTTT does not - it just fails the applet run and moves on. For RSS-to-shortener applets that fire on a feed with 50 items in a single update window, IFTTT will hit the Elido rate limit and silently drop some. Workarounds: switch to Make, batch through a bulk endpoint, or live with it for low-volume feeds.

Webhook return trips on IFTTT stall if the second applet's trigger URL changes. IFTTT regenerates the per-user URL when you delete and recreate the applet, so treat applet rebuilds as breaking changes.

The pricing page lists the API rate limits per tier. Free and Pro work for Make and IFTTT volumes; Business adds the higher per-second ceiling for schedulers hitting the API every few seconds across multiple scenarios.

Start small. Build one Make scenario with a hard-coded URL on a daily schedule, watch it for a week, then add the Sheets and Mailchimp modules once you trust the trigger. Same with IFTTT: ship one applet, confirm it fires, then chain the return-trip webhook. Both platforms are forgiving in development and unforgiving in production at scale.