DEV Community: Rushi Patel

HTML to PDF with headless Chrome in Node.js, without Puppeteer

Rushi Patel — Tue, 10 Nov 2026 23:12:21 +0000

You can turn any HTML into a print-ready PDF with headless Chrome and about 60 lines of Node.js, no Puppeteer and no npm packages: start Chrome with a debugging port, open its WebSocket, and send two DevTools Protocol commands, Page.navigate and Page.printToPDF. Here is the whole script, the CSS that makes the page size right, and four things that go wrong.

We use exactly this on Triplli, our sister product for travel agencies, to make its free downloads: a blank and a filled itinerary format and a payment receipt format, each printed from the same HTML that the guide page shows. The document is drawn once, in HTML, and the PDF, the picture and the page can never disagree.

Why not Puppeteer

Puppeteer is fine, and it downloads its own copy of Chrome on install. For a build script that prints a handful of documents from a Chrome already on the machine, the Chrome DevTools Protocol (CDP) directly is smaller and has nothing to keep up to date. Node.js 22 has a global WebSocket, so there is no dependency at all.

Step 1: start Chrome with a debugging port

import { spawn } from "node:child_process";
import { mkdtempSync, rmSync } from "node:fs";
import { tmpdir } from "node:os";
import { join } from "node:path";

const CHROME = process.env.CHROME || "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome";
const port = 9222 + Math.floor(Math.random() * 500);
const profile = mkdtempSync(join(tmpdir(), "pdf-"));
const chrome = spawn(CHROME, [
  "--headless=new", "--disable-gpu", "--no-first-run",
  `--remote-debugging-port=${port}`, `--user-data-dir=${profile}`, "about:blank",
], { stdio: "ignore" });

A fresh --user-data-dir per run keeps your own Chrome profile out of it, and a random port lets two runs work side by side. On Linux the binary is usually google-chrome or chromium.

Step 2: find the page and connect

Chrome lists its open pages, each with a WebSocket URL, at /json/list. It takes a moment to start, so poll:

const sleep = (ms) => new Promise((r) => setTimeout(r, ms));
let target;
for (let i = 0; i < 50 && !target; i++) {
  try {
    const list = await (await fetch(`http://127.0.0.1:${port}/json/list`)).json();
    target = list.find((t) => t.type === "page");
  } catch { await sleep(200); }
}
if (!target) throw new Error("chrome did not start");

const ws = new WebSocket(target.webSocketDebuggerUrl);
await new Promise((r) => (ws.onopen = r));

let id = 0;
const pending = new Map();
ws.onmessage = (ev) => {
  const m = JSON.parse(ev.data);
  if (m.id && pending.has(m.id)) { pending.get(m.id)(m); pending.delete(m.id); }
};
const send = (method, params = {}) =>
  new Promise((r) => { const i = ++id; pending.set(i, r); ws.send(JSON.stringify({ id: i, method, params })); });
const evaluate = async (expression) =>
  (await send("Runtime.evaluate", { expression, returnByValue: true, awaitPromise: true })).result.result.value;

Every CDP command is a JSON message with an id; the reply carries the same id. That small send is the whole client.

Step 3: open the page and wait for fonts

await send("Page.enable");
await send("Emulation.setDeviceMetricsOverride", { width: 860, height: 1400, deviceScaleFactor: 1.5, mobile: false });
await send("Page.navigate", { url: "http://localhost:4323/guides/itinerary-format/" });
await sleep(1500);
await evaluate("document.fonts.ready.then(() => true)");

Emulation.setDeviceMetricsOverride sets the layout width the PDF is printed from. Use it rather than --window-size: headless Chrome's window will not go below about 500 pixels wide, which matters when you also screenshot phone layouts.

Step 4: keep only the document

The guide page has a header, a footer and the article around the document. For the PDF we want the document alone, with its styles:

await evaluate(`(() => {
  const el = document.querySelector("#it-sample");
  const s = document.createElement("style");
  s.textContent = "@page { size: A4; margin: 12mm } html, body { background: #fff; margin: 0 }";
  document.head.append(s);
  document.body.replaceChildren(el);
  return true;
})()`);

replaceChildren moves the element into an otherwise empty body. The page's stylesheets stay in <head>, so it looks exactly as it did on the page. A blank version of the same document can sit on the page hidden (display: none) and be printed the same way after setting el.style.display = "block".

Step 5: print

import { writeFileSync } from "node:fs";

const r = await send("Page.printToPDF", { preferCSSPageSize: true, printBackground: true });
writeFileSync("itinerary-format.pdf", Buffer.from(r.result.data, "base64"));

Two options do most of the work:

Option	What it does	Without it
`preferCSSPageSize: true`	Uses `@page { size: A4 }` from your CSS	US Letter, 8.5 by 11 inches
`printBackground: true`	Prints background colours and shading	Table headers and boxes print white

To keep a block of the document from splitting across two pages, give it break-inside: avoid in CSS. Chrome honours it in printToPDF.

Step 6: a picture of it, for image search

The same session can screenshot the element, cropped to its size, even when it is taller than the viewport:

const rect = await evaluate(`(() => {
  const r = document.body.firstElementChild.getBoundingClientRect();
  return { x: r.x, y: r.y + scrollY, width: r.width, height: r.height };
})()`);
const shot = await send("Page.captureScreenshot", {
  format: "png", captureBeyondViewport: true, clip: { ...rect, scale: 1 },
});
writeFileSync("itinerary-format.png", Buffer.from(shot.result.data, "base64"));

On Triplli the filled itinerary picture sits beside the page heading with ImageObject markup, so the format can show up in image results as well as web results.

Four things that go wrong

Fonts print as the fallback. The PDF was printed before the web font arrived. Wait on document.fonts.ready first.
Everything prints on Letter. @page { size: A4 } does nothing until preferCSSPageSize is true.
Animated content stays hidden. Headless Chrome reports prefers-reduced-motion, and elements that fade in on scroll may stay at opacity 0. Force them visible in the injected style, or call Emulation.setEmulatedMedia with prefers-reduced-motion: no-preference.
Cleanup crashes after a good run. This one bit us: deleting the temporary profile on exit failed with ENOTEMPTY, because Chrome was still writing to it while being killed. All the files were made; wrap the cleanup in try { rmSync(profile, { recursive: true, force: true }) } catch {}.

Closing

ws.close();
chrome.kill();
try { rmSync(profile, { recursive: true, force: true }); } catch {}

That is the whole printer. The same approach makes Cabaro's duty slip for taxi operators, another sister product, in blank and filled form. For documents a server makes on demand, for every customer, a PDF library in the app is usually the better fit; for a build step that prints a few files from HTML you already have, headless Chrome and CDP are hard to beat.

First published on signops.dev. Written with AI assistance and checked against the script it describes.

Cloudflare D1 free tier limits: what counts as a row written

Rushi Patel — Fri, 06 Nov 2026 20:30:15 +0000

Cloudflare D1's free tier allows 100,000 rows written and 5 million rows read a day, counted across every database on the account, and resets at 00:00 UTC. When you go over, every query on every D1 database in the account fails until the reset. We found that out by taking three products down with one load test. Here is what the limits are, what counts as a row, and how to stay under them.

The limits on Workers Free

Limit	Workers Free	Workers Paid
Rows read	5 million a day	25 billion a month included
Rows written	100,000 a day	50 million a month included
Storage	5 GB for the account	5 GB included, up to 1 TB
Database size	500 MB	10 GB
Databases	10	100,000 included
Queries per Worker invocation	50	1,000

From Cloudflare's D1 pricing and limits pages, checked on 6 November 2026. Workers Paid is 5 US dollars a month. A db.batch() call counts as one query toward the per-invocation limit, but every row inside it still counts toward reads and writes.

What counts as a row written

This is where the 100,000 goes faster than you expect.

Every inserted, updated or deleted row counts. Inserting 10 rows is 10.
Every index the write touches adds a row. A table with two indexes on the columns you insert costs three rows per insert.
Deletes count. Cleaning up after a test costs as much as the test did, and a retention job that deletes old rows every night spends writes every night.
Schema changes (CREATE, ALTER, DROP) can count as reads and writes.

So one logical event is usually several rows. An email OTP in SignOps is about 8 over its life: the code row and its index, a daily counter, the check, then the deletion when it expires. At 8 rows each, 100,000 writes is about 12,000 codes a day, before anything else on the account writes a row.

What happened to us

We run three products on one Cloudflare account: SignOps, Triplli, quotation software for travel agencies in India, and Cabaro, taxi booking software for cab operators. Each has its own D1 database. On the free plan they share one daily allowance.

On 20 October 2026 we load tested SignOps push on production: 26,000 imported device tokens, three sends to 25,000 devices, then deleting the test devices. Each failed send wrote a row per device, and the cleanup wrote the same again. The account went past 100,000 rows written, and from then until 00:00 UTC, every write failed on all three products, including a travel agency quoting live customers in Triplli. Reads kept working, so pages loaded and every save failed.

The only fix that day was to wait.

How to stay under the limit

Work out the row cost before a test. Rows written times (1 + indexes touched), plus the cleanup. 26,000 devices with two indexes is 78,000 rows to insert and 78,000 to delete: over the daily limit before a single send.

Run volume tests locally. wrangler dev with a local D1 (wrangler d1 migrations apply DB --local) has no daily limit. Keep production tests to a few hundred rows.

Store counts, not events. We replaced one row per failed device with one row per message, platform and reason, holding a count. A 25,000-device send with every token failing now writes a handful of rows instead of 25,000.

Cap per customer, per day. If customers' usage writes rows, give each organisation a daily ceiling well under the account's allowance, so one busy customer cannot use it all.

Give each product its own account. The limit is per account. A second free Cloudflare account gives a second product its own 100,000 writes, and a spike in one cannot reach the other. It costs nothing but a login.

Or pay 5 dollars. Workers Paid includes 50 million rows written a month, about 1.6 million a day, and lifts the daily cutoff within minutes of upgrading.

Checking how close you are

The Cloudflare dashboard shows rows read and written per database under Storage and Databases, D1, Metrics. For the account total, add up every database, or query the GraphQL Analytics API's d1AnalyticsAdaptiveGroups dataset for rowsWritten grouped by day. Check it after any change that adds a table, an index or a scheduled job.

First published on the SignOps blog.

iOS silent push not working: content-available and background pushes

Rushi Patel — Thu, 05 Nov 2026 15:51:17 +0000

A silent push, which Apple calls a background notification, has no alert, sound or badge. It wakes your app so it can fetch new content. Apple treats it as low priority and does not guarantee delivery, so "it worked once and then stopped" is often the system working as designed. This page goes through what must be right on the sender and in the app, and what the device itself decides.

Symptom to cause

What you see	Likely cause	Fix
Never arrives, alert pushes work	Remote notifications background mode not ticked	Signing and Capabilities > Background Modes > Remote notification
Shows a banner instead of waking the app quietly	`alert`, `sound` or `badge` in `aps` next to `content-available`	Send `aps` with `content-available: 1` and nothing else
APNs returns `400`	`apns-priority: 10` with `apns-push-type: background`	Priority `5` for background pushes, always
Delivered late, or in bursts	Priority 5 pushes are sent according to the device's power state	Expected; use an alert push for anything a person waits for
Arrives in testing, then stops	Throttled: too many background pushes	Two or three an hour at most
Nothing after the user swiped the app away	The app was force quit	Nothing to fix; it wakes again once the user opens it
Only the last of several arrives	The device holds only the newest background push	Fetch everything new on each wake, not one item per push
Nothing on some phones	Background App Refresh off, or the phone saving power	Sync when the app comes to the foreground too

The payload

The aps dictionary must contain only content-available. Your own keys go beside aps, not inside it:

{
  "aps": { "content-available": 1 },
  "kind": "inbox",
  "since": "1762300800"
}

Any key that would make the device show something (alert, sound, badge) turns it into a visible notification, which iOS handles differently. Keep the whole payload under 4 KB.

The headers

curl -v --http2 \
  -H "authorization: bearer $JWT" \
  -H "apns-topic: com.example.app" \
  -H "apns-push-type: background" \
  -H "apns-priority: 5" \
  -d '{"aps":{"content-available":1},"kind":"inbox"}' \
  https://api.sandbox.push.apple.com/3/device/$TOKEN

apns-push-type: background. Required on watchOS, recommended everywhere else. Apple says that if the header does not match the payload, APNs may return an error, delay the push or drop it.
apns-priority: 5. Apple: "Always use priority 5. Using priority 10 is an error." Priority 5 means APNs delivers based on the device's power, so the push can be grouped with others and arrive in a burst.
apns-topic is the bundle ID with nothing added.
A sandbox token only works against api.sandbox.push.apple.com. If the curl above fails, see send a test push with curl and APNs error codes.

Through FCM, the same three things go in the apns block of the HTTP v1 message, and the message has no notification block:

{
  "message": {
    "token": "FCM_TOKEN",
    "data": { "kind": "inbox" },
    "apns": {
      "headers": { "apns-push-type": "background", "apns-priority": "5" },
      "payload": { "aps": { "content-available": 1 } }
    }
  }
}

The app

Background mode. In Signing and Capabilities, add Background Modes and tick Remote notifications. Without it, iOS does not wake the app for a background push.
Register. Call registerForRemoteNotifications() on every launch. A background push does not need notification permission, but it does need a device token.
Handle it in the right method. On iOS the system calls application(_:didReceiveRemoteNotification:fetchCompletionHandler:). Your app has up to 30 seconds, and must call the completion handler or it is terminated.

func application(_ application: UIApplication,
                 didReceiveRemoteNotification userInfo: [AnyHashable: Any]) async -> UIBackgroundFetchResult {
    do {
        let changed = try await Inbox.shared.syncFromServer()
        return changed ? .newData : .noData
    } catch {
        return .failed
    }
}

In SwiftUI apps this lives in a class you attach with @UIApplicationDelegateAdaptor. Apple also notes that apps which use a lot of power handling remote notifications "may not always be woken up early" for later ones, so do the fetch and return.

What the device decides

These are not bugs, and no header changes them:

Throttling. Apple: the system may throttle background notifications "if the total number becomes excessive" and advises not sending "more than two or three per hour".
Only the newest is held. While a delivery is delayed, a new background push replaces the older one. If the app is launched, the held one is delivered at once.
Force quit. If the user force quits the app, the held push is discarded, and the system does not launch the app in the background again until the user opens it or restarts the device. Test by pressing Home or locking the phone, not by swiping the app away.
Settings and power. Apple's delivery metrics list the device's power state and a person disabling background refresh among the things that decide delivery.

So design for missed pushes: treat a background push as a hint to sync, and sync again whenever the app comes to the foreground.

Testing

Test on a real iPhone, from a build that is not attached to the Xcode debugger as well as one that is.
Watch the device in the Console app on a Mac (filter by your app's process) to see the push arrive and the app wake.
The Push Notifications Console at icloud.developer.apple.com sends test pushes and shows delivery metrics, including pushes APNs stored or discarded.

With SignOps

SignOps Push sends a background push when you give data and no title or body. For an iPhone it then sets apns-push-type: background, apns-priority: 5 and an aps dictionary with only content-available: 1, both when it sends to Apple directly and through FCM; your keys go beside aps. A silent push cannot carry buttons.

curl https://api.signops.dev/v1/push \
  -H "Authorization: Bearer $SIGNOPS_KEY" \
  -H "content-type: application/json" \
  -d '{"user_id":"usr_8f21c4","data":{"kind":"inbox"}}'

The app side is still yours: the background mode and the delegate method above. Setup is in the iOS push guide.

Frequently asked questions

Why is my iOS silent push not received?

The most common causes are a missing Remote notifications background mode, an aps dictionary with alert, sound or badge keys next to content-available, the wrong apns-push-type or apns-priority headers, an app the user force quit, Background App Refresh turned off, or Apple throttling because too many background pushes were sent.

What headers does a background push need?

apns-push-type set to background and apns-priority set to 5, with apns-topic set to the app's bundle ID. Apple says priority 10 with the background push type is an error.

How many silent pushes can I send to an iPhone?

Apple does not give a fixed number. Its documentation says the system may throttle background notifications if there are too many, and advises sending no more than two or three per hour.

Does a silent push wake an app the user force quit?

No. If the user force quits the app, the system discards the held background notification and does not launch the app again until the user opens it or restarts the device.

How long does my app have to handle a background push?

Up to 30 seconds. Call the completion handler of application(_:didReceiveRemoteNotification:fetchCompletionHandler:) as soon as you are done, or the app is terminated.

Sources: Apple: Pushing background updates to your App, Apple: Sending notification requests to APNs, Apple: application(_:didReceiveRemoteNotification:fetchCompletionHandler:), Apple: Viewing the status of push notifications, Firebase: FCM HTTP v1 message.

First published on signops.dev.

Email OTP vs SMS OTP: cost, delivery and security

Rushi Patel — Thu, 05 Nov 2026 03:41:14 +0000

Both send a short code the user types back. They differ on cost, setup, delivery and what an attacker needs to steal one.

Side by side

	SMS OTP	Email OTP
Cost each in India	About Rs 0.13 to Rs 0.25	A few paise to send; Rs 0.025 on SignOps
Setup	DLT entity, header and template registration	A verified sending domain (SPF, DKIM, DMARC)
Proves	The user has the phone number	The user has the inbox
Delivery	Usually seconds; can fail on weak signal or DND issues	Usually seconds; can land in spam if the domain is not set up
SIM swap risk	Yes	No
Phishing risk	Yes, users read codes out to callers	Yes
Works without a phone	No	Yes, on any device with email

When SMS is the right choice

You need to prove a phone number, for example for a delivery or payments app, or for KYC.
Your users may not use email much.

Even then, you usually need it once per user, at signup.

When email is the right choice

Logins for web apps and SaaS, where users already sign up with email.
You want to avoid DLT registration and template approval.
Cost matters at volume: 1 lakh logins a month cost about Rs 17,000 by SMS at Rs 0.17 and about Rs 2,500 by email at Rs 0.025. The OTP cost calculator works it out for your own numbers.

Better than both for returning users

Codes of either kind can be phished. For users who already signed in on a phone:

Push approval: the phone shows who is signing in and asks for a number match and Face ID. Nothing to read out.
Passkeys: a fingerprint or screen lock, and nothing to phish at all.

A sensible flow: SMS or email once at signup, then passkeys or push approval for logins, with email codes as the fallback. See passkeys vs OTP and SMS OTP cost in India.

FAQ

Is email OTP more secure than SMS OTP?

It avoids SIM swap and SMS interception, but anyone with access to the inbox can read it, and both can be phished. Neither is as strong as a passkey or a signed push approval.

Which is cheaper in India, email or SMS OTP?

Email. An SMS OTP costs about Rs 0.13 to Rs 0.25 from Indian providers and needs DLT registration; an email code costs a few paise to send, and Rs 0.025 on SignOps.

Do I need DLT for email OTP?

No. DLT applies to commercial SMS in India. Email codes need a verified sending domain instead.

First published on signops.dev.

WebAuthn errors: NotAllowedError, InvalidStateError and more

Rushi Patel — Mon, 02 Nov 2026 14:25:15 +0000

WebAuthn reports every failure as a DOMException with a name. The message text differs between Chrome, Safari and Firefox, so branch on err.name and log the message for yourself. This page lists each name the spec throws from navigator.credentials.create() (registering a passkey) and navigator.credentials.get() (signing in), what causes it in practice, and what to show the user.

try {
  const cred = await navigator.credentials.create({ publicKey: options });
} catch (err) {
  console.log(err.name, err.message); // "NotAllowedError", "The operation either timed out or was not allowed..."
}

Every WebAuthn error, at a glance

err.name	create()	get()	Usual cause	What to do
`NotAllowedError`	Yes	Yes	Cancelled, timed out, no matching credential, blocked by policy	Show "Try again" and a fallback sign-in. Do not count it as a failed attempt
`InvalidStateError`	Yes		A credential in `excludeCredentials` is already on this authenticator	Say the passkey is already set up
`SecurityError`	Yes	Yes	`rp.id` does not match the page's domain, or the page is not HTTPS	Fix `rp.id` or serve the page over HTTPS
`NotSupportedError`	Yes		None of the algorithms in `pubKeyCredParams` is supported	Include `-7` (ES256) and `-257` (RS256)
`ConstraintError`	Yes		`residentKey: "required"` or `userVerification: "required"` and no authenticator can do it	Use `"preferred"` unless you really need it
`AbortError`	Yes	Yes	Your `AbortSignal` was aborted	Expected when you cancel; ignore it
`TypeError`	Yes	Yes	Bad options: `user.id` empty or over 64 bytes, a challenge that is not a buffer	Fix the options your server sends

NotAllowedError

This is the one you will see most, and it covers several causes on purpose. The spec makes the browser answer the same way whether the user cancelled or no credential exists, so a page cannot probe which accounts have passkeys.

Causes, in the order you are likely to hit them:

The user cancelled the browser or system prompt, or pressed Escape.
The timeout ran out. timeout is in milliseconds and is a hint the browser may change. Five minutes (300000) is common.
No credential matched (sign-in). You sent an allowCredentials list and none of those ids is on any authenticator the browser can reach: the passkey was deleted, was made on another phone that is not synced, or was made for another rpId.
No user gesture. Safari in particular wants create() and get() called straight from a click handler. An await fetch() before the call can lose the gesture; fetch the options first, then call on the click.
A cross-origin iframe without permission. The iframe needs allow="publickey-credentials-create; publickey-credentials-get".

What to do: show a short message ("Sign-in was cancelled. Try again or use another way") and keep a fallback visible. Never lock an account over NotAllowedError.

InvalidStateError

Only on create(). Your server listed the user's existing credential ids in excludeCredentials, which is right, and the authenticator recognised one of them. The user already has a passkey for this account on this device or in this password manager.

} catch (err) {
  if (err.name === "InvalidStateError") return showMessage("You already have a passkey for this account on this device.");
  throw err;
}

Keep sending excludeCredentials. Without it the same phone would save two passkeys for one account and the user could not tell them apart.

SecurityError

The browser checks that rp.id (on create()) or rpId (on get()) is the page's own domain or a parent domain of it:

Page	rp.id	Result
`https://app.example.com`	`example.com`	Works
`https://app.example.com`	`app.example.com`	Works
`https://app.example.com`	`login.example.com`	SecurityError
`https://example.com`	`example.co`	SecurityError
`http://localhost:3000`	`localhost`	Works
`http://192.168.1.5:3000`	anything	SecurityError (IP address)
`http://staging.example.com`	`example.com`	Fails: not a secure context

Two things follow. Pick the parent domain as rp.id from the start if you have several subdomains, because passkeys made for app.example.com will never work on www.example.com. And test on a phone through an HTTPS tunnel or a real domain, not your laptop's IP. Different domains that must share passkeys need Related Origin Requests, a /.well-known/webauthn file listing them.

NotSupportedError and ConstraintError

NotSupportedError means the authenticator supports none of the algorithms you offered. Offer both:

pubKeyCredParams: [
  { type: "public-key", alg: -7 },   // ES256, every passkey provider
  { type: "public-key", alg: -257 }, // RS256, Windows Hello
],

ConstraintError means you demanded something no available authenticator can give: a discoverable credential (residentKey: "required") or user verification (userVerification: "required"), and the user only has, say, an old security key. "preferred" for both works with every passkey and still gives you a discoverable credential with verification on phones and laptops.

AbortError

Your own code aborted the request through the signal you passed. The usual case is passkey autofill: a conditional get() waits in the background, and when the user clicks a "Sign in with a passkey" button you abort it first, because only one WebAuthn request can run at a time. Catch AbortError and do nothing. See passkey autofill.

Errors from your server, not the browser

Some failures pass the browser and fail at verification. They are not DOMExceptions; your server library raises them:

Challenge mismatch. The challenge in clientDataJSON is not the one you stored, often because two tabs started a sign-in. Store one challenge per attempt and expire it in a few minutes.
Origin mismatch. clientDataJSON.origin is https://www.example.com and you expected https://example.com. List every origin your sign-in page is served from. In Android apps the origin is android:apk-key-hash:..., not your web domain.
rpIdHash mismatch. The credential was made for another rp.id.
Counter went backwards. Synced passkeys usually report a counter of 0. Accept 0; only treat a lower non-zero counter as suspect.

What SignOps does with these

SignOps Passkeys makes the options on its server: excludeCredentials from the user's existing passkeys, residentKey and userVerification set to "preferred", ES256 and RS256 offered, a fresh challenge per attempt, and the origin and rp.id checked against the domain and sign-in pages you list in the dashboard. Your page calls passkeys.register() or passkeys.signIn() from @signops/web and gets a token your server confirms. Setup: passkeys on your website, or test what your browser supports with the passkey checker.

Frequently asked questions

What does "NotAllowedError The operation either timed out or was not allowed" mean?

It is WebAuthn's catch-all. The user closed or cancelled the prompt, the timeout ran out, the page called the API without a user gesture inside a cross-origin iframe, a permissions policy blocked it, or, for a sign-in, none of the credentials in allowCredentials exist on any authenticator the browser can reach. The browser does not tell your page which, on purpose, so a site cannot learn whether a passkey exists.

Why does navigator.credentials.create() throw InvalidStateError?

The authenticator already holds a credential listed in excludeCredentials, so the user tried to register a second passkey for the same account on the same device or password manager. Treat it as "already set up" and show that, not as a failure.

What causes SecurityError "The relying party ID is not a registrable domain suffix of, nor equal to the current domain"?

The rp.id (or rpId) you passed is not the page's domain or a parent of it. A page on app.example.com can use example.com or app.example.com, never another domain. It also happens on an IP address or a non-HTTPS origin other than localhost.

Does WebAuthn work on localhost?

Yes. Browsers treat http://localhost as a secure context, so the API works there with rp.id set to localhost. Any other plain http origin fails, and so does an IP address such as 192.168.1.5.

What is the difference between NotAllowedError and AbortError?

AbortError comes from your own code, when the AbortSignal you passed is aborted, for example when you cancel a pending passkey autofill request to start a button sign-in. NotAllowedError comes from the user or the browser.

Sources: W3C: Web Authentication Level 3, create and get request exceptions, MDN: CredentialsContainer.create(), MDN: CredentialsContainer.get().

First published on signops.dev.

Passkeys vs OTP: what changes for your sign-in

Rushi Patel — Wed, 28 Oct 2026 03:36:23 +0000

An OTP proves you can read a code sent to you. A passkey proves you hold a key made for this one website, unlocked by your fingerprint or screen lock. That difference is why passkeys are replacing codes for sign-in.

How a passkey works

Registration. The phone or laptop makes a key pair for your domain. The private key stays on the device or in the user's password manager. Your server stores the public key.
Sign-in. Your server sends a random challenge. The device asks for the fingerprint or screen lock, signs the challenge with the private key, and your server checks the signature with the public key.

The browser only lets a passkey answer the domain it was made for. A look-alike phishing site gets nothing.

Passkeys vs OTP

	SMS or email OTP	Passkey
What the user does	Waits for a code, types it	One touch or glance
Can be phished	Yes	No
SIM swap risk	Yes for SMS	No
Cost per sign-in	Rs 0.025 to Rs 0.25	Nothing to send
Works offline	No	Yes, on the device
Needs a new device to be set up	No	Yes, once per device or synced account

Where OTP still fits

Proving a new email or phone number at signup.
Recovery when someone loses every device.
Users on old devices without passkey support.

So the usual design is passkeys for sign-in, email OTP for signup and recovery.

Adding passkeys

The browser API is WebAuthn (navigator.credentials.create and .get). The work is on your server: making challenges, storing credentials and checking every response correctly. A minimal flow:

// Browser, with SignOps: your server makes a registration token for the signed-in user,
// and the browser makes the passkey with it
import { passkeys } from "@signops/web";
await passkeys.register({ token: registrationToken });

// Later: sign in, with the passkey offered in the email field (autofill)
const { signops_token } = await passkeys.signIn({ autofill: true });
// your server confirms signops_token before starting a session

On Android, passkeys go through Credential Manager; on iOS through AuthenticationServices. Flutter and React Native packages wrap both. To see what a browser and device support, open the passkey support checker on it.

SignOps Passkeys runs the server side on your own domain, with 1,000 sign-ins a month free and 50,000 on Starter, and email OTP on the same account for recovery.

FAQ

Are passkeys better than OTP?

For sign-in, yes. A passkey only answers the website it was made for, so it cannot be phished, and there is no code to send, read or intercept. OTP is still useful to verify a new email or phone, and to recover an account when the passkey is lost.

Which phones support passkeys?

Android 9 and later, iOS 16 and later, and current Chrome, Safari, Edge and Firefox. Synced passkeys are backed up by Google Password Manager, iCloud Keychain or password managers such as 1Password.

Can I add passkeys to Flutter or React Native?

Yes. On Android they go through Credential Manager and on iOS through AuthenticationServices; Flutter and React Native packages wrap both, and your server must check the WebAuthn responses.

What happens if a user loses their phone?

Synced passkeys come back on the new phone through the same Google or Apple account. If not, let them in with an email code and ask them to make a new passkey.

First published on signops.dev.

Sources: passkeys.dev, Android: Credential Manager, W3C: Web Authentication.

Is Firebase push notification free? FCM pricing, quotas and rate limits

Rushi Patel — Wed, 28 Oct 2026 03:27:46 +0000

Yes, Firebase push notifications are free. Firebase lists Cloud Messaging (FCM) as "no-cost" on both its free Spark plan and its paid Blaze plan. Google charges nothing per message, and there is no monthly limit on how many you send. Apple's push service (APNs) is free to send through too. So why do OneSignal, Pusher and others charge? Because sending is free, and everything around sending is not.

What is free

	Cost
FCM messages to Android, iOS and web	Free, unlimited
APNs messages to iPhones	Free (needs the Apple Developer Program, which any iOS app has)
Web push through browsers' push services	Free
Topics and topic subscriptions on FCM	Free

FCM quotas and rate limits (HTTP v1)

Sending is free, but not unlimited in speed. These are Firebase's documented limits:

Limit	Value
Messages per project	600,000 a minute, counted per message, not per request
Over a quota	`429` with error code `QUOTA_EXCEEDED`, for the project, one device or a topic
Messages to one Android device	240 a minute and 5,000 an hour
Collapsible messages to one device	A burst of 20, then 1 every 3 minutes; extras are delayed, not dropped
Payload	4 KB per message

Client errors (400 to 499, except 429) count against the quota, so a list full of dead tokens uses it up faster. The minute is not aligned to the clock, so a retry at :00 can still fail. Firebase asks for exponential backoff starting at no less than 1 minute for messages rejected with 429.

Raising it: in Google Cloud Console, open Quotas and system limits for the Firebase Cloud Messaging API and edit Send requests per minute. Google considers up to 25% more once usage sits at 80% of the quota for at least 5 minutes a day with client errors under 5%. For a launch or a sale, ask Firebase Support for a temporary increase at least 15 days ahead (30 days above 18 million a minute), at most twice a year.

Other limits worth knowing:

Topics: fan-out to large topics is not instant; plan for minutes, not seconds, on very large sends.
No delivery guarantee: FCM accepting a message does not mean the phone showed it. See why FCM notifications are not received.

What is not free: the server around it

FCM delivers to a token. Everything else is yours to build and run:

A database of tokens per user, updated when a token changes, a user reinstalls or signs in on another phone.
Sending logic: one user to many devices, lists of users, topics, everyone.
Scheduling and time zones.
Cleanup: deleting tokens FCM reports as UNREGISTERED, or every send gets slower and every count wrong.
A screen for non-developers who write offers and reminders.
Delivery logs to answer "did my user get it".
Credentials: HTTP v1 needs a service account and short-lived tokens. See the FCM HTTP v1 migration.

That work is what paid push services sell.

What that costs to buy

Service	Free	Paid
FCM directly	Unlimited, you build the server	Your own servers and time
Expo push	Unlimited, Expo apps only	Free
OneSignal	Mobile push up to 1,000 users	$19 a month plus $0.012 a user
Pusher Beams	1,000 devices	$29 a month for 10,000
SignOps	1,000 devices	Rs 499 a month for 5,000, then Rs 0.20 a device

The short answer

If you have a backend and one app, FCM directly is free and fine. When you need users across devices, topics, scheduling, a composer for your team or delivery logs, you either build that server or pay for one. SignOps Push is that server, with your own Firebase and Apple keys, free for 1,000 devices.

FAQ

Is Firebase Cloud Messaging free?

Yes. Firebase lists Cloud Messaging as no-cost on both the free Spark plan and the pay-as-you-go Blaze plan. There is no charge per message and no monthly cap.

What is the FCM free limit?

There is no message limit. There is a rate quota of 600,000 messages a minute per Firebase project by default, which Google can raise for projects that need more.

What is the FCM HTTP v1 quota?

600,000 messages a minute per project, counted in messages, not requests. Past it the API answers 429 QUOTA_EXCEEDED; retry with backoff starting at 1 minute. One Android device takes up to 240 messages a minute and 5,000 an hour.

How do I raise the FCM quota?

In Google Cloud Console, under Quotas and system limits for the Firebase Cloud Messaging API, edit Send requests per minute. Google considers up to 25% more once you sit at 80% of the quota for 5 minutes a day with under 5% client errors. For a launch, ask Firebase Support at least 15 days ahead.

Do I pay for iOS pushes?

Apple charges nothing to send through APNs. You need the Apple Developer Program membership that every iOS app needs anyway.

Then why do push services charge?

For the server around FCM. Storing tokens per user, targeting topics, scheduling, retrying, removing dead tokens, a dashboard for non-developers and delivery logs are all work that FCM leaves to you.

First published on signops.dev.

Sources: Firebase pricing, Firebase: FCM throttling and quotas, FCM error codes.

Migrating from the FCM legacy API to HTTP v1

Rushi Patel — Wed, 21 Oct 2026 18:19:27 +0000

If your server still posts to https://fcm.googleapis.com/fcm/send with a server key, it has stopped delivering. Firebase deprecated the legacy HTTP and XMPP APIs on 20 June 2023 and began shutting them down on 22 July 2024. The replacement is the HTTP v1 API. Your app does not change. Your server does, in three places: how it authenticates, where it sends, and what the payload looks like.

What changes between legacy and v1

	Legacy API	HTTP v1
Endpoint	`POST /fcm/send`	`POST /v1/projects/PROJECT_ID/messages:send`
Authentication	`Authorization: key=SERVER_KEY`, never expires	`Authorization: Bearer ACCESS_TOKEN`, from a service account, lasts about an hour
Many devices	`registration_ids` with up to 1,000 tokens	One target per request: a token, a topic or a condition
Platform options	Mixed into one object	Separate `android`, `apns` and `webpush` blocks
Data values	Any JSON	Strings only

Step 1: get a service account key

In the Firebase console open Project settings, Service accounts and generate a new private key. Keep the JSON file out of your repo and your app. It is a password to every device of your project.

Step 2: turn the key into an access token

The token is an OAuth 2.0 bearer token with the scope https://www.googleapis.com/auth/firebase.messaging. Libraries fetch and refresh it for you.

// Node: npm install google-auth-library
import { GoogleAuth } from "google-auth-library";

const auth = new GoogleAuth({
  keyFile: "service-account.json",
  scopes: ["https://www.googleapis.com/auth/firebase.messaging"],
});
const token = await auth.getAccessToken();

Step 3: send with the v1 payload

curl -X POST \
  "https://fcm.googleapis.com/v1/projects/YOUR_PROJECT_ID/messages:send" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "message": {
      "token": "DEVICE_TOKEN",
      "notification": { "title": "Order shipped", "body": "Arriving today" },
      "data": { "order_id": "88213" },
      "android": { "priority": "high" },
      "apns": { "headers": { "apns-priority": "10" } }
    }
  }'

Two things trip people up here. Every value in data must be a string, so send "88213", not 88213. And priority moved into the android block.

The same in PHP

// composer require google/auth guzzlehttp/guzzle
use Google\Auth\Credentials\ServiceAccountCredentials;

$creds = new ServiceAccountCredentials(
    'https://www.googleapis.com/auth/firebase.messaging',
    json_decode(file_get_contents('service-account.json'), true)
);
$token = $creds->fetchAuthToken()['access_token'];

$client = new GuzzleHttp\Client();
$client->post("https://fcm.googleapis.com/v1/projects/{$projectId}/messages:send", [
    'headers' => ['Authorization' => "Bearer {$token}"],
    'json' => ['message' => [
        'token' => $deviceToken,
        'notification' => ['title' => 'Order shipped', 'body' => 'Arriving today'],
    ]],
]);

Step 4: replace registration_ids

HTTP v1 has no list of tokens. You have two choices:

One request per token. The Firebase Admin SDK does this in parallel with sendEach and sendEachForMulticast. The older sendAll and sendMulticast used a batch endpoint that was retired with the legacy API.
Topics. Subscribe devices to a topic once and send one message to "topic": "offers". FCM fans it out.

// npm install firebase-admin
import { initializeApp, cert } from "firebase-admin/app";
import { getMessaging } from "firebase-admin/messaging";

initializeApp({ credential: cert("service-account.json") });

const res = await getMessaging().sendEachForMulticast({
  tokens: deviceTokens, // up to 500 per call
  notification: { title: "Order shipped", body: "Arriving today" },
});
console.log(res.successCount, "sent,", res.failureCount, "failed");

Step 5: handle the new errors

v1 errors are clearer than legacy ones. The two you will see most:

UNREGISTERED (404): the token is dead, usually because the app was uninstalled. Delete it from your database.
INVALID_ARGUMENT (400): a malformed token or payload. A number inside data is the usual cause.

Keep the cleanup automatic. A list of dead tokens slows every send and inflates every count.

If you would rather not run this

All of the above is what SignOps Push does: it holds your service account and APNs key, sends through HTTP v1 to every device a user has, removes dead tokens and tells your server by webhook. You call one endpoint with your own user id. It is free for 1,000 devices.

Sources: Firebase: migrate from legacy FCM APIs to HTTP v1, Firebase: FCM throttling and quotas.