Cloudflare Workers Free for Small APIs: Limits and Safety

A small API is often the first useful thing you can put on Cloudflare Workers. Maybe it returns a plain-language BIN note, a reviewed list of card-platform policies, or a bit of read-only data for an operations page. That is a reasonable use of the product. Treating a free edge runtime as a payment backend is not.

This guide is about low-risk APIs on the Workers Free plan. It is not a recipe for processing card payments or collecting card numbers. A service that touches full PANs, CVVs, identity documents, private keys, top-ups, or transaction instructions needs a different level of controls, contracts, and review.

Start with the limits, not the demo

Cloudflare's Workers pricing page, checked on August 19, 2026, says the Free plan includes 100,000 requests per day and 10 milliseconds of CPU time per invocation. The account-plan table in the official Workers limits documentation also lists 100,000 requests per day for Workers Free.

Those figures need a little translation. The request allowance is daily, not monthly. CPU time is the time spent executing your Worker code, not a license to run a long job because an upstream request is still waiting. A short JSON lookup may fit comfortably. Parsing several large responses, looping through a big dataset, doing expensive cryptography, and then calling an AI model is a different workload altogether.

That distinction matters because failures are boring to users. They do not care that a deployment was clever. They see a timeout or a 5xx page. Keep the request path small enough that you can explain it in one sentence.

What belongs in a small card-related API

Read-only, tightly scoped information is a good starting point. A route can return a human-reviewed note for a six- or eight-digit prefix, a public checklist for evaluating a card platform, or a mapping between an internal platform code and a documented support page. The API is providing information, not making a financial decision.

There is a useful design test: can the route return a sensible answer without querying several vendors in real time? If the answer is yes, you have a better chance of staying within a small execution budget and keeping the failure modes understandable. Keep common mappings in the Worker or in an approved data binding. Move slow verification and batch work to a purpose-built backend or queue.

Keep the response deliberately modest

{
  "prefix": "123456",
  "result": "Confirm details with the issuer and the authorization result.",
  "updatedAt": "2026-08-19"
}

That cautious wording is there for a reason. BIN data changes. A prefix cannot prove that a particular card belongs to someone, will work at a merchant, or is valid for a subscription. Our Chinese guide on using free BIN lookup tools safely goes into that boundary in more detail. The same rule should apply to an API response.

Build one route before building a platform

Begin with a Worker that does one thing: checks the method, accepts a short parameter, returns fixed JSON, and sends predictable cache and security headers. Call it repeatedly with curl before wiring it into a site. Bad input should not produce a stack trace. A response body should not suddenly turn into a page of HTML because an upstream service had a bad day.

One route also makes observability less theatrical. You can see which input breaks, how long the request took, and whether an error is yours or the provider's. Add a version such as /v1/bin/123456 only when you have a stable response shape. Versioning is less about looking mature than avoiding a quiet breakage when a field changes later.

Secrets stay on the server

The most ordinary leak is still one of the worst: a third-party token is pasted into Worker source, then the source is pushed to a repository or exposed through a client-side request. Cloudflare's official Secrets documentation says to store sensitive values as secrets and read them from the runtime environment. Do that from the first test deployment.

It also helps to separate public identifiers from credentials. A public project ID may be fine in a browser. A token that can spend money, read customer data, create cards, or change account settings is not. Your Worker can use such a token when the design requires it, but it must never return it to the client, write it to a log, or include it in an error message.

Logs deserve the same suspicion. Route, status, request ID, and duration are usually enough for debugging. Full authorization headers, personal data in query strings, and raw upstream payloads are not routine diagnostics. They are a future incident waiting for the wrong dashboard permission.

Rate limits, caching, and validation are one job

A daily allowance of 100,000 requests can disappear faster than it sounds. A copied script or a noisy crawler can burn through it in minutes. The Free plan is a good place to validate a real need; it is not a reason to accept unlimited traffic from every origin. Check the method, path, and parameter length. Rate-limit public routes by client where your architecture supports it. Require authentication for staff routes.

Caching is practical for stable information. A BIN explanation, public help copy, or a reviewed category list does not need a fresh computation every time. A sensible cache policy reduces executions and makes the response faster. But cached data must never become a shortcut for returning one user's balance, order, or card status to another user. That is not a performance bug. It is a data exposure.

Validate inputs with the same discipline. A BIN lookup should accept digits of a reasonable length. Platform codes should come from a whitelist. Unknown values should receive a clear 400 or 404. Do not fetch arbitrary URLs supplied by a visitor, and do not let arbitrary origins call an administrative route. Both shortcuts have a habit of turning into abuse paths.

A launch check that catches the obvious mistakes

• Confirm the route does not accept full card numbers, CVVs, seed phrases, or identity documents.
• Search the repository, browser bundle, and logs for tokens. Sensitive values should come from Secrets.
• Test a normal request, an empty request, an oversized parameter, and the wrong HTTP method.
• Check that cached responses contain no account-specific data.
• Record the date you checked the Workers documentation. Limits and pricing can change.

If the job is deploying a site to Workers rather than writing an API, see our earlier guide to enabling IndexNow for Astro on Cloudflare. The technical details differ, but the habit is the same: make the request path visible and testable before automating it.

FAQ

Can Workers Free process virtual-card top-ups directly?

It should not be treated as a shortcut around payment controls. A Worker may be part of a carefully designed gateway or status page, but top-ups and payments involve provider agreements, authorization, identity, fraud controls, and compliance obligations. Use the approved payment provider flow.

Is 100,000 requests per day enough?

For an internal tool or a well-cached public information route, possibly. For an unauthenticated API that scripts can call repeatedly, maybe not. Measure daily requests, errors, and cache behavior with real traffic before deciding whether to upgrade or split the service.

Does 10 ms of CPU mean the API only runs for 10 ms?

Not as a simple wall-clock limit. It is a limit on CPU time used by the Worker. Keep the work short anyway, then check the current official limits for the exact products and plan you use.

The sensible boundary

Workers Free is a good home for a prototype with a few routes, short responses, constrained input, and no sensitive payment data. The interesting decision is not how quickly you can deploy it. It is what the route should never be allowed to see. Get that right first.