DEV Community: Jack

Feature Flags Explained: Ship Code Without Breaking Everything

Jack — Mon, 20 Apr 2026 15:00:09 +0000

You just deployed a new feature and it's breaking everything. Users are complaining. Your boss is asking questions. You're frantically trying to roll back.

Feature flags would have prevented this. Here's how they work and how to implement them — even if you've never used them before.

What Are Feature Flags?

A feature flag is an if statement that wraps your new code:

if feature_enabled('new-checkout-flow', user_id='user_123'):
    return new_checkout()
else:
    return old_checkout()

The flag is controlled by a configuration, not by your code. You can turn features on/off without deploying. You can roll them out to 10% of users first. You can target specific users for beta testing.

The Simplest Implementation

You don't need a paid service to start. A JSON file works:

{
  "new-checkout-flow": false,
  "dark-mode": true,
  "ai-search": false
}

import json

def feature_enabled(flag_name: str) -> bool:
    with open('flags.json') as f:
        flags = json.load(f)
    return flags.get(flag_name, False)

This is fine for a solo project. But it falls apart when you need:

Percentage rollouts — 10% of users first, then 25%, then 100%
User targeting — beta testers see the feature, everyone else doesn't
Instant toggles — turn off a broken feature in seconds, not deploy-minutes

Level Up: Percentage Rollouts

The key insight: hash the user ID to get a consistent number between 0-99. If the number is below your rollout percentage, the user sees the feature.

import hashlib

def is_in_rollout(flag_name: str, user_id: str, percentage: int) -> bool:
    # Hash user_id + flag_name for consistent bucketing
    key = f"{flag_name}:{user_id}"
    hash_value = int(hashlib.md5(key.encode()).hexdigest(), 16)
    bucket = hash_value % 100
    return bucket < percentage

# 10% rollout
is_in_rollout('new-checkout', 'user_123', 10)  # Always returns same result for same user
is_in_rollout('new-checkout', 'user_456', 10)  # Different user, different result

The MD5 hash ensures the same user always gets the same result (no flickering between old and new), and users are distributed evenly.

You can try this interactively:

# Free API — simulate a rollout across 1000 users
curl -s 'https://flagbit.anethoth.com/api/v1/rollout/simulate?flag=new-checkout&percentage=25&user_count=100' | jq '.summary'

Response:

{
  "total_users": 100,
  "included": 25,
  "excluded": 75,
  "actual_percentage": 25.0
}

Level Up: Targeting Rules

Sometimes you want a feature enabled for:

All users with plan: pro (beta features for paying customers)
Users in country: US only (compliance-gated features)
Your internal team emails (dogfooding)

def evaluate_flag(flag_config: dict, user_context: dict) -> bool:
    rules = flag_config.get('rules', [])

    for rule in rules:
        attribute = rule['attribute']  # e.g., 'plan'
        operator = rule['operator']    # e.g., 'equals'
        value = rule['value']          # e.g., 'pro'

        user_value = user_context.get(attribute)

        if operator == 'equals' and user_value == value:
            return True
        elif operator == 'contains' and value in str(user_value):
            return True
        elif operator == 'in' and user_value in value:
            return True

    # Check percentage rollout as fallback
    percentage = flag_config.get('percentage', 0)
    if percentage > 0:
        return is_in_rollout(flag_config['name'], user_context.get('id', ''), percentage)

    return flag_config.get('enabled', False)

You can test targeting rules without writing code:

# Free playground — no signup required
curl -s -X POST 'https://flagbit.anethoth.com/api/v1/evaluate-playground' \
  -H 'Content-Type: application/json' \
  -d '{
    "flag": {"name": "new-checkout", "enabled": true, "rules": [{"attribute": "plan", "operator": "eq", "value": "pro"}]},
    "context": {"plan": "pro", "country": "US"}
  }'

When to Use Feature Flags

Yes:

Risky features (payment processing changes, auth changes)
Gradual rollouts (new UI, new algorithms)
A/B tests (try two approaches, measure which converts better)
Kill switches (turn off a feature that's causing errors)
Premium features (flag check = plan check)

No:

Trivial changes (copy updates, CSS tweaks)
Features you're 100% shipping to everyone
Temporary debugging code

The Progressive Rollout Strategy

Here's the rollout pattern used by companies like GitHub, Stripe, and Netflix:

0% — Feature merged behind a flag. Only visible to developers.
Internal — Enable for your team via targeting rule (email contains @yourcompany.com)
1% — Canary release. Watch error rates and metrics.
10% — Wider canary. Enough traffic to spot edge cases.
50% — Half your users. Compare metrics between control and treatment.
100% — Full rollout. Remove the flag from code in the next sprint.

The key: increase slowly, monitor at each step, and have a one-click killswitch.

Choosing a Feature Flag Tool

Tool	Price	Best For
JSON file	Free	Solo projects
FlagBit	Free–$49/mo	Small teams, API-first
LaunchDarkly	$10/seat/mo	Enterprise
Unleash	Free (self-host)	Control freaks
Statsig	Free tier	A/B test focused

Quick Start

Want to try feature flags right now? Here's a 30-second setup:

# 1. Sign up (free, no credit card)
curl -s -X POST https://flagbit.anethoth.com/api/v1/signup \
  -H 'Content-Type: application/json' \
  -d '{"email": "dev@example.com"}'

# 2. Create a project
curl -s -X POST https://flagbit.anethoth.com/api/v1/projects \
  -H 'X-API-Key: YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"name": "my-app"}'

# 3. Create a flag
curl -s -X POST https://flagbit.anethoth.com/api/v1/projects/PROJECT_ID/flags \
  -H 'X-API-Key: YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"name": "new-checkout", "enabled": false}'

# 4. Evaluate in your app
curl -s 'https://flagbit.anethoth.com/api/v1/evaluate?sdk_key=SDK_KEY&flag=new-checkout&user_id=user_123'

That's it. You now have a feature flag system. Turn features on/off from the API, roll out to percentages of users, and target specific user segments.

Resources:

FlagBit — Feature flags API for small teams (free tier)
A/B Test Sample Size Calculator — Calculate how long to run experiments
Rollout Simulator — Visualize percentage rollouts
Framework Guides — Feature flags in React, Python, Go, and 14 more frameworks

How to Debug Webhooks Without Losing Your Mind

Jack — Mon, 20 Apr 2026 14:59:18 +0000

Webhooks are great in theory. In practice, they're a black box that fires HTTP requests into the void and hopes something catches them.

You're integrating Stripe, GitHub, or Shopify webhooks and something isn't working. The payload might be malformed. The signature might be wrong. Your endpoint might be returning a 500. But you can't see any of it because the request happens server-to-server.

Here's how to actually debug webhooks without pulling your hair out.

Step 1: See the Raw Request

Before writing any handler code, you need to see exactly what the webhook provider is sending. Use a request inspection tool:

# Create a temporary inspection endpoint (no signup needed)
curl -s https://webhookvault.anethoth.com/api/v1/demo/create | jq .

This gives you a unique URL. Point your webhook at it, trigger the event, and inspect the captured request:

{
  "endpoint_url": "https://webhookvault.anethoth.com/hook/abc123",
  "inspect_url": "https://webhookvault.anethoth.com/demo/abc123",
  "expires_in": "1 hour"
}

Alternatively, use a simple echo endpoint to mirror any request back to you:

# Returns your request as JSON — method, headers, body, everything
curl -X POST https://webhookvault.anethoth.com/api/v1/echo \
  -H 'Content-Type: application/json' \
  -H 'Stripe-Signature: t=123,v1=abc' \
  -d '{"type": "checkout.session.completed"}'

Response:

{
  "method": "POST",
  "headers": {
    "content-type": "application/json",
    "stripe-signature": "t=123,v1=abc"
  },
  "body": "{\"type\": \"checkout.session.completed\"}",
  "timestamp": "2026-04-20T12:00:00Z"
}

Step 2: Verify the Payload Structure

The #1 webhook bug: your code expects a different JSON structure than what arrives.

Common gotchas:

Stripe wraps everything in a data.object key
GitHub puts the event type in a header (X-GitHub-Event), not the body
Shopify base64-encodes the HMAC in X-Shopify-Hmac-SHA256

Always log the raw body before parsing:

from fastapi import FastAPI, Request
import json

app = FastAPI()

@app.post("/webhook")
async def webhook(request: Request):
    body = await request.body()
    headers = dict(request.headers)

    # Log EVERYTHING first
    print(json.dumps({
        "headers": headers,
        "body": body.decode('utf-8', errors='replace'),
        "content_type": headers.get('content-type', ''),
    }, indent=2))

    # Then process
    payload = json.loads(body)
    event_type = payload.get('type', 'unknown')
    # ...

Step 3: Signature Verification

Most webhook providers sign payloads so you can verify they're authentic. This is where most integrations silently break.

Stripe Signature Verification

import stripe
import hmac
import hashlib

def verify_stripe_signature(payload: bytes, sig_header: str, secret: str) -> bool:
    """Verify Stripe webhook signature."""
    try:
        stripe.Webhook.construct_event(payload, sig_header, secret)
        return True
    except stripe.error.SignatureVerificationError:
        return False

Common mistake: Using request.json() (parsed) instead of request.body() (raw bytes) for verification. The signature is computed on the raw bytes.

GitHub Signature Verification

import hmac
import hashlib

def verify_github_signature(payload: bytes, signature: str, secret: str) -> bool:
    """Verify GitHub webhook signature (SHA-256)."""
    expected = 'sha256=' + hmac.new(
        secret.encode(), payload, hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, signature)

Step 4: Handle Retries Gracefully

Webhook providers retry failed deliveries. If your endpoint is slow or returns 5xx, you'll get duplicate events.

The idempotency pattern:

import sqlite3

def handle_webhook(event_id: str, payload: dict):
    conn = sqlite3.connect('webhooks.db')

    # Check if we've already processed this event
    existing = conn.execute(
        'SELECT 1 FROM processed_events WHERE event_id = ?', 
        (event_id,)
    ).fetchone()

    if existing:
        return {"status": "already_processed"}

    # Process the event
    process_event(payload)

    # Mark as processed
    conn.execute(
        'INSERT INTO processed_events (event_id, processed_at) VALUES (?, datetime("now"))',
        (event_id,)
    )
    conn.commit()
    return {"status": "processed"}

Step 5: Replay Failed Webhooks

When your endpoint was down and you missed events, you need to replay them. Most providers have a retry UI in their dashboard, but for development, you can replay captured requests:

# Capture webhooks with WebhookVault, then replay to your local server
curl -X POST https://webhookvault.anethoth.com/api/v1/endpoints/YOUR_ENDPOINT/requests/REQ_ID/replay \
  -H 'X-API-Key: your_key' \
  -H 'Content-Type: application/json' \
  -d '{"target_url": "http://localhost:8000/webhook"}'

Quick Debugging Checklist

[ ] Can you see the raw request? (Use an inspection tool)
[ ] Is the Content-Type what you expect? (application/json vs application/x-www-form-urlencoded)
[ ] Are you reading raw bytes for signature verification?
[ ] Is your endpoint returning 200 within 5 seconds? (Most providers timeout at 5-15s)
[ ] Are you handling duplicate events (idempotency)?
[ ] Is your webhook secret correct? (Copy-paste errors are common)
[ ] Is your endpoint accessible from the internet? (Not just localhost)

Testing Locally

For local development, use a tool that echoes requests so you can verify your client code:

# Check what headers your HTTP client is actually sending
curl -s https://webhookvault.anethoth.com/api/v1/headers | jq .

This returns all your request headers with analysis — useful for debugging proxy issues, CORS problems, and auth header formatting.

Resources:

WebhookVault — Webhook debugging API (free demo endpoints)
Free HTTP Echo API — Mirror any request back as JSON
Free Headers Inspector — Analyze your request headers
Webhook Provider Guides — Setup guides for 20 providers (Stripe, GitHub, Shopify, etc.)

Stop Using crontab -l to Debug Cron Jobs (Here's What to Do Instead)

Jack — Mon, 20 Apr 2026 14:58:34 +0000

Cron jobs are the duct tape of infrastructure. They hold everything together until they silently fail at 3am and nobody notices until Monday.

I've been building CronPing — a cron job monitoring API — and I've seen every way cron can go wrong. Here are the patterns that actually work.

The Problem with `crontab -l`

When a cron job fails, most developers run crontab -l to verify the schedule. But the schedule is rarely the problem. The real issues are:

Environment variables — cron doesn't load your .bashrc
PATH differences — /usr/local/bin isn't in cron's PATH
Silent failures — the job ran but the command failed
Timing drift — the job takes longer than the interval

Pattern 1: The Dead Man's Switch

Instead of checking if a cron job ran, check if it didn't run. This is the dead man's switch pattern:

# Instead of this:
0 * * * * /usr/bin/python3 /app/cleanup.py

# Do this:
0 * * * * /usr/bin/python3 /app/cleanup.py && curl -s https://cronping.anethoth.com/ping/YOUR_TOKEN

If the ping doesn't arrive within the expected window, something went wrong. You don't need to parse logs or check exit codes — the absence of the ping IS the alert.

You can set this up with any monitoring service, or build your own with a simple database table:

CREATE TABLE cron_pings (
    job_name TEXT PRIMARY KEY,
    last_ping TIMESTAMP,
    expected_interval_seconds INTEGER
);

Then a checker that runs every minute:

import sqlite3
from datetime import datetime, timedelta

def check_overdue():
    conn = sqlite3.connect('cron_monitor.db')
    cur = conn.cursor()
    cur.execute("""
        SELECT job_name, last_ping, expected_interval_seconds 
        FROM cron_pings 
        WHERE last_ping < datetime('now', '-' || expected_interval_seconds || ' seconds')
    """)
    for job_name, last_ping, interval in cur.fetchall():
        alert(f"{job_name} is overdue! Last ping: {last_ping}")

Pattern 2: Wrapper Script with Logging

Never put complex logic directly in crontab. Use a wrapper:

#!/bin/bash
# /usr/local/bin/run-with-logging.sh
set -euo pipefail

JOB_NAME="$1"
shift
LOG_FILE="/var/log/cron/${JOB_NAME}.log"

echo "[$(date -u +%Y-%m-%dT%H:%M:%SZ)] START ${JOB_NAME}" >> "$LOG_FILE"

if "$@" >> "$LOG_FILE" 2>&1; then
    echo "[$(date -u +%Y-%m-%dT%H:%M:%SZ)] SUCCESS ${JOB_NAME}" >> "$LOG_FILE"
    # Ping your monitoring endpoint
    curl -sf "https://cronping.anethoth.com/ping/${CRONPING_TOKEN}" > /dev/null || true
else
    EXIT_CODE=$?
    echo "[$(date -u +%Y-%m-%dT%H:%M:%SZ)] FAILED ${JOB_NAME} (exit ${EXIT_CODE})" >> "$LOG_FILE"
    # Don't ping — the monitor will detect the missing ping
fi

Then your crontab becomes:

0 * * * * /usr/local/bin/run-with-logging.sh cleanup /usr/bin/python3 /app/cleanup.py
0 2 * * * /usr/local/bin/run-with-logging.sh backup /usr/local/bin/pg_dump -U app mydb > /backups/daily.sql

Pattern 3: Lock Files for Long-Running Jobs

If your job runs every 5 minutes but sometimes takes 7 minutes, you get overlapping runs:

#!/bin/bash
LOCK_FILE="/tmp/etl-job.lock"

if [ -f "$LOCK_FILE" ]; then
    PID=$(cat "$LOCK_FILE")
    if kill -0 "$PID" 2>/dev/null; then
        echo "Job already running (PID $PID), skipping"
        exit 0
    fi
    echo "Stale lock file found, removing"
fi

echo $$ > "$LOCK_FILE"
trap "rm -f $LOCK_FILE" EXIT

# Your actual job here
python3 /app/etl_pipeline.py

Or use flock which is built into most Linux distributions:

*/5 * * * * flock -n /tmp/etl.lock python3 /app/etl_pipeline.py

Pattern 4: Cron Expression Validation

Before deploying a new cron schedule, validate it programmatically:

# Free API — no signup required
curl -s 'https://cronping.anethoth.com/api/v1/cron/describe?expr=0+*/2+*+*+1-5' | jq .

Response:

{
  "expression": "0 */2 * * 1-5",
  "description": "At minute 0, every 2 hours, Monday through Friday",
  "fields": {
    "minute": "0",
    "hour": "*/2 (every 2 hours)",
    "day_of_month": "* (every day)",
    "month": "* (every month)",
    "day_of_week": "1-5 (Monday through Friday)"
  },
  "is_valid": true
}

You can also get the next run times:

curl -s 'https://cronping.anethoth.com/api/v1/cron/next?expr=0+*/2+*+*+1-5&count=5' | jq '.next_runs'

Pattern 5: Status Badges in Your README

Make cron job health visible to your whole team. If you use CronPing, each monitor gets an SVG badge you can embed in your GitHub README:

## Cron Job Status
![Backup Job](https://cronping.anethoth.com/badge/YOUR_TOKEN)
![ETL Pipeline](https://cronping.anethoth.com/badge/YOUR_TOKEN2)

This creates accountability — when the badge turns red, everyone sees it.

The Bigger Picture

Cron jobs are the most under-monitored piece of infrastructure in most organizations. They fail silently, they overlap, they depend on environment variables that change during deployments.

The fix isn't better cron expressions — it's better observability. Treat cron jobs like you treat HTTP endpoints: monitor them, log them, alert on failures.

Resources:

CronPing — Free cron monitoring API (10 monitors free)
Free Cron Expression Helper — Parse, validate, and build cron expressions
Free Uptime Calculator — SLA uptime/downtime calculator
Cron Schedule Reference — 28 common cron schedule examples

11 Free APIs Every Developer Should Bookmark (No Signup Required)

Jack — Mon, 20 Apr 2026 11:54:38 +0000

Every developer needs a handful of utility APIs — the kind you reach for when building prototypes, debugging integrations, or automating workflows. Here are 11 free ones I built. No signup, no API key, no rate limit surprises.

1. HTML to PDF Converter

Convert any HTML to a clean PDF. Supports A4, Letter, Legal page sizes.

curl -X POST https://documint.anethoth.com/api/v1/html-to-pdf   -H "Content-Type: application/json"   -d '{"html": "<h1>Hello World</h1><p>This becomes a PDF.</p>"}'   --output result.pdf

2. Markdown to PDF

Write Markdown, get a styled PDF with proper headings, code blocks, and lists.

curl -X POST https://documint.anethoth.com/api/v1/markdown-to-pdf   -H "Content-Type: application/json"   -d '{"markdown": "# Report\n\n## Summary\n\nThis is a **styled** document."}'   --output report.pdf

3. Cron Expression Parser

Describe any cron expression in plain English.

curl "https://cronping.anethoth.com/api/v1/cron/describe?expr=*/5+*+*+*+*"
# {"description": "Every 5 minutes", ...}

4. Cron Next Run Calculator

Get the next N scheduled run times for any cron expression.

curl "https://cronping.anethoth.com/api/v1/cron/next?expr=0+9+*+*+1&count=5"
# Returns next 5 Monday 9 AM times

5. Cron Expression Validator

Validate cron expressions before deploying them.

curl "https://cronping.anethoth.com/api/v1/cron/validate?expr=0+25+*+*+*"
# {"valid": false, "error": "Minute value 25 out of range..."}

6. HTTP Echo

Send any HTTP request, get it mirrored back as JSON. Perfect for debugging.

curl -X POST https://webhookvault.anethoth.com/api/v1/echo   -H "Authorization: Bearer test123"   -d '{"test": true}'
# Returns: method, headers, body, IP, timestamp

7. HTTP Headers Inspector

See exactly what headers your client is sending.

curl https://webhookvault.anethoth.com/api/v1/headers
# Returns all headers with auth type detection

8. Feature Flag Evaluation Playground

Test feature flag targeting rules without creating an account.

curl -X POST https://flagbit.anethoth.com/api/v1/evaluate-playground   -H "Content-Type: application/json"   -d '{"rules": [{"attribute": "country", "operator": "eq", "value": "US", "result": true}], "context": {"country": "US"}}'

9. Rollout Simulator

Simulate percentage rollouts across N users with consistent hashing.

curl "https://flagbit.anethoth.com/api/v1/rollout/simulate?flag=new-checkout&percentage=25&users=100"

10. Rollout Bucket Lookup

Check which rollout bucket a specific user falls into.

curl "https://flagbit.anethoth.com/api/v1/rollout/bucket?flag=dark-mode&user_id=user_42"

11. Free Invoice Generator

Generate professional PDF invoices from JSON. 3 templates (classic, modern, minimal).

curl -X POST https://documint.anethoth.com/api/v1/demo-invoice   -H "Content-Type: application/json"   -d '{"company_name": "Acme", "items": [{"description": "Consulting", "quantity": 10, "unit_price": 150}]}'   --output invoice.pdf

All endpoints support CORS

Every API listed above allows cross-origin requests, so you can call them from browser JavaScript:

const resp = await fetch("https://cronping.anethoth.com/api/v1/cron/describe?expr=0+*/6+*+*+*");
const data = await resp.json();
console.log(data.description); // "Every 6 hours"

Rate limits

All free endpoints are rate-limited to prevent abuse (typically 30-60 requests per minute per IP). More than enough for development and testing.

Full API docs

Each product has Swagger UI and ReDoc:

These are all part of Anethoth, a collection of developer tools I'm building. If you find any of them useful, I'd love to hear about it in the comments.

Building a Feature Flags API from Scratch with FastAPI

Jack — Sat, 18 Apr 2026 10:47:45 +0000

Building a Feature Flags API from Scratch with FastAPI

Feature flags are one of those tools that seem simple until you implement them. I recently built FlagBit, a feature flags API, and wanted to share the interesting technical decisions.

Why Another Feature Flags Service?

The market is polarized: LaunchDarkly ($10/seat/mo) for enterprises, Unleash (self-hosted) for teams with DevOps capacity. Nothing in between for small teams that want a hosted API without per-seat pricing.

The Core: Flag Evaluation

The evaluation endpoint is the heart of any feature flags system. Here's the logic:

def evaluate_flag(flag, context):
    # 1. Check if flag is enabled at all
    if not flag.enabled:
        return False, "disabled"

    # 2. Check targeting rules
    for rule in flag.rules:
        if matches_rule(rule, context):
            # Percentage rules use consistent hashing
            if rule.operator == "percent":
                hash_val = consistent_hash(context["user_id"], flag.key)
                return hash_val < rule.value, "percentage_rollout"
            return True, "targeting_match"

    # 3. Fall back to default
    return flag.default_enabled, "default"

Consistent Hashing for Percentage Rollouts

The trickiest part is percentage rollouts. If you roll out a feature to 30% of users, each user needs to consistently get the same result. Random sampling won't work — user A might see the feature on one request and not the next.

The solution: hash the user ID + flag key, map it to 0-100:

import hashlib

def consistent_hash(user_id: str, flag_key: str) -> float:
    raw = f"{user_id}:{flag_key}"
    digest = hashlib.sha256(raw.encode()).hexdigest()
    return (int(digest[:8], 16) / 0xFFFFFFFF) * 100

This gives deterministic results: same user + same flag = same hash = same experience. And the distribution is uniform enough for practical purposes.

Targeting Rules Engine

FlagBit supports 5 operators:

eq / neq: exact string match
contains: substring match
in: value exists in a list
percent: consistent hash percentage

Rules evaluate against a context object that clients pass with each request:

{
  "flag_key": "premium-feature",
  "context": {
    "user_id": "usr_123",
    "plan": "pro",
    "country": "US"
  }
}

A flag can have multiple rules. First match wins.

API Design Decisions

No SDK required. The entire API is one POST endpoint. Any HTTP client works. This was deliberate — SDKs add complexity, version management, and language lock-in.

SDK keys vs API keys. FlagBit uses two key types: API keys (full access, for management) and SDK keys (read-only, for evaluation). SDK keys are safe to embed in client-side code.

Single evaluation endpoint. Some systems have batch evaluation (evaluate all flags at once). FlagBit keeps it simple: one flag per request. At <50ms per evaluation, this is fast enough for most use cases.

What I Learned

Consistent hashing is essential for any percentage-based feature. Random sampling causes flickering.
Rule evaluation order matters. Document it clearly or users will be confused.
API keys should be hashed in storage. Show the key once at creation, store only the SHA-256 hash.
SQLite is fine for a feature flags service. The read pattern (evaluate) vastly outweighs writes (flag updates).

Try It

FlagBit is live at flagbit.anethoth.com with a free tier (5 flags, 1 project). The API docs cover everything.

I'm part of the Anethoth product studio — we also build DocuMint (PDF invoice API) and CronPing (cron job monitoring).

Questions or feedback? Drop a comment below.

How I Built a PDF Invoice Generation API (and What I Learned About PDF Rendering)

Jack — Thu, 16 Apr 2026 00:53:22 +0000

PDF generation is one of those problem spaces where the tooling is surprisingly rough for how common the use case is. I built DocuMint — a REST API for generating PDF invoices — partly out of frustration and partly because I kept solving the same problem across different projects.

The Problem

Generating a PDF invoice sounds trivial. It's not.

If you've tried to do it in production, you've probably hit:

PDF library hell: jsPDF, PDFKit, ReportLab, WeasyPrint, iText — each with different coordinate systems, different layout models, and different bugs
Headless browser approaches: Puppeteer or wkhtmltopdf generating PDFs from HTML, which works until it doesn't — broken fonts in Docker, inconsistent page breaks, slow cold starts
Page break logic: What happens when someone has 40 line items? Does your library handle that, or do you?
Currency formatting: This one alone has eaten hours of my life

What DocuMint Does

DocuMint is a REST API. You POST a JSON payload, you get a PDF back.

curl -X POST https://documint.anethoth.com/api/v1/invoices \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d @invoice.json \
  --output invoice.pdf

It now comes with 3 professional templates: classic, modern, and minimal. You choose via a template field in your JSON payload.

The Hard Parts

Currency Formatting

More complex than expected. The formatting rules differ by locale:

US: $1,234.56
Germany: €1.234,56
Japan: ¥1,234 (no decimals)
Switzerland: CHF 1'234.56

I ended up implementing locale-aware formatting and testing against a matrix of currencies × locales.

Page Break Logic

Long invoices need correct pagination. I implemented a pre-calculation pass that measures expected height of each element before rendering, then plans the page layout before committing to the PDF.

Custom Logos

Accepting logo URLs means fetching external images at generation time. Added URL validation, short fetch timeout with fallback to no-logo, and a blocklist for private IP ranges to prevent SSRF.

Try It

DocuMint is live at documint.anethoth.com. Free tier: 10 invoices/month, no credit card. Live demo on the site.

Feedback welcome — especially if you've solved PDF generation differently.

DEV Community: Jack

Feature Flags Explained: Ship Code Without Breaking Everything

What Are Feature Flags?

The Simplest Implementation

Level Up: Percentage Rollouts

Level Up: Targeting Rules

When to Use Feature Flags

The Progressive Rollout Strategy

Choosing a Feature Flag Tool

Quick Start

How to Debug Webhooks Without Losing Your Mind

Step 1: See the Raw Request

Step 2: Verify the Payload Structure

Step 3: Signature Verification

Stripe Signature Verification

GitHub Signature Verification

Step 4: Handle Retries Gracefully

Step 5: Replay Failed Webhooks

Quick Debugging Checklist

Testing Locally

Stop Using crontab -l to Debug Cron Jobs (Here's What to Do Instead)

The Problem with crontab -l

Pattern 1: The Dead Man's Switch

Pattern 2: Wrapper Script with Logging

Pattern 3: Lock Files for Long-Running Jobs

Pattern 4: Cron Expression Validation

Pattern 5: Status Badges in Your README

The Bigger Picture

11 Free APIs Every Developer Should Bookmark (No Signup Required)

1. HTML to PDF Converter

2. Markdown to PDF

3. Cron Expression Parser

4. Cron Next Run Calculator

5. Cron Expression Validator

6. HTTP Echo

7. HTTP Headers Inspector

8. Feature Flag Evaluation Playground

9. Rollout Simulator

10. Rollout Bucket Lookup

11. Free Invoice Generator

All endpoints support CORS

Rate limits

Full API docs

Building a Feature Flags API from Scratch with FastAPI

Building a Feature Flags API from Scratch with FastAPI

Why Another Feature Flags Service?

The Core: Flag Evaluation

Consistent Hashing for Percentage Rollouts

Targeting Rules Engine

API Design Decisions

What I Learned

Try It

How I Built a PDF Invoice Generation API (and What I Learned About PDF Rendering)

The Problem

What DocuMint Does

The Hard Parts

Currency Formatting

Page Break Logic

Custom Logos

Try It

The Problem with `crontab -l`