DEV Community: Jonas Hämmerle

Looking up a historical exchange rate correctly (and why 'the rate on that date' is fuzzier than it sounds)

Jonas Hämmerle — Sat, 29 Aug 2026 14:37:05 +0000

A common ask in invoicing/reconciliation code: "what was the USD/EUR rate on 2024-01-15?" The naive approach — pick a rate source, hit it with a date, trust the number — glosses over one detail that matters: ECB reference rates only publish on business days, so "the rate on" a weekend or bank-holiday date doesn't exist as a distinct value.

The honest way to handle this is to resolve the requested date to the nearest actual trading date and say so in the response, rather than silently picking one:

async function getHistoricalRate(date, from, to) {
  const res = await fetch(`https://currency-api.p.rapidapi.com/v1/historical?date=${date}&from=${from}&to=${to}`, {
    headers: { "X-RapidAPI-Key": key, "X-RapidAPI-Host": "currency-api.p.rapidapi.com" },
  });
  return res.json(); // { from, to, rate, date } — "date" is the resolved trading date, not necessarily the one you asked for
}

Two failure modes worth guarding against explicitly, not just the happy path: a future date (there's no "historical" rate for a date that hasn't happened) and a date before your data source's coverage starts (ECB/Frankfurter data begins 1999-01-04 — pre-Euro-era rates aren't there). Both should be a clean 400, not a confusing 502 or a silently wrong 200.

Currency API's new /v1/historical endpoint does exactly this: validates the date up front (rejects future/out-of-range/malformed dates with a 400), resolves weekend/holiday dates to the prior business day, and returns which date it actually used — same "fail honestly, don't fabricate" principle as the rest of the API. Sibling APIs on the same account: Validate and QR API.

Branded QR codes without a design tool: setting foreground/background color via query params

Jonas Hämmerle — Thu, 27 Aug 2026 19:52:52 +0000

The default black-on-white QR code works fine functionally, but it clashes with pretty much every brand style guide the moment you drop it into a poster, product package, or app screen. Most "just generate a QR code" APIs don't expose color at all, which pushes color-matching into a separate image-editing step after the fact — recoloring an SVG's fill by hand, or worse, round-tripping through a design tool for something that should be a one-line request.

QR API takes color (module/foreground) and bgColor (background) as plain hex query params on GET /v1/qr, no leading #:

curl "https://qr-api.p.rapidapi.com/v1/qr?data=https://example.com&color=1a2b3c&bgColor=f4f1ea" \
  -H "X-RapidAPI-Key: <your-key>" \
  -H "X-RapidAPI-Host: qr-api.p.rapidapi.com" \
  --output qr.svg

Both default to black-on-white (000000/ffffff) if omitted, so existing integrations don't need to change anything to keep their current output.

Two things worth knowing if you're picking colors instead of just accepting the defaults:

Contrast still has to survive a camera, not just a screen. A QR decoder needs a clear light/dark distinction between modules and background — a pastel-on-pastel combination that looks fine in a design mockup can fail to scan reliably once printed or viewed under bad lighting. Keep real contrast between the two hex values, not just a stylistic difference.
Validate hex input server-side if you ever accept it from a user. These values get embedded directly into SVG fill attributes, so strict 3/6-digit hex validation isn't optional — it's the difference between a color param and a markup-injection vector.

Same /v1/qr/matrix raw-grid endpoint is unaffected by color params since it returns boolean modules, not rendered output — colors only apply to the SVG path. Sibling APIs on the same account: Validate and Currency API.

EU VAT number validation: format check vs VIES lookup, and when you need which

Jonas Hämmerle — Tue, 25 Aug 2026 09:49:58 +0000

If you sell B2B in the EU, you'll eventually need to validate a customer's VAT number. There are two very different levels of "validation" here and it's worth knowing which one you actually need:

Format validation — does the string match the country's VAT number pattern (length, structure)? This catches typos instantly, works offline, and is free forever.

VIES lookup — is this VAT number actually registered with that EU country's tax authority right now? This requires a live call to the European Commission's VIES service, can be slow (VIES has outages more often than you'd like), and is the only way to know if the number is real vs just correctly-formatted.

For most signup flows, format validation is enough to catch mistakes, with an optional VIES check before you actually apply a reverse-charge VAT exemption (since that's the part with tax liability implications).

POST /v1/validate/vat
{ "countryCode": "IE", "vatNumber": "6388047V", "checkExistence": true }

That's the shape I settled on for Validate — format check always runs, VIES lookup is opt-in per request so you're not waiting on a flaky government API when you don't need to. Sibling APIs on the same account: QR API and Currency API.

ISO 4217 currency codes: the edge cases that break naive multi-currency forms

Jonas Hämmerle — Sat, 22 Aug 2026 09:50:32 +0000

Most currency handling code assumes every currency has 2 decimal places and a straightforward numeric amount. Neither assumption holds universally, and both break in ways that are easy to miss until a real transaction hits the edge case.

Not every currency has 2 minor units. JPY has zero — ¥100 is a whole number, there's no ¥100.00. KWD (Kuwaiti Dinar) has three. If your form/database column hardcodes 2 decimal places "because that's how currency works," you'll either round JPY amounts into nonsense or truncate KWD precision.

const MINOR_UNITS = { JPY: 0, KWD: 3 /* ... */ }; // default 2 for anything not listed
function formatAmount(amount, code) {
  const digits = MINOR_UNITS[code] ?? 2;
  return amount.toFixed(digits);
}

Currency codes aren't a stable, closed set forever — they get added, and in rare cases retired (old Eurozone currencies like DEM, FRF were withdrawn when the Euro launched). A hardcoded currency list baked into your app years ago can silently drift from reality. Pull the supported-currency list from a source that's actually kept current, rather than a list you typed once.

Symbol collisions are a UI bug waiting to happen. $ alone is ambiguous across USD, CAD, AUD, and several others — showing just the symbol without the ISO code next to it (or as a tooltip) is a real source of "wait, is that dollars or my dollars" confusion in any multi-currency UI.

Currency API's /v1/currencies endpoint always reflects the actual current supported set (ECB scope, ~30 major currencies) rather than a list that can go stale — check it instead of hardcoding one, especially if you're validating currency-code input from a form. Sibling API QR API is useful if that same form flow ever needs a QR code for a payment link, and Validate covers the rest of the form's IBAN/email/phone checks.

Branded QR codes without a design tool: setting foreground/background color via query params

Jonas Hämmerle — Thu, 20 Aug 2026 09:53:08 +0000

QR API takes color (module/foreground) and bgColor (background) as plain hex query params on GET /v1/qr, no leading #:

curl "https://qr-api.p.rapidapi.com/v1/qr?data=https://example.com&color=1a2b3c&bgColor=f4f1ea" \
  -H "X-RapidAPI-Key: <your-key>" \
  -H "X-RapidAPI-Host: qr-api.p.rapidapi.com" \
  --output qr.svg

Both default to black-on-white (000000/ffffff) if omitted, so existing integrations don't need to change anything to keep their current output.

Two things worth knowing if you're picking colors instead of just accepting the defaults:

Contrast still has to survive a camera, not just a screen. A QR decoder needs a clear light/dark distinction between modules and background — a pastel-on-pastel combination that looks fine in a design mockup can fail to scan reliably once printed or viewed under bad lighting. Keep real contrast between the two hex values, not just a stylistic difference.
Validate hex input server-side if you ever accept it from a user. These values get embedded directly into SVG fill attributes, so strict 3/6-digit hex validation isn't optional — it's the difference between a color param and a markup-injection vector.

Phone number validation is harder than you think (a libphonenumber crash course)

Jonas Hämmerle — Tue, 18 Aug 2026 09:47:17 +0000

A regex will not validate phone numbers correctly. I promise. Numbering plans vary by country, mobile vs landline prefixes differ, and some countries have variable-length numbers. Google's libphonenumber (the library that powers Android's dialer) is the only sane way to do this client- or server-side.

import parsePhoneNumberFromString from "libphonenumber-js";

const parsed = parsePhoneNumberFromString("+49 170 1234567");
console.log(parsed.isValid());          // true
console.log(parsed.country);            // "DE"
console.log(parsed.formatInternational()); // "+49 170 1234567"

Two gotchas that catch people out: numbers without a country code need a defaultCountry hint or parsing will silently fail, and "valid" only means "matches the numbering plan" — it says nothing about whether the number is currently assigned to someone.

For a stateless HTTP version of this (useful if your stack isn't JS, or you don't want the dependency), I built it as one of the endpoints on Validate — same libphonenumber-js under the hood, just over JSON. Same account also covers QR API and Currency API.

Looking up a historical exchange rate correctly (and why 'the rate on that date' is fuzzier than it sounds)

Jonas Hämmerle — Sat, 15 Aug 2026 09:49:40 +0000

The honest way to handle this is to resolve the requested date to the nearest actual trading date and say so in the response, rather than silently picking one:

async function getHistoricalRate(date, from, to) {
  const res = await fetch(`https://currency-api.p.rapidapi.com/v1/historical?date=${date}&from=${from}&to=${to}`, {
    headers: { "X-RapidAPI-Key": key, "X-RapidAPI-Host": "currency-api.p.rapidapi.com" },
  });
  return res.json(); // { from, to, rate, date } — "date" is the resolved trading date, not necessarily the one you asked for
}

Batch-generating QR codes for events, inventory, or ticketing without hammering an API

Jonas Hämmerle — Thu, 13 Aug 2026 10:31:12 +0000

Generating one QR code per attendee badge, warehouse bin, or ticket sounds like a simple loop until you're doing it for a few thousand items and either your own rate limiter or the API's kicks in halfway through a batch job.

A few things that make batch QR generation less painful:

Concurrency, not sequential loops. A single QR code generation call is fast (no external network dependency if the service computes the matrix in-process rather than calling out to render it), so the bottleneck is almost always your own request-issuing pattern, not the API. A small worker pool (5-10 concurrent requests) clears a few thousand codes in well under a minute instead of one-at-a-time sequential awaiting.

async function generateBatch(items, concurrency = 8) {
  const results = [];
  for (let i = 0; i < items.length; i += concurrency) {
    const batch = items.slice(i, i + concurrency);
    const responses = await Promise.all(
      batch.map((item) =>
        fetch(`https://qr-api.p.rapidapi.com/v1/qr?data=${encodeURIComponent(item.url)}`, {
          headers: { "X-RapidAPI-Key": process.env.RAPIDAPI_KEY, "X-RapidAPI-Host": "qr-api.p.rapidapi.com" },
        }).then((r) => r.text())
      )
    );
    results.push(...responses);
  }
  return results;
}

Respect the tier's rate limit rather than discovering it via 429s. If you know you're generating a few thousand codes in one job, check your plan's requests-per-month ceiling ahead of time rather than mid-batch — free tiers are usually sized for "generate codes as users request them," not "bulk-generate an entire event's worth in one run."

Cache the output if the input doesn't change. A QR code for a fixed URL/payload is deterministic — regenerating the same code repeatedly across job re-runs (a common failure mode when a batch job is re-triggered after a partial failure) wastes calls for zero benefit. Key your cache on the exact data+ecc+size params.

Stateless generation (no per-request server state, no database) is what makes this kind of batch job cheap to run in the first place — that's the whole design of QR API: every call is a pure function of its query params, nothing persisted, nothing logged beyond the request path. Same account also runs Validate (IBAN/email/phone/etc. format checks) and Currency API (exchange rates) if useful for the rest of an onboarding/checkout pipeline.

Stop rolling your own password breach checker — here's how k-anonymity makes it safe

Jonas Hämmerle — Tue, 11 Aug 2026 10:09:20 +0000

If you're checking user passwords against HaveIBeenPwned's breach database, please don't send the full password (or even the full hash) over the wire. Here's why, and the actual protocol that fixes it.

HIBP's Pwned Passwords API uses k-anonymity: you SHA-1 hash the password locally, send only the first 5 characters of the hash, and the API returns every suffix that starts with that prefix (usually 300-900 of them). You compare locally. The full password never leaves your server, and HIBP never sees enough to reconstruct it.

import { createHash } from "node:crypto";

async function isBreached(password) {
  const hash = createHash("sha1").update(password).digest("hex").toUpperCase();
  const prefix = hash.slice(0, 5);
  const suffix = hash.slice(5);
  const res = await fetch(`https://api.pwnedpasswords.com/range/${prefix}`);
  const text = await res.text();
  return text.split("\n").some(line => line.startsWith(suffix));
}

That's genuinely all it takes — no library needed. I wrapped this (plus password strength scoring) into an endpoint on Validate if you'd rather not maintain the hashing/comparison logic yourself, but honestly, the snippet above will get most people there. Sibling APIs on the same account: QR API and Currency API.

ISO 4217 currency codes: the edge cases that break naive multi-currency forms

Jonas Hämmerle — Sat, 08 Aug 2026 10:02:11 +0000

const MINOR_UNITS = { JPY: 0, KWD: 3 /* ... */ }; // default 2 for anything not listed
function formatAmount(amount, code) {
  const digits = MINOR_UNITS[code] ?? 2;
  return amount.toFixed(digits);
}

The IBAN mod-97 checksum, explained (and how to validate one in one line)

Jonas Hämmerle — Tue, 04 Aug 2026 16:28:32 +0000

Ever wondered how your bank instantly knows you fat-fingered an IBAN before it even checks if the account exists? It's a checksum: ISO 13616's mod-97 algorithm.

Here's the short version: move the first four characters to the end, convert letters to numbers (A=10, B=11...), then check if the resulting number mod 97 equals 1. That's it — no database lookup needed to catch most typos.

// simplified version of the check
function ibanChecksumValid(iban) {
  const rearranged = iban.slice(4) + iban.slice(0, 4);
  const numeric = rearranged.replace(/[A-Z]/g, c => c.charCodeAt(0) - 55);
  let remainder = 0;
  for (const digit of numeric) remainder = (remainder * 10 + Number(digit)) % 97;
  return remainder === 1;
}

Fine for a side project. Once you're validating IBANs from real users, you also want country-specific length checks, BBAN structure validation, and ideally a formatted, human-readable output — which is more code than you want to own for something this boilerplate.

If you'd rather not maintain that: Validate is a small API I built that handles this (plus VAT/email/phone/credit-card format checks) as a single JSON call. Free tier is 100 requests/month, no card required. Same account also runs QR API (QR code generation) and Currency API (exchange rates) if useful.

Caching exchange rates correctly: per-day TTL, not per-request memoization

Jonas Hämmerle — Sat, 01 Aug 2026 12:41:30 +0000

If you're converting to several currencies at once — a pricing page showing a product in 8 currencies, say — the naive approach is one /convert call per currency pair. That works, but it's leaving an easy optimization on the table: ECB-sourced rates update once per business day, so there's no reason to be making fresh network calls more often than that.

The right cache key isn't "this specific conversion," it's "the rate table for this base currency, as of today's date":

const rateCache = new Map(); // key: `${base}:${isoDate}`

async function getRatesForDay(base) {
  const today = new Date().toISOString().slice(0, 10);
  const key = `${base}:${today}`;
  if (rateCache.has(key)) return rateCache.get(key);

  const res = await fetch(`https://currency-api.p.rapidapi.com/v1/rates?base=${base}`, {
    headers: { "X-RapidAPI-Key": key_env, "X-RapidAPI-Host": "currency-api.p.rapidapi.com" },
  });
  const data = await res.json();
  rateCache.set(key, data);
  return data;
}

One call per base currency per day gets you every target currency's rate in that response — /v1/rates returns the full table, not just one pair — so converting to 8 currencies from a cached table is 8 in-memory lookups, not 8 network round-trips.

Two things worth being careful about: cache the date the rate was published, not the date you fetched it (a request right after midnight UTC might still be serving yesterday's ECB publish if today's hasn't landed yet), and don't cache across a process restart without also persisting the date key — a stale in-memory cache that outlives its day is exactly the silent-wrong-number problem you're trying to avoid.

Currency API's /v1/rates endpoint is built for this pattern — pull the whole table once, cache it client-side for the day, and reserve /v1/convert for one-off single conversions where pulling the whole table would be overkill. Sibling APIs on the same account: Validate and QR API.