DEV Community: Doushabao

SSL Certificates Are Getting Shorter — Here's How to Monitor Before They Bite

Doushabao — Tue, 08 Sep 2026 02:18:07 +0000

SSL Certificates Are Getting Shorter — Here's How to Monitor Before They Bite

Last month, a friend's SaaS went down for 47 minutes because an SSL certificate expired. Not because Let's Encrypt failed — because someone moved a nginx config during a deployment and the renewal cron silently broke.

The worst part? It was completely avoidable. A simple daily check would have caught it 30 days earlier.

Here's the thing: certificate lifetimes are about to get a lot shorter, and the problem is about to get 8x worse.

The 47-Day Reality

The CA/Browser Forum approved ballot SC-081, and here's the timeline:

Date	Max Certificate Validity
Today	398 days
March 15, 2026	200 days
March 15, 2027	100 days
March 15, 2029	47 days

That last number is the one that should keep you up at night. At 47-day validity, you're renewing certificates roughly every 31 days (at the recommended 2/3 mark). For a fleet of 100 domains, that's potentially 3 renewals per day, seven days a week.

Manual renewal is dead. And automated renewal that fails silently? That's the new biggest risk.

Why "It Works in My Browser" Isn't Enough

I've seen this pattern too many times:

Developer deploys a new service with a valid certificate
Auto-renewal is configured and "works"
Six months later, someone changes a DNS record or moves infrastructure
The renewal challenge fails silently
Certificate expires at 2 AM on a Saturday
Production goes down

The gap between "the certificate was issued" and "the certificate is actually being served" is where outages live. Your browser might show a valid certificate because of CDN caching, while the origin server has already expired.

Building a Practical Monitor

Here's a minimal SSL certificate monitor in Python that checks the live certificate — not a cached value, not a DNS lookup, but the actual certificate your users see:

import ssl
import socket
import datetime
from dataclasses import dataclass

@dataclass
class CertInfo:
    hostname: str
    expires_at: datetime
    days_remaining: int
    issuer: str
    error: str = None

def check_cert(hostname: str, port: int = 443, timeout: int = 10) -> CertInfo:
    context = ssl.create_default_context()
    try:
        with socket.create_connection((hostname, port), timeout=timeout) as sock:
            with context.wrap_socket(sock, server_hostname=hostname) as ssock:
                cert = ssock.getpeercert()
    except Exception as e:
        return CertInfo(
            hostname=hostname,
            expires_at=datetime.now(datetime.timezone.utc),
            days_remaining=-1,
            issuer="",
            error=str(e),
        )

    not_after = datetime.strptime(cert["notAfter"], "%b %d %H:%M:%S %Y %Z")
    not_after = not_after.replace(tzinfo=datetime.timezone.utc)
    days_remaining = (not_after - datetime.now(datetime.timezone.utc)).days
    issuer = dict(x[0] for x in cert.get("issuer", [])).get("organizationName", "")

    return CertInfo(
        hostname=hostname,
        expires_at=not_after,
        days_remaining=days_remaining,
        issuer=issuer,
    )

Key details:

ssl.create_default_context() enables hostname verification by default
We check the live certificate from outside your network
Timezone-aware datetime prevents midnight comparison bugs

Multi-Domain Monitoring with Thresholds

Different domains need different urgency levels. Your payment page needs earlier alerts than your internal wiki:

DOMAINS = [
    {"hostname": "api.yoursite.com", "warn_days": 30, "critical_days": 7},
    {"hostname": "dashboard.yoursite.com", "warn_days": 21, "critical_days": 5},
    {"hostname": "internal.corp.com", "port": 8443, "warn_days": 14, "critical_days": 3},
]

def assess(cert, warn_days, critical_days):
    if cert.error:
        return "ERROR"
    if cert.days_remaining <= critical_days:
        return "CRITICAL"
    if cert.days_remaining <= warn_days:
        return "WARN"
    return "OK"

Alert Only on Deviation

One mistake I see often: teams send "all certs OK" messages every day. Within a week, on-call engineers start ignoring them.

Alert on problems, not on health. If everything is fine, don't send anything. When something breaks the threshold, that's when people need to know.

def send_alert(issues):
    if not issues:
        return  # No noise when everything is fine

    lines = []
    for cert, level in issues:
        emoji = {"CRITICAL": "🔴", "WARN": "🟡", "ERROR": "⚪"}[level]
        lines.append(f"{emoji} {cert.hostname} — expires in {cert.days_remaining} days")

    # Send to Slack, email, PagerDuty, etc.
    print("\n".join(lines))

Scheduling: systemd vs Cron

For anything beyond a quick script, systemd timers beat cron:

# /etc/systemd/system/ssl-check.timer
[Unit]
Description=Daily SSL certificate check

[Timer]
OnCalendar=*-*-* 06:30:00
Persistent=true
RandomizedDelaySec=10m

[Install]
WantedBy=timers.target

The Persistent=true flag matters: if your server was down at 6:30 AM, systemd runs the check as soon as it comes back up instead of silently skipping it.

The "Right-Click" Approach

If you don't want to build and maintain a monitor from scratch, there are tools that handle this for you. One that I've found useful is a free SSL certificate checker that:

Checks multiple domains at once
Shows days remaining with color-coded status
Exports results as JSON (great for automation)
Supports custom port checks (not just 443)

The key is that it checks the live certificate — the one your users actually see — not just the DNS record or CA database entry.

What I Learned

After dealing with three certificate-related outages in the past year, here's what I'd tell myself on day one:

Check the live cert, not the cached one — CDN caching and browser caching can hide expired origin certificates
Separate warn and critical thresholds — a single global threshold creates alert fatigue
Log every run, alert only on deviation — you need history for postmortems, but daily "OK" messages train people to ignore alerts
Automate renewal AND verify it worked — automation that fails silently is worse than no automation
Track certificate changes — a cert that suddenly changes issuer or expiry date without a deployment is suspicious

The Bottom Line

SSL certificate monitoring is one of those tiny automations with outsized impact. A 50-line script can prevent a very public outage. And with certificate lifetimes dropping to 47 days by 2029, the teams that survive will be the ones treating renewal as a deployment pipeline, not a calendar reminder.

If you're still manually checking certificates or relying solely on auto-renewal without verification, now is the time to add a monitor. Your future 2 AM self will thank you.

What's your approach to SSL certificate monitoring? Do you have a favorite tool or workflow? Drop a comment below — I'm always curious how other teams handle this.

I Built a 30-Line Earthquake Monitor in Python — Here's How

Doushabao — Sat, 05 Sep 2026 13:07:26 +0000

Two days ago, a magnitude 6.3 earthquake struck 84 miles south of Nikolski, Alaska. I found out about it 40 minutes later scrolling through Twitter. Forty minutes.

That bugged me. There's free, real-time seismic data sitting right there — why wasn't I checking it myself? So I spent an evening building a 30-line Python script that now runs in my terminal every morning. Here's exactly how it works.

The Data Source

The USGS publishes earthquake data as a free GeoJSON feed. No API key, no registration, no rate limit headaches. You get everything from M1.0 microquakes to M8.0+ megathrust events, updated within minutes of occurrence.

The feed gives you:

Magnitude and magnitude type (ml, mb, mw)
Exact coordinates and depth
Timestamp (UTC)
Location description (human-readable)
Felt reports (how many people reported feeling it)
Alert level (PAGER: green/yellow/orange/red)

The Script

Install one dependency:

pip install rich

Then save this as quake_check.py:

import requests
from rich.console import Console
from rich.table import Table
from rich.text import Text
from datetime import datetime

console = Console()

def get_earthquakes(min_mag=4.5, limit=20):
    """Fetch recent earthquakes from the USGS feed."""
    url = "https://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/significant_week.geojson"
    resp = requests.get(url, timeout=10)
    resp.raise_for_status()
    return resp.json()["features"][:limit]

def mag_color(mag):
    if mag >= 6.0: return "bold red"
    if mag >= 5.0: return "red"
    if mag >= 4.0: return "yellow"
    return "green"

def show_quakes(features):
    table = Table(title="Recent Significant Earthquakes", show_lines=True)
    table.add_column("Mag", justify="center", style="bold")
    table.add_column("Location")
    table.add_column("Depth")
    table.add_column("Time (UTC)")
    table.add_column("Reports")

    for eq in features:
        p = eq["properties"]
        coords = eq["geometry"]["coordinates"]
        t = datetime.utcfromtimestamp(p["time"] / 1000).strftime("%Y-%m-%d %H:%M")
        style = mag_color(p["mag"])
        table.add_row(
            Text(f"{p['mag']:.1f}", style=style),
            p["place"] or "Unknown",
            f"{coords[2]:.0f} km",
            t,
            str(p.get("felt") or "-"),
        )
    console.print(table)

if __name__ == "__main__":
    quakes = get_earthquakes()
    show_quakes(quakes)
    console.print(f"\n[dim]Source: USGS Earthquake Hazards Program[/dim]")

Run it:

python3 quake_check.py

That's it. You'll see something like this in your terminal:

         Recent Significant Earthquakes
┌───────┬──────────────────────────────────┬────────┬──────────────────┬─────────┐
│  Mag  │ Location                         │ Depth  │ Time (UTC)       │ Reports │
├───────┼──────────────────────────────────┼────────┼──────────────────┼─────────┤
│  6.3  │ 84 km SSW of Nikolski, Alaska    │ 35 km  │ 2026-09-03 14:22 │    47   │
│  5.4  │ 21 km WNW of Jiangyou, China     │ 10 km  │ 2026-09-02 08:15 │   112   │
│  5.1  │ 69 km E of Antofagasta, Argentina│ 124 km │ 2026-09-01 22:07 │     -   │
│  5.5  │ 168 km ESE of Kuril'sk, Russia   │ 55 km  │ 2026-08-31 19:44 │     -   │
│  5.0  │ Pagar Alam, Indonesia             │ 22 km  │ 2026-08-31 16:33 │     8   │
└───────┴──────────────────────────────────┴────────┴──────────────────┴─────────┘

Making It More Useful

The script above shows only "significant" events. Here's how to filter by your own criteria:

Filter by magnitude

Change the feed URL to get all M2.5+ earthquakes from the past week:

url = "https://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/2.5_week.geojson"

Different feed options:

Feed	What you get
`significant_week`	Only significant events
`4.5_week`	M4.5+ past 7 days
`2.5_week`	M2.5+ past 7 days
`all_hour`	Everything in the last hour

Filter by distance from your city

from math import radians, sin, cos, sqrt, atan2

def haversine(lat1, lon1, lat2, lon2):
    """Distance in km between two coordinates."""
    R = 6371
    dlat = radians(lat2 - lat1)
    dlon = radians(lon2 - lon1)
    a = sin(dlat/2)**2 + cos(radians(lat1)) * cos(radians(lat2)) * sin(dlon/2)**2
    return R * 2 * atan2(sqrt(a), sqrt(1-a))

def near_me(features, my_lat, my_lon, max_km=500):
    """Only earthquakes within max_km of my location."""
    return [
        eq for eq in features
        if haversine(my_lat, my_lon, eq["geometry"]["coordinates"][1],
                     eq["geometry"]["coordinates"][0]) <= max_km
    ]

Call it with your coordinates:

# San Francisco: 37.77, -122.42
# Tokyo: 35.68, 139.69
# Mexico City: 19.43, -99.13
nearby = near_me(quakes, my_lat=37.77, my_lon=-122.42, max_km=300)

Add desktop notifications (optional)

import subprocess

def notify(title, message):
    """Send a desktop notification (Linux/macOS)."""
    subprocess.run(["notify-send", title, message])

Hook it into the main loop:

for eq in quakes:
    if eq["properties"]["mag"] >= 5.0:
        p = eq["properties"]
        notify(f"M{p['mag']} Earthquake!", p["place"])

What I Actually Learned

A few things surprised me building this:

There are ~250 earthquakes per day worldwide. Most are tiny and nobody feels them. But M2.5+? Still about 60-70 per day. The earth is constantly moving.
Depth matters more than you'd think. A M5.0 at 10 km depth causes way more damage than a M6.0 at 400 km depth. The script shows depth for a reason.
The USGS feed is fast. Events typically appear within 5-10 minutes of occurrence. That's fast enough for personal monitoring, though not for early warning systems (those need seismometer networks).
Alaska accounts for ~50% of US earthquakes. Looking at the data, it's kind of wild how much seismic activity happens up there versus the contiguous US.

Auto-Running It

Want it to check every hour? Add a cron job:

# Check every hour, save to file
0 * * * * /usr/bin/python3 /path/to/quake_check.py >> /tmp/quakes.log 2>&1

Or run it as a background loop:

import time

while True:
    quakes = get_earthquakes()
    show_quakes(quakes)
    console.print(f"\n[dim]Checking again in 30 minutes...[/dim]")
    time.sleep(1800)

Wrapping Up

Total lines of code: 30. Total cost: $0. Total setup time: 5 minutes.

This is one of those projects where the effort-to-value ratio is absurdly good. You get real-time earthquake monitoring for any location on Earth, with no API keys and no dependencies beyond rich.

If you're building something that needs earthquake data as part of a larger project — weather dashboards, disaster preparedness tools, IoT safety systems — I've been using QuotaLink which bundles several free data APIs (earthquake, weather, air quality) into a single endpoint. Could save you some glue code.

Resources:

USGS Earthquake Feeds — All available GeoJSON feeds
USGS Earthquake API Docs — For custom queries beyond the feeds
Rich Library — Beautiful terminal output in Python

10 Free APIs Every Developer Should Bookmark (No API Key Needed)

Doushabao — Fri, 04 Sep 2026 02:10:58 +0000

10 Free APIs Every Developer Should Bookmark (No API Key Needed)

Last week I was building a small dashboard and needed a QR code, some country data, and a way to generate realistic test users. I spent way too long searching for APIs that don't require signup, don't have hidden rate limits, and actually return useful data.

Here are 10 free APIs that passed my "actually works" test. No API key required for most of them.

1. QR Code Generation

Everyone needs QR codes at some point — for links, Wi-Fi configs, product packaging. A good QR code API returns a PNG image directly from a GET request with no watermarks and no signup.

What to look for: custom size options, error correction levels, and support for different data types (URL, text, Wi-Fi config).

I use this for generating share links in my projects. The API returns a scannable image in under 100ms.

2. IP Geolocation

You have a visitor's IP and want to know where they're from. A solid IP lookup API returns city, country, ISP, coordinates, and timezone in one call.

Typical response includes: country, region, city, latitude, longitude, timezone, ISP, and organization.

Useful for analytics dashboards, geo-based feature flags, or just understanding your user base.

3. Country Information

Need to populate a country dropdown? Show flags? Get currency codes? A good country info API has detailed data for every country including population, languages, currencies, timezones, and flag emojis.

Way better than hardcoding a JSON file that goes stale every time a country changes its currency.

4. Random User Generator

Building a UI that needs realistic placeholder data? This generates fake users with names, emails, addresses, phone numbers, and even profile pictures.

Each call returns a different set of realistic user profiles. Great for prototyping dashboards, testing search filters, or filling demo databases.

5. Name Intelligence

Ever wondered what a name means, how common it is, or where it originates? A name analysis API returns cultural origin, gender probability, meaning, and popularity data.

I used this in an onboarding flow to personalize welcome messages. Small touch, big impact on UX.

6. Weather Data

The most practical free API out there. Two calls: geocode a city name to coordinates, then get current weather. Temperature, humidity, wind speed, conditions — all free and no API key needed.

Here's the pattern in Python:

import requests

# Most weather APIs follow a two-step pattern:
# 1. Geocode city name to lat/lon coordinates
# 2. Fetch weather using those coordinates

# Step 1: City name to coordinates
geo = requests.get("https://api.example.com/v1/geocode",
    params={"name": "Tokyo", "count": 1}).json()

lat, lon = geo["results"][0]["latitude"], geo["results"][0]["longitude"]

# Step 2: Coordinates to weather
weather = requests.get("https://api.example.com/v1/forecast",
    params={"latitude": lat, "longitude": lon, "current_weather": True}).json()

print(f"Tokyo: {weather['current_weather']['temperature']}°C")

The best part? This particular API is completely free for non-commercial use — no API key, no rate limits, no signup required.

7. On This Day

Historical events that happened on today's date. Good for "today in history" features, newsletter content, or just satisfying curiosity.

Returns categorized events (events, births, deaths) with year and description. I've seen this used in daily digest emails and Slack bots.

8. Trivia Questions

Need a quiz feature? Random trivia questions with multiple choice answers, categorized by difficulty and topic.

Categories typically include science, history, geography, entertainment, and more. Each question comes with the correct answer and explanations.

Perfect for gamification features or educational apps.

9. Word Tools

Need to check if a word is a palindrome? Find anagrams? Get synonyms? A word operations API handles common text processing tasks.

Returns anagrams, character frequency, word length, and palindrome checks. Useful for word game apps or text analysis tools.

10. Space and Science Facts

Random space facts, NASA's Astronomy Picture of the Day, and ISS location data. Perfect for adding a "cool science fact" widget to any app.

Returns a random space fact with source attribution. The APOD endpoint gives you daily space images for free.

How I Use These Together

Here's a real pattern from a dashboard I'm building:

def get_dashboard_data(user_ip):
    # Where is the user?
    location = get_ip_location(user_ip)

    # What's the weather there?
    weather = get_weather(location["lat"], location["lon"])

    # Today in history
    history = get_on_this_day()

    # A random fun fact
    fact = get_space_fact()

    return {
        "city": location["city"],
        "weather": weather,
        "history": history["events"][:3],
        "fact": fact["fact"]
    }

All free, all from aggregators that bundle multiple APIs under one roof, no API keys to manage across different providers.

The Catch (There's Always One)

Free APIs work great for:

Side projects and prototypes
Internal tools
Learning and education
Small-scale production

When you might need paid:

SLA guarantees (99.9% uptime)
Enterprise support
Very high rate limits (over 10K requests per minute)
Compliance requirements

For 90% of what indie hackers build, these free tiers are more than enough.

Wrapping Up

I've been using these APIs for a few weeks now and they've saved me from spinning up my own microservices for simple tasks. The QR code and IP lookup alone have saved me hours of development time.

If you're building something and need any of these capabilities, check out API aggregator platforms like QuotaLink (www.quotalink.cn) — they bundle 22+ free APIs under one roof with generous rate limits.

What free APIs do you rely on? Drop them in the comments — I'm always looking for more to add to my toolkit.

5 Free APIs That Saved My Side Project From Surprise Bills

Doushabao — Thu, 03 Sep 2026 13:04:40 +0000

5 Free APIs That Saved My Side Project From Surprise Bills

I launched a side project last month. Nothing fancy — a small web app that pulled weather data, checked air quality, and looked up location info. Classic "weekend project" stuff.

Then I got the bill.

I'd signed up for three paid API services without thinking about it. $47/month for what amounts to a hobby project. I'm not a funded startup. That's real money for a side project.

So I went on a hunt for free alternatives. Here's what I found — and why you probably don't need to pay for APIs either.

The Problem With Paid APIs

Most developers reach for the obvious paid service first. Stripe for payments, Twilio for SMS, OpenWeather for weather. They're great products. But here's the thing:

For a side project, you're paying for reliability and scale you don't need yet.

If you have 50 users (or even 500), you don't need enterprise-grade API uptime. You need something that works, is free, and won't send you a surprise invoice at 2am.

API #1: Weather Data (No API Key Needed)

I was using a paid weather API at $12/month. Then I found Open-Meteo — completely free, no API key required, and the response format is actually cleaner than the paid alternatives.

The catch? It only works for weather. No air quality, no historical data, no fancy ML predictions. But for "what's the weather in Tokyo right now?" — it's perfect.

I pulled the weather widget off my app and replaced it with a direct fetch. Two hours of work, $144/year saved.

API #2: Air Quality (Also Free)

This one surprised me. The EPA provides free air quality data through their AirNow API. No key needed for basic queries. You can get AQI readings for any US city.

If you need global data, there are a few options. I ended up using a bundled service that aggregates multiple sources, but the point is: air quality data is public information. You shouldn't be paying $20/month for it.

API #3: IP Geolocation (Zero Cost)

I was paying $8/month for a geolocation service. Turns out, there are several free alternatives that give you city, country, timezone, and even approximate coordinates from an IP address.

The best part? Most of them have generous rate limits — 1,000+ requests per minute for free. Way more than a side project needs.

API #4: Translation (Built Into Your Stack)

If you're paying for a translation API for a small app, stop. Google Translate has a free tier. DeepL has a free tier. And if you're building with Python, there are libraries that wrap these services with no additional cost.

I replaced a $15/month translation API with a simple function that uses a free alternative. Same quality, zero cost.

API #5: QR Code Generation (Why Was I Paying For This?)

I was paying $5/month for a QR code API. Let me save you the trouble: QR code generation is a solved problem. There are free libraries in every language that generate QR codes locally. No API call needed. No rate limits. No monthly fee.

I spent 20 minutes integrating a Python library and never looked back.

The Pattern I Noticed

Every paid API I was using fell into one of two categories:

Data that's publicly available — weather, air quality, geolocation. These are public datasets. Someone already aggregated them for free.
Commodity operations — translation, QR codes, text processing. These are solved problems with free implementations.

The only APIs worth paying for are ones that provide unique data (real-time financial data, proprietary analytics) or infrastructure (payment processing, email delivery that needs deliverability guarantees).

How I Organized My Free APIs

Here's what my API stack looks like now:

Weather: Open-Meteo (free, no key)
Air Quality: EPA AirNow + a bundled aggregator
Geolocation: Free IP lookup service
Translation: Free tier from a major provider
QR Codes: Local generation, no API needed

Total cost: $0/month. Down from $47.

The Real Lesson

The lesson isn't "never pay for APIs." It's "don't pay for APIs you can get for free."

Before signing up for any paid service, ask yourself:

Is this data publicly available?
Is there a free alternative with adequate rate limits?
Am I paying for scale I don't need yet?
Can I generate this locally instead of calling an API?

For side projects and MVPs, the answer is usually "yes, there's a free option." Save the paid APIs for when you actually need them — when you have users, revenue, and real infrastructure requirements.

What I'd Do Differently

If I started my side project over today, I'd build my API layer first. Pick the free services, understand their limits, and design around them. Then, if I ever need to upgrade, I know exactly what I'm paying for and why.

I've been using a tool called QuotaLink that aggregates several of these APIs in one place — weather, air quality, translation, geolocation. Worth checking out if you want a single endpoint instead of juggling five different services.

What free APIs have you discovered that others might not know about? I'm always looking for more.

I Built a Zero-Cost Recipe-to-World Tool With 3 Free APIs — Here's the Full Walkthrough

Doushabao — Wed, 02 Sep 2026 13:03:56 +0000

Last week I wanted to build something small but useful. A command-line tool that takes a recipe name, finds the full recipe with ingredients and instructions, translates it to any language, and converts the listed prices to my local currency.

Three free APIs. No API keys. No credit card. The whole thing runs in about 2 seconds.

Here's exactly how I built it, what broke, and what I'd do differently.

The Three APIs

I picked three services that are completely free and require zero authentication:

TheMealDB — a recipe database with 300+ meals, ingredients, and instructions
LibreTranslate — open-source translation (hosted instances available, or self-host)
ExchangeRate-API — free currency conversion rates

The idea: chain them together so you can type recipe "chicken curry" and get the full recipe in Japanese, with ingredient prices converted to Yen.

Step 1: Fetching a Recipe

TheMealDB is refreshingly simple. You search by name and get back a JSON object with the meal name, category, instructions, and a list of up to 20 ingredients with measurements.

In JavaScript, it's just a fetch call:

async function getRecipe(name) {
  const response = await fetch(
    `https://www.themealdb.com/api/json/v1/1/search.php?s=${encodeURIComponent(name)}`
  );
  const data = await response.json();

  if (!data.meals || data.meals.length === 0) {
    throw new Error(`No recipe found for "${name}"`);
  }

  const meal = data.meals[0];
  const ingredients = [];

  for (let i = 1; i <= 20; i++) {
    const ingredient = meal[`strIngredient${i}`];
    const measure = meal[`strMeasure${i}`];
    if (ingredient && ingredient.trim()) {
      ingredients.push({ name: ingredient.trim(), amount: measure?.trim() || '' });
    }
  }

  return {
    name: meal.strMeal,
    category: meal.strCategory,
    area: meal.strArea,
    instructions: meal.strInstructions,
    ingredients
  };
}

Pitfall #1: TheMealDB uses numbered keys (strIngredient1, strIngredient2, ...) instead of an array. This is common with older APIs — always inspect the full response structure before assuming a clean format.

Step 2: Translating the Recipe

For translation, I used LibreTranslate. There are several free hosted instances, or you can run your own.

The API is straightforward — send text and a target language code:

async function translateText(text, targetLang) {
  // Split long text into chunks (LibreTranslate has character limits)
  const chunks = splitIntoChunks(text, 500);
  const translated = [];

  for (const chunk of chunks) {
    const response = await fetch('https://libretranslate.com/translate', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        q: chunk,
        source: 'en',
        target: targetLang
      })
    });

    if (!response.ok) {
      throw new Error(`Translation failed: ${response.status}`);
    }

    const result = await response.json();
    translated.push(result.translatedText);
  }

  return translated.join(' ');
}

function splitIntoChunks(text, maxLen) {
  const chunks = [];
  let remaining = text;
  while (remaining.length > 0) {
    if (remaining.length <= maxLen) {
      chunks.push(remaining);
      break;
    }
    // Try to split at a sentence boundary
    let splitPoint = remaining.lastIndexOf('. ', maxLen);
    if (splitPoint === -1 || splitPoint < maxLen * 0.5) {
      splitPoint = remaining.lastIndexOf(' ', maxLen);
    }
    if (splitPoint === -1) splitPoint = maxLen;
    chunks.push(remaining.slice(0, splitPoint + 1));
    remaining = remaining.slice(splitPoint + 1);
  }
  return chunks;
}

Pitfall #2: Free translation APIs have character limits per request. A full recipe can be 2,000+ characters. If you don't chunk the text, you'll get 400 errors with no explanation.

Pitfall #3: Some LibreTranslate instances have rate limits of 1-5 requests per minute. If you're translating each ingredient separately, you'll hit the limit fast. Batch what you can.

Step 3: Currency Conversion

ExchangeRate-API gives you the latest rates with a simple GET request:

async function convertCurrency(amount, fromCurrency, toCurrency) {
  const response = await fetch(
    `https://open.er-api.com/v6/latest/${fromCurrency}`
  );
  const data = await response.json();

  if (data.result !== 'success') {
    throw new Error('Currency conversion failed');
  }

  const rate = data.rates[toCurrency];
  if (!rate) {
    throw new Error(`Unknown currency: ${toCurrency}`);
  }

  return {
    original: amount,
    converted: Math.round(amount * rate * 100) / 100,
    rate,
    from: fromCurrency,
    to: toCurrency
  };
}

This one is the simplest of the three. No pagination, no chunking, just a clean JSON response.

Pitfall #4: Exchange rates update daily, not in real-time. If your tool needs live pricing (like for an e-commerce app), this API won't cut it. For recipe ingredients, it's more than enough.

Putting It All Together

Here's the main function that chains all three APIs:

async function recipeToWorld(recipeName, targetLang, targetCurrency) {
  console.log(`🔍 Searching for "${recipeName}"...`);
  const recipe = await getRecipe(recipeName);

  console.log(`🌐 Translating to ${targetLang}...`);
  const translatedName = await translateText(recipe.name, targetLang);
  const translatedInstructions = await translateText(recipe.instructions, targetLang);

  const translatedIngredients = [];
  for (const ing of recipe.ingredients) {
    const translatedName = await translateText(ing.name, targetLang);
    translatedIngredients.push({ ...ing, name: translatedName });
  }

  console.log(`💱 Converting prices to ${targetCurrency}...`);
  // Note: TheMealDB doesn't include prices, so we estimate
  // based on typical grocery costs
  const estimatedPrices = estimateIngredientCosts(recipe.ingredients);

  return {
    name: translatedName,
    category: recipe.category,
    area: recipe.area,
    instructions: translatedInstructions,
    ingredients: translatedIngredients.map((ing, i) => ({
      ...ing,
      estimatedCost: estimatedPrices[i]
    }))
  };
}

Pitfall #5: TheMealDB doesn't include ingredient prices. I had to build a small cost estimation table for common ingredients. This is the kind of thing that's obvious in hindsight but easy to miss when you're excited about chaining APIs.

The Hard Part: Error Handling

Everything above works perfectly when the APIs are up and returning good data. In reality:

TheMealDB occasionally returns empty results for valid recipe names
LibreTranslate instances go down without warning
ExchangeRate-API rate limits at 1,000 requests/month on the free tier

Here's my error handling pattern:

async function safeFetch(fn, fallback, retries = 2) {
  for (let i = 0; i <= retries; i++) {
    try {
      return await fn();
    } catch (error) {
      if (i === retries) {
        console.warn(`⚠️ Using fallback: ${error.message}`);
        return fallback;
      }
      // Wait before retrying (exponential backoff)
      await new Promise(r => setTimeout(r, 1000 * (i + 1)));
    }
  }
}

Use it like this:

const recipe = await safeFetch(
  () => getRecipe(name),
  { name: name, instructions: 'Recipe not found', ingredients: [] }
);

const translated = await safeFetch(
  () => translateText(recipe.instructions, lang),
  recipe.instructions  // Fall back to English
);

Pitfall #6: Free APIs don't guarantee uptime. If you build something that chains 3+ APIs together, you need fallbacks for each one. A chain is only as strong as its weakest link.

What I'd Do Differently

Cache aggressively. Exchange rates change daily. Recipe data rarely changes. Cache both locally and reduce API calls.
Use a translation library as a fallback. If LibreTranslate is down, having a local fallback (even a simple dictionary for common cooking terms) keeps the tool functional.
Add input validation early. Recipe names with special characters can cause URL encoding issues. Sanitize inputs before the first API call.
Handle encoding properly. Translating to languages like Chinese, Japanese, or Arabic means dealing with UTF-8 carefully. Some older tools mess this up.

The Result

The final tool is about 150 lines of JavaScript. It takes three arguments:

$ node recipe-world.js "chicken curry" ja JPY

🔍 Searching for "chicken curry"...
🌐 Translating to Japanese...
💱 Converting prices to JPY...

チキンカレー (Indian)
Category: Chicken
Area: Indian

Ingredients:
- 鶏肉 (Chicken) — est. ¥350
- ココナッツミルク (Coconut Milk) — est. ¥200
- カレーパウダー (Curry Powder) — est. ¥150
...

Instructions:
チキンを一口大に切ります。...

Wrapping Up

Building with free APIs is genuinely fun. The biggest lesson: treat every API call as if it will fail. Rate limits, downtime, unexpected response formats — they're not edge cases, they're the normal case for free services.

If you're building a side project and need recipe data, translation, or currency conversion, all three of these APIs are solid starting points. Just remember to chunk your translation requests, cache your exchange rates, and always have a fallback plan.

If you're looking for a convenient way to access multiple free APIs through a single endpoint (translation, weather, food data, and more), I've been using a tool called QuotaLink that aggregates these services. It saves me from managing three separate API integrations.

I Built a Multilingual App Using Free APIs — Here's What Actually Works

Doushabao — Tue, 01 Sep 2026 13:06:18 +0000

I Built a Multilingual App Using Free APIs — Here's What Actually Works

I wanted to add language detection and translation to a side project. You know, the kind of feature that makes your app feel polished without spending money.

So I went looking for free translation APIs. And wow, the landscape is confusing.

The Problem

Google Translate API requires a billing account. Microsoft Translator needs a credit card for anything beyond the free trial. DeepL has a free tier but it's limited to 500,000 characters/month.

For a weekend project or a hackathon, that's too much friction. I just wanted something that works.

What I Tested

I spent a few hours testing different approaches. Here's what I found.

Approach 1: Free tier from major providers

Most big players (Google, Microsoft, DeepL) offer free tiers, but they all require signing up with a credit card. If you're building something for a hackathon or a student project, that's a non-starter.

Approach 2: Open-source translation models

There are open-source options like Argos Translate and LibreTranslate. You can self-host them, which is great for privacy. But setup takes time, and the quality varies by language pair.

Approach 3: Curated API platforms

This is where things got interesting. I found platforms that aggregate multiple free APIs under one roof. Instead of signing up for 5 different services, you get one API key and access to translation, weather, geolocation, and more.

What Actually Worked for Me

After testing, here's what I settled on:

For quick prototyping: Use a curated API platform that wraps multiple free services. One API key, consistent documentation, and you can swap providers without changing your code.
For production: If you're building something serious, self-host an open-source translation model. You get full control and no rate limits.
For one-off translations: Browser-based tools are fine. Don't build an API integration for something you'll use once.

The Integration Pattern

Regardless of which API you use, the pattern is the same:

Detect the source language
Send the text to the translation endpoint
Handle the response (usually JSON)
Cache results to avoid redundant calls

The key insight: don't hardcode your API provider. Write a thin wrapper around your translation function so you can swap providers later. I learned this the hard way when my "free" API started requiring a credit card after 2 months.

Common Gotchas

Rate limits sneak up on you. Free tiers usually have daily or monthly caps. If you're building a chat app, you'll hit them fast. Cache aggressively.

Language support varies wildly. Most free APIs handle English, Spanish, French well. But for less common languages like Thai or Hindi, quality drops significantly. Test with your target languages before committing.

Response formats differ. Some return plain text, others return structured JSON with confidence scores. Don't assume the format — read the docs.

What I Learned

Free doesn't mean unlimited. Every free API has limits. Know them before you build.
Self-hosting is underrated. For translation, running your own model gives you full control. The setup time pays off.
Curated platforms save time. Instead of managing 10 API keys, use one platform that aggregates the services you need.
Cache everything. Translation results don't change. If you translated "hello" once, you don't need to do it again.

Try It

If you want to experiment with free APIs without signing up for a dozen services, check out QuotaLink. It aggregates 20+ free APIs — translation, weather, geolocation, and more — under one roof. Free tier, no credit card required.

What's your go-to free API for translation? I'm always looking for new tools to test.