Free URL Shortener API: Code Examples That Run

A free URL shortener API lets you create short links from code instead of clicking around a dashboard. Send a request with a destination URL, get back a short link that redirects to it. This post has runnable examples in curl, JavaScript, Python, and Go against Elido's API, which is available on the free plan, plus the honest part most listicles skip: what "free" actually gates.

If you have never shortened a link at all, how to shorten a URL covers the manual version first. Everything below assumes you want to do it programmatically.

What a Shortener API Does

At its core the API is four operations on a link resource: create, read, update, delete. You create a link by posting a destination URL, and the service returns a short URL that resolves elsewhere.

One thing that trips people up: the API host and the redirect host are different. Elido's API lives at https://api.elido.app/v1, while the short links themselves resolve at a redirect domain like s.elido.me. You talk to the API to manage links; your users only ever hit the redirect domain. Keeping those two separate is what lets the redirect path stay fast while the API does the heavier work.

Authenticate First

Every real request carries a bearer token in the Authorization header. You generate the token in your workspace settings, store it as an environment variable, and never put it in client-side code, because anyone with the token can create links on your account.

export ELIDO_TOKEN="your_token_here"

That is the whole auth model: one header, Authorization: Bearer $ELIDO_TOKEN, on every call. APIs that skip this entirely are convenient for a throwaway script, but there is no account behind the links, so you cannot list, edit, or measure them later.

Create a Short Link

Here is the same create call in four languages. Each one posts a destination URL and prints the short URL from the response.

curl -X POST https://api.elido.app/v1/links \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"destination_url": "https://example.com/spring-sale"}'

The response is JSON:

{
  "id": "lnk_9aF2xK",
  "short_url": "https://s.elido.me/abc123",
  "destination_url": "https://example.com/spring-sale"
}

JavaScript, using the built-in fetch:

const res = await fetch("https://api.elido.app/v1/links", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.ELIDO_TOKEN}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ destination_url: "https://example.com/spring-sale" }),
});
const link = await res.json();
console.log(link.short_url); // https://s.elido.me/abc123

Python, with requests:

import os
import requests

res = requests.post(
    "https://api.elido.app/v1/links",
    headers={"Authorization": f"Bearer {os.environ['ELIDO_TOKEN']}"},
    json={"destination_url": "https://example.com/spring-sale"},
)
print(res.json()["short_url"])  # https://s.elido.me/abc123

Go, with the standard library:

package main

import (
	"bytes"
	"encoding/json"
	"fmt"
	"net/http"
	"os"
)

func main() {
	body, _ := json.Marshal(map[string]string{
		"destination_url": "https://example.com/spring-sale",
	})
	req, _ := http.NewRequest("POST", "https://api.elido.app/v1/links", bytes.NewReader(body))
	req.Header.Set("Authorization", "Bearer "+os.Getenv("ELIDO_TOKEN"))
	req.Header.Set("Content-Type", "application/json")

	res, _ := http.DefaultClient.Do(req)
	defer res.Body.Close()

	var link struct {
		ShortURL string `json:"short_url"`
	}
	json.NewDecoder(res.Body).Decode(&link)
	fmt.Println(link.ShortURL) // https://s.elido.me/abc123
}

Add optional fields to the body as you need them: a slug for a custom back-half, tags for organisation, a domain to pick a branded custom domain, or expires_at for a link that stops working after a date.

What "Free" Actually Gates

This is where the honest comparison lives, because "free API" covers two very different things.

The no-signup, no-auth endpoints, the ones that shorten a URL with a single unauthenticated POST, are genuinely free and genuinely limited. Shared rate limits, no account, no branded domain, no analytics, and no promise the service exists next quarter. Fine for a one-off script, risky for anything you ship.

An authenticated free tier is the more useful kind, and there the gating is predictable. The features most often reserved for paid plans are branded custom domains, high request volume, longer analytics retention, and bulk endpoints. On Elido's free plan the API itself is included, links resolve and are tracked, and the limits are workspace-scoped rather than shared with strangers. For how the paid tools compare on this, Dub vs Bitly covers two of the best-known APIs, and you can start on the free plan to try Elido's.

The rule of thumb: if the link is disposable, a no-auth API is fine. If it carries your brand or you need to measure it, use an authenticated one with a domain you control.

Rate Limits and Idempotency

The number that actually protects you in production is not the rate limit, it is idempotency.

Every mutating request accepts an Idempotency-Key header. Send a unique key with a create call, and if the request times out and you retry with the same key, the server returns the original result instead of creating a second link. This is what makes a retry loop safe.

curl -X POST https://api.elido.app/v1/links \
  -H "Authorization: Bearer $ELIDO_TOKEN" \
  -H "Idempotency-Key: spring-sale-2026-04-01" \
  -H "Content-Type: application/json" \
  -d '{"destination_url": "https://example.com/spring-sale"}'

Idempotency is a property of the HTTP method semantics in RFC 9110, and any API you rely on for automated link creation should support it. The deeper treatment, which status codes to retry and how to pace against the limit, is in rate limits, retries, and idempotency in production.

SDKs or Raw HTTP?

You do not have to hand-roll requests. Elido publishes SDKs generated from its OpenAPI specification for TypeScript, Python, Go, and more, and the API and SDK quickstart walks through installing and calling them.

Use an SDK when you want types, retries, and pagination handled for you. Use raw HTTP, like the examples above, when you want zero dependencies or you are calling from a language without an official client. Both hit the same REST API; the SDK is just a thinner path to it.

Related on the Blog

• URL shortener API and SDK quickstart
• Rate limits, retries, and idempotency in production
• How to shorten a URL: free, branded, and bulk links
• Dub vs Bitly: pricing, free plans, and features