The problem with rolling your own URL shortener
Almost every project I’ve worked on eventually needed short URLs.
Marketing links. SMS campaigns. QR codes. Email tracking. Temporary access links.
And every time, I found myself rebuilding the same service yet again.
So I decided to turn that problem into a reusable API.
The problem with rolling your own URL shortener
A basic short URL service is easy.
A production-ready one is not.
At scale, you start running into:
- Collision-safe shortcode generation
- High write volumes
- Fast redirects
- Analytics and tracking
- Expiry rules
- Abuse prevention
- API authentication and rate limits
Most teams don’t want to own that complexity — they just want a clean API.
Enter myapi.rest
myapi.rest is a unified API platform that bundles common developer utilities behind one REST interface.
One of the core services is a URL Shortener API built for scale.
Key features:
- Massive shortcode space (57+ trillion possible codes)
- Fast redirects
- Optional expiry
- Per-link analytics
- API key–based auth
- JSON-first responses
Creating a short URL via API
Here’s what creating a short URL looks like.
POST:
curl --location 'https://api.myapi.rest/api/shorturl/generate' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer <API_KEY>' \
--data '{
"long_url": "https://jenturner.studio",
"expires_at": "2026-11-15T10:01:57.102Z"
}'
Response:
{
"shorturl": "https://grc.pw/Z7hye8b"
}
Click events can also be pushed to your own systems via webhooks, making it easy to stream short-URL activity into your analytics pipeline, CRM, or internal tooling in near real time.
Click Event Webhook Payload:
{
"occurredAt": "2025-12-01 06:11:08",
"id": "5346718",
"code": "KJPwJbu",
"domain": "grc.pw",
"ip": "105.245.231.156",
"user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36",
"referer": "",
"accept_language": "en-ZA,en-GB;q=0.9,en-US;q=0.8,en;q=0.7"
}
That’s it.
No SDK required. No setup beyond an API key.
Built for real-world usage
This isn’t a toy service.
The API is designed to handle:
- High-volume creation (think campaigns and batch jobs)
- Heavy redirect traffic
- Programmatic usage from backend systems
- Analytics pipelines and dashboards
It’s the same kind of infrastructure you’d normally have to build, harden, and maintain yourself.
Why I built it
After years of backend and SaaS work, I realised most teams don’t need custom versions of these utilities — they need reliable, minimal, well-designed APIs.
So instead of rebuilding short URL logic for the tenth time, I turned it into a service others can use.
What’s next
The URL shortener is just one part of the platform. Other APIs include QR codes, barcodes, image hosting, tokens, and chat-flow logic — all behind the same REST interface, with more being added regularly. Suggestions are always welcome.
If you’re interested, feedback from other devs is always welcome.
Top comments (0)