Lessons learned from building a minimal, predictable URL preview API

This started as a feature request at the company I work for.

We’re building a platform that connects pet parents with pet care service providers. A real-time, two-way chat system between our users is one of the most active parts of the platform—thousands of messages are sent every day.

One basic expectation is that when someone pastes a link, it expands into a neat preview: title, description, image, favicon; the usual things. Nothing fancy, just the standard link card you see on Facebook Messenger, WhatsApp, and similar apps.

I assumed this would be a straightforward task. After all, there are plenty of URL preview APIs out there, right?

Turns out… not exactly.

---

What I Found When Researching URL Preview APIs

While comparing services, I noticed a few recurring patterns.

1. Hourly limits that didn’t match our usage

Chat traffic comes in waves. For our users (mostly located in the western US) activity is very high from 10AM–2PM MST and fairly quiet after 6PM.

Several APIs priced their usage by the hour or enforced burst limits that didn’t align with real-world usage patterns. Even if the total theoretical monthly usage was reasonable, hitting a short-term cap could break previews during busy periods. That wasn’t something we felt comfortable building on.

2. Features we didn’t need

Many APIs went far beyond basic metadata extraction: screenshots, AI-based parsing, very large JSON responses, and more.

These tools are impressive, but for the simple preview cards we needed, they felt heavier than necessary. The pricing reflected that complexity as well. While some use cases absolutely benefit from these features, ours didn’t.

3. Expensive to get started

The cheapest plans with commercial usage licenses I found typically started at around $25/month. The included quota varied, but the entry price was consistent.

That may not be a big deal for larger companies, but for indie developers and small bootstrapped businesses, it’s another recurring cost added to an already tight budget.

At that point, I started wondering: why does basic metadata extraction need to be this bloated and expensive?

---

Why I Decided to Build My Own Solution

This wasn’t driven by a “I can do it better” mindset. The motivation was much simpler: I needed something simple, reliable, and affordable, and I couldn’t find an existing solution that fit our use case.

It started as an internal need at my company. We were frustrated by hourly limits, unnecessary complexity, and pricing that felt disconnected from what we actually needed. I was looking for something that worked well without overengineering the problem.

Over time, that internal tool evolved into a small standalone service, which eventually became URLPreview.

---

Rules Followed

While building this link previewer, I kept the following rules in mind.

1. Simplicity in the API

One endpoint, simple authentication, and a concise JSON response with only the fields needed to build a standard link card.

2. Simplicity in quotas

No hourly limits. A monthly quota that users can consume whenever they want. Bursts are only temporarily restricted if they threaten the stability of the service.

3. Granular pricing

Smaller users shouldn’t be forced into large tiers. URLPreview starts at $9/month for 50k requests, compared to $25/month with some well-known services for a similar quota.

4. Reliable metadata extraction

Affordable shouldn’t mean unreliable. Broken sites and edge cases are continuously monitored and fixed, often based on user feedback.

5. Equal features across tiers

The only difference between plans is the number of requests. Features whose cost doesn’t scale with usage are available to everyone.

---

Features Intentionally Avoided

1. Screenshots and extras

Not needed for most preview use cases. They require additional infrastructure and storage, which increases operating costs.

2. AI-based extraction

AI-based systems aren’t deterministic. Responses can vary for the same URL. They also require GPU-backed infrastructure, which significantly raises costs.

3. Hourly limits

Hourly quotas penalize bursty traffic patterns like those found in chat applications.

These avoided features aren’t bad. In fact, they’re useful for specific scenarios. They just weren’t necessary for the majority of preview use cases I was targeting, and avoiding them helped keep pricing affordable.

---

Early Launch & User Response

The response was encouraging. Just a few days after casually mentioning the project in a Reddit comment, I got the first paying user. That small signal was enough to validate that the problem resonated with others.

I later launched on Product Hunt and Uneed. Uneed was especially successful: I posted hoping to get the 5 upvotes needed to be listed permanently, and ended up with 69 upvotes and second place for the day.

It drove dozens of signups and confirmed that there was real interest from the developer community. Today, most traffic comes organically from Google, with very little marketing effort.

It’s not generating millions, but it comfortably covers operating costs and provides a return on the time invested.

---

How It Works

The API response is intentionally minimal:

GET https://api.urlpreview.com/v1/preview?url=youtube.com&key=YOUR_KEY

{
"access": "public",
"title": "YouTube",
"description": "Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.",
"image": "https://www.youtube.com/img/desktop/yt_1200.png",
"icon": "https://www.youtube.com/s/desktop/31c2c151/img/favicon.ico",
"url": "https://youtube.com"
}

This covers what most apps actually need for link cards.

Lessons Learned

Simplicity wins – Most use cases don’t need screenshots or AI; keeping things minimal makes the API easier to maintain and more affordable.

Predictable pricing matters – Burst limits frustrate developers; In my opinion, a flat monthly quota works better for real-world usage.

Free tiers help adoption – Allowing personal projects and testing without friction encourages experimentation and feedback.

Focus on reliability – Even affordable services must be dependable; monitoring and alerting are worth the effort.

Small gaps can become opportunities – Sometimes building a small, focused tool to solve a real pain can create value for others.

Why I’m Sharing This

Many developers eventually need link previews whether it’s for chat apps, dashboards, bookmarking tools, browser extensions, or automations.

I wanted to share the lessons I learned while building a small, minimal URL preview API, in case others face similar challenges with existing services, pricing models, or API limitations.

If you’ve tackled this problem differently, I’d love to hear your approach or any feedback on my implementation. Sharing experiences and ideas like this is a great way for all of us to learn and discover better solutions.