DEV Community: David | Kordhub

3 FastAPI Services, 1 Process: The Bugs Nobody Warns You About published: false tags: fastapi, python, api, webdev

David | Kordhub — Mon, 03 Aug 2026 16:01:53 +0000

I had three independent FastAPI services, each with its own repo and its own deployment, and I wanted to merge them into a single process — one app, three mounted sub-apps. On paper it's a five-line change: import each app, app.mount() it under a prefix, done.

In practice, it surfaced three bugs I wouldn't have hit any other way — and they're the kind of bugs that only show up once code that worked fine in isolation has to share a process with siblings it's never met.

The setup

Three independent APIs, each its own repo:

Discord Webhook Shield — stores Discord webhook URLs encrypted, proxies messages through with spam filtering and optional AI-based formatting
QR Code Generator — PNG/SVG generation with logo overlay
JSON Repair — fixes malformed JSON from LLM output, falling back to an AI repair pass when the deterministic parser can't handle it

Merging them meant mounting all three as FastAPI sub-applications under one root app:

from fastapi import FastAPI
from webhook_shield.main import app as webhook_shield_app
from qr_generator.main import app as qr_generator_app
from json_fixer.main import app as json_repair_app

app = FastAPI(title="Kordhub API Suite")
app.mount("/webhook-shield", webhook_shield_app)
app.mount("/qr", qr_generator_app)
app.mount("/json-repair", json_repair_app)

Straightforward. Then I actually ran it.

Bug #1: a package shadowing its own dependency

The JSON repair service imports the json_repair library (from json_repair import repair_json). I'd named its own package folder json_repair too, for symmetry with the other two. Python resolved the local package first, and the import inside it silently broke — a name collision that only exists once you put sibling services in the same interpreter. Renamed the folder to json_fixer, problem gone. Obvious in hindsight, invisible until you actually boot the merged process.

Bug #2: `.env` files stomping on each other

Each service loaded its own .env the same way:

load_dotenv(dotenv_path=Path(__file__).resolve().parent / ".env")

python-dotenv's load_dotenv() does not override a variable that's already set in the process environment — by default. That's fine when each service is its own process. It's not fine when three services share one process and all three .env files define a key with the same name (RAPIDAPI_PROXY_SECRET, in my case, each with a different value). Whichever module imports first "wins," and the other two silently validate against the wrong secret.

The minimal fix was override=True on each load_dotenv() call, so each module's own file takes precedence at the moment it loads. But that only solves it for local development, where each sub-package still has its own .env file. On a platform like Render, environment variables are injected once, process-wide — there's no such thing as three separate .env files anymore. So the real fix was to stop sharing the variable name at all: each sub-app now reads its own uniquely-named secret (WEBHOOK_SHIELD_PROXY_SECRET, QR_GENERATOR_PROXY_SECRET, JSON_FIXER_PROXY_SECRET), each still validated against the exact proxy secret RapidAPI already had configured for that specific API listing. No changes needed on RapidAPI's side, and the three services never have to agree on anything.

Bug #3: fail-fast code that fails the wrong thing

One of the services calls sys.exit(1) if a required credential is missing at import time — reasonable for a standalone service, since you want a fast, loud failure instead of serving broken requests. Reasonable, until it's one FastAPI sub-app mounted inside a bigger process: a missing variable now takes down all three APIs, not just the one that needed it. I left the fail-fast behavior in place (it's still the right call), but it's now a hard requirement that every environment variable for all three services be set together in the merged deployment — a constraint that didn't exist when they were separate.

What actually mattered

None of these were algorithm problems. They were all "two things that work fine alone don't automatically work fine together" problems — namespace collisions, shared process state, and failure modes that assume isolation. The lesson that generalizes: when you consolidate services that were never designed to share a process, test the combination, not just each piece. A health check on each mounted sub-app told me nothing about the env var collision — only calling a real authenticated endpoint on each one, with distinct test values, actually caught it.

The three APIs are live again, now sharing a single Render free-tier instance instead of three:

Curious how others have handled merging previously-independent services into one deployment — did you run into the same class of "works alone, breaks together" bugs, or something else entirely?

Generating branded QR codes with logo overlay in Python (PNG + SVG)

David | Kordhub — Mon, 06 Jul 2026 13:17:52 +0000

The Problem

Most QR code libraries give you a black-and-white square.
That's fine for internal tools, but if you need branded QR codes
for marketing, packaging, or invoices, you need custom colors,
your logo in the center, SVG output for print quality, and high
enough error correction that the QR still scans with a logo on top.

Why error correction matters for logo overlay

When you put a logo in the center of a QR code, you're covering
part of the data. QR codes have built-in error correction —
level H (30%) means the code can still be read even if 30% of it
is obscured. Always use H when adding a logo.

Generating a branded QR code

POST /v1/generate
{
  "data": "https://yoursite.com",
  "format": "png",
  "size": 500,
  "foreground_color": "#2563EB",
  "background_color": "#FFFFFF",
  "error_correction": "H",
  "logo_url": "https://yoursite.com/logo.png"
}

Response — the data field is base64-encoded PNG:

<img src="data:image/png;base64,iVBORw0KGgo..." />

PNG vs SVG

PNG — best for web, apps, and mobile. Supports logo overlay.

SVG — best for print and packaging. Scales infinitely without pixelation. No logo overlay support.

Validate before generating

POST /v1/validate
{
  "data": "your string here",
  "error_correction": "H"
}

Response:

{
  "valid": true,
  "estimated_version": 4,
  "message": "QR version 4 will be used"
}

Higher version = denser QR. Version 40 is the maximum.

Try it free

500 requests/month, no card required:

https://rapidapi.com/kordhubdev/api/kordhub-qr-code-generator

Feedback welcome — especially if you've found edge cases with logo overlay or very long URLs.

How I protect Discord webhook URLs from being exposed in frontend code

David | Kordhub — Fri, 03 Jul 2026 21:30:35 +0000

The Problem

If you've ever used Discord webhooks in a frontend app, you've probably done something like this:

const webhookUrl = "https://discord.com/api/webhooks/123456/abc..."
fetch(webhookUrl, { method: "POST", body: JSON.stringify(message) })

The problem: that URL is now visible to anyone who opens DevTools.
They can use it to spam your Discord server, send fake alerts,
or simply abuse it until Discord revokes it.

The Solution: Never expose the real URL

The pattern that actually works:

Register your webhook URL once through a secure backend
Get back a safe ID (like whk_abc123)
Use only that ID in your frontend — the real URL never leaves the server

How it works in practice

Register once (server-side or one-time setup):

POST /v1/webhooks
{ "discord_webhook_url": "https://discord.com/api/webhooks/..." }

Response: { "webhook_id": "whk_abc123" }

Send messages using only the ID:

POST /v1/send
{
  "webhook_id": "whk_abc123",
  "content": "New sale: $49.99",
  "title": "Payment received",
  "mode": "auto"
}

The server decrypts the real URL, formats the message into a
clean Discord embed, strips any @everyone/@here spam, and delivers it.
Your frontend never sees the real webhook URL again.

Bonus: automatic spam filtering

Even if someone on your team accidentally sends @everyone in
an automated message, the API strips it before it reaches Discord.

Try it free

I built this as a standalone API available on RapidAPI with a
free tier (200 messages/month, no card required):

https://rapidapi.com/kordhubdev/api/kordhub-discord-webhook-shield-formatter

Would love feedback — especially from anyone who's dealt with
webhook abuse before.

I built 3 free APIs for LLM developers — here's what I shipped and why

David | Kordhub — Wed, 01 Jul 2026 17:23:53 +0000

The Problem

If you've built anything with GPT-4, Claude, or Llama, you've probably run into these:

JSON that won't parse because of a trailing comma or markdown fence
Discord webhook URLs exposed in your frontend code
Needing QR codes dynamically but not wanting to pay per request

I kept hitting these same walls, so I spent a week building three utility APIs to solve them. All three have free tiers on RapidAPI.

1. JSON Repair & Formatter

LLMs don't always return clean JSON. Trailing commas, markdown code fences, truncated objects — all of these break JSON.parse() and crash your pipeline.

Input (broken LLM output):

{ "name": "Pro Plan", "price": 19.00, }

Output (clean JSON):

{ "name": "Pro Plan", "price": 19.00 }

Fast local repair engine first (<5ms, no AI call). Falls back to AI only when the input is too corrupted for local processing.

Free tier: 500 requests/month, no card required.
https://rapidapi.com/kordhubdev/api/kordhub-ai-json-repair-formatter

2. Discord Webhook Shield & Formatter

If you use Discord webhooks in a frontend app, your webhook URL is exposed in source code. Anyone can find it and spam your server.

You register your real webhook URL once — stored encrypted — and get a safe webhook_id instead. Your real URL never touches your frontend again. Auto-strips @everyone/@here spam before anything reaches Discord.

Free tier: 200 messages/month, no card required.
https://rapidapi.com/kordhubdev/api/kordhub-discord-webhook-shield-formatter

3. QR Code Generator

PNG & SVG output, custom hex colors, optional logo overlay. Error correction up to H (30%) keeps the QR scannable even with a logo on top. 100% local processing — no per-call AI cost.

Free tier: 500 requests/month, no card required.
https://rapidapi.com/kordhubdev/api/kordhub-qr-code-generator

Tech stack

FastAPI + Python, hosted on Render. Local engines use open-source libraries (json-repair, qrcode + Pillow) so cost per request is near zero. Groq only kicks in as AI fallback when local processing fails.

Would love feedback on pricing or use cases I missed.
Find me on X: @kordhub

DEV Community: David | Kordhub

3 FastAPI Services, 1 Process: The Bugs Nobody Warns You About published: false tags: fastapi, python, api, webdev

The setup

Bug #1: a package shadowing its own dependency

Bug #2: .env files stomping on each other

Bug #3: fail-fast code that fails the wrong thing

What actually mattered

Generating branded QR codes with logo overlay in Python (PNG + SVG)

The Problem

Why error correction matters for logo overlay

Generating a branded QR code

PNG vs SVG

Validate before generating

Try it free

How I protect Discord webhook URLs from being exposed in frontend code

The Problem

The Solution: Never expose the real URL

How it works in practice

Bonus: automatic spam filtering

Try it free

I built 3 free APIs for LLM developers — here's what I shipped and why

The Problem

1. JSON Repair & Formatter

2. Discord Webhook Shield & Formatter

3. QR Code Generator

Tech stack

Bug #2: `.env` files stomping on each other