Open Sam Newman’s original 2015 pattern write-up on Backends For Frontends and read only the table of contents. The entry reads “The General-Purpose API Gateway.” Follow that link, and the heading you land on — same page, same anchor, id="general" — reads “The General-Purpose API Backend.” That isn’t a stale link somebody forgot to fix. It is still there, byte for byte, in the raw HTML of the single most-cited BFF origin document, in 2026.
If you have ever tried to settle a BFF vs API gateway argument in a design review and watched the two terms slide into each other no matter how carefully everyone defined their position, this is why. The conflation isn’t a failure to read the source carefully. It is sitting inside the source.
This article does three things a “here’s the difference” explainer usually skips: it grounds the distinction in what the original pattern was actually built to solve — team autonomy and per-client aggregation, with no security motive anywhere in it — shows exactly where the canonical write-up contradicts itself about what to call the thing it’s describing, and then shows where the 2026 security definition (RFC 10017, the IETF’s OAuth Best Current Practice for browser apps) walks away from both older meanings entirely.
The Document Everyone Cites Doesn’t Agree With Itself
Newman’s post, “Pattern: Backends For Frontends” (samnewman.io/patterns/architectural/bff/, dated on the page Nov 18 2015), is the write-up most later explainers trace back to. Its own navigation and its own prose disagree about the name of one specific thing: the shared, do-everything API that BFF is a reaction against.
The table of contents links to an anchor called #general with the label “The General-Purpose API Gateway.” Click through, and the <h3 id="general"> heading two lines into the section reads “The General-Purpose API Backend.” Newman uses “Gateway” to point at the section in his own navigation, then uses “Backend” to name the same section in his own prose. This is not a copy-editing slip that got fixed in a later revision — it is present in the live page today, and it means the single document everyone cites as the origin of “BFF vs API gateway” cannot itself keep the two terms apart for the length of one hyperlink.
Chris Richardson’s microservices.io — an independently maintained pattern catalogue, footer copyright currently reading 2026 — resolves the ambiguity a different way: not by picking a side, but by making BFF a variant of API Gateway rather than a rival to it. Its own page for the pattern is titled, plainly, “Pattern: API Gateway / Backends for Frontends” — one catalogue entry, not two — and states the relationship in its own “Variation” section:
“A variation of this pattern is the Backends for frontends pattern. It defines a separate API gateway for each kind of client.”
That same section even reproduces the same counting mistake this hub keeps running into elsewhere, in miniature — describing three separate per-client gateways, it states: “There are three different API gateways. Each one is provides an API for its client.” [sic — the grammatical slip is in the source, quoted exactly rather than silently tidied]. A named-pattern reference site, describing the pattern most precisely of the three sources checked for this article, still can’t get through one sentence about it without a typo. None of this is a knock on either author. It is evidence that the boundary between these two names is genuinely hard to hold onto in prose, not just in casual conversation.
What SoundCloud Was Actually Solving, Before Security Entered the Room
The pattern’s own origin, per Phil Calçado’s account of building it at SoundCloud (dated Sep 18, 2015), had nothing to do with gateways, security, or routing topology as a goal in itself. It was an organizational fix:
“Our first proposed solution would be to have different APIs for mobile and web. The idea was that having the team working on the client own the API would allow for them to move much quicker as it required no coordination between parts.”
That is the whole justification: whichever team owns a user experience should own the backend that serves it, so releasing a change doesn’t require a second team’s calendar to line up with the first. Calçado is explicit that this reshaped what the thing was, not just who ran it. His team stopped treating their per-client backend as an API their app happened to call, and started treating it as a piece of the application itself:
“The BFF was part of the application.”
Neither Calçado’s post nor Newman’s mentions security, tokens, cookies, or XSS as a reason for the pattern to exist — a claim easy to overstate, so it’s worth being precise: I searched both posts directly and found zero occurrences of any of those words as part of the problem statement in either one. The defining question the pattern answers, in both founding accounts, is which team owns this code and how many kinds of client it serves — not which protocol role it plays. Keep that axis in mind; it’s the one that survives into the comparison below, and it’s the one the 2026 security definition drops entirely.
An API Gateway, Defined Without Reference to Any BFF
It’s worth stating what “API gateway” means on its own terms, independent of the BFF conversation, because the generic pattern predates and is broader than the per-client variant. Richardson’s page states the core idea plainly:
“Implement an API gateway that is the single entry point for all clients.”
And the shape that makes it worth having at all — a gateway doesn’t have to treat every client identically, which is exactly the property that makes the BFF/gateway line blurry in the first place:
“Rather than provide a one-size-fits-all style API, the API gateway can expose a different API for each client. For example, the Netflix API gateway runs client-specific adapter code that provides each client with an API that’s best suited to its requirements.”
Read that sentence again: a generic API gateway can already run per-client logic inside a single shared process. That’s the crux of the whole confusion. The difference a BFF adds isn’t per-client behavior — a gateway can do that too — it’s cardinality and ownership: one shared gateway process serving every client type, versus a separate, independently deployed instance per client, typically owned by that client’s own team. The same section also notes, in passing, something worth carrying into the next part — that a gateway can already implement security, stated as: “The API gateway might also implement security, e.g. verify that the client is authorized to perform the request” — full stop, no more said about it there. Putting authentication at this layer was already a documented, generic benefit of the gateway shape years before any OAuth working group repurposed a differently-named pattern for exactly that job.
Three Axes That Actually Separate Them
Once you stop asking which one it is, and start asking which axis the label is actually describing, the three uses of “BFF” and “gateway” in circulation stop competing with each other. They’re answers to three different questions.
| Axis | Generic / centralized API gateway | Original BFF (Calçado & Newman, 2015) | RFC 10017’s OAuth BFF (2026) |
|---|---|---|---|
| The question it answers | How do many different clients reach many backend services through one door? | Who owns the backend code for one specific client experience? | Which component holds OAuth token custody so the browser never does? |
| Cardinality | Typically one shared instance for all clients (can still branch per client internally) | One deployable per client type or per team | One per frontend that needs OAuth-protected data — cardinality isn’t the point |
| Owned by | A platform or infrastructure team, per Newman’s own account of the alternative | The same team that owns the user interface | Whoever is accountable for the OAuth client role — could be the UI team, could be a platform team |
| Defined by RFC/pattern text as | “the single entry point for all clients” (Richardson) | “part of the application” (Calçado) — an ownership and deployment relationship | “a confidential OAuth client” that “forwards all requests” (RFC 10017, §6.1) — a protocol role |
| What breaks if you get it wrong | Every client is stuck with a one-size-fits-all response shape | A shared team becomes the bottleneck the pattern was invented to remove | A token reaches the browser and the residual attack surface this whole hub is about opens up |
Nothing in that table is in tension with anything else in it — a single running process can genuinely be all three at once, or any two, or just one. That’s the point the next section makes with a real system rather than a hypothetical.
The Line Gets Blurry the Moment Anyone Ships It
SoundCloud’s own engineering blog, six years after Calçado’s original post, describes its production BFFs in language that erases the “BFF vs gateway” distinction on purpose rather than by accident (dated Jul 29th, 2021):
“SoundCloud operates dozens of BFFs, each powering a dedicated API. BFFs provide API gateway responsibilities, including rate limiting, authentication, header sanitization, and cache control.”
Read that as a definition and it says: our BFFs are API gateways, just dedicated to one client instead of centralized. The same post separately contrasts its own architecture with “centralized API gateways” as the alternative it didn’t choose — which is the cardinality axis from the table above, stated by the company the pattern is named after, in its own current production vocabulary. SoundCloud isn’t confused about the difference; it has simply concluded, in practice, that a per-client BFF and a per-client API gateway are the same box wearing two labels.
Vendor tooling shipped today makes the same collapse from a different direction. Curity’s documentation for what it brands the “Token Handler pattern” — its own name for an OAuth-security BFF implementation, verified last updated 2024-03-28 — recommends building the piece that forwards requests to resource servers as “a dedicated OAuth Proxy plugin, hosted in a high-performance API gateway.” In other words: the current, vendor-recommended way to build the security-flavored BFF from RFC 10017 is to run it as a plugin inside an actual, literal API gateway product. Two years after the “BFF vs gateway” question gets asked in a design review, a leading identity vendor’s own reference implementation answers it by putting one inside the other.
OAuth Redefined the Same Three Letters Around a Different Axis
RFC 10017, “OAuth 2.0 for Browser-Based Applications” (BCP 212, Best Current Practice, August 2026), takes over the “BFF” name for §6.1 of its own architecture taxonomy — and defines it by a criterion neither Calçado, Newman, nor Richardson ever used: not who owns it, not how many clients it serves, but which party holds the OAuth client role. The RFC states the BFF’s job as three responsibilities:
“1. The BFF interacts with the authorization server as a confidential OAuth client (as defined in Section 2.1 of [RFC6749]). 2. The BFF manages OAuth access and refresh tokens in the context of a cookie-based session, avoiding the direct exposure of any tokens to the browser-based application. 3. The BFF forwards all requests to a resource server, augmenting them with the correct access token before forwarding them to the resource server.”
And then, in the very next sentence, it names the exact confusion this article is about and draws its own line — not on ownership, not on cardinality, but on protocol role:
“In this architecture, the BFF runs as a server-side component, but it is a component of the frontend application. To avoid confusion with other architectural concepts, such as API gateways and reverse proxies, it is important to keep in mind that the BFF becomes the OAuth client for the frontend application.”
That sentence is the whole divergence in miniature. RFC 10017 isn’t disagreeing with Newman about who should own the box, or with Richardson about how many clients it should serve. It’s answering a question neither of them was asking: which component is the party the authorization server trusts with a client secret and a token. A system can satisfy the 2015 definition of BFF — one team, one client, “part of the application” — while never touching OAuth at all, and a system can satisfy RFC 10017’s definition — confidential OAuth client, token custody, request-forwarding — while being run by a centralized platform team for a dozen different frontends, which is the exact ownership shape the 2015 pattern was invented to avoid.
It’s worth being precise about how completely RFC 10017 leaves the original pattern’s vocabulary behind: across its full 137,419-byte text, the words “team,” “aggregat[e/ion],” “Newman,” “Calçado,” and “SoundCloud” each occur exactly zero times, checked directly against the document rather than assumed. And “gateway” itself appears exactly once — in the sentence quoted above, existing only to be distinguished from the thing RFC 10017 is actually defining. The standard borrowed three letters from an architecture pattern about team boundaries and per-client aggregation, kept none of that pattern’s justification, and built an entirely new definition — token custody — on top of the name.
Naming the Box Correctly on Your Own Diagram
None of this means the terms are useless — it means each one answers a specific question, and the fix for a “BFF or gateway” argument is to name which question is actually on the table before reaching for either word.
- Who owns and deploys this service, and for how many kinds of client? If that’s the question, you’re on the 2015 axis. A dedicated, single-team, single-client-experience backend is a BFF in the Calçado/Newman sense whether or not it does anything with OAuth.
- Does one process sit in front of many different backends and route or reshape traffic for many different clients? If so, you’re describing a generic API gateway, whether or not any single team owns it, and whether or not it happens to run per-client logic internally (per Richardson, it’s allowed to).
- Which component holds the confidential OAuth client role and keeps tokens out of the browser? That’s RFC 10017’s axis, and the honest answer might be a shared API gateway, a per-client BFF, or a centralized platform service — the RFC never constrains who runs it.
- A single deployed service can be all three, some two, or just one — and that’s fine. SoundCloud’s own production systems and Curity’s own recommended implementation are both real examples of a box that is deliberately all three at once. The mistake isn’t running one process that does several of these jobs; it’s assuming that because a system does one of them, it automatically satisfies the others’ requirements too.
❓ Frequently Asked Questions
Is a BFF just a type of API gateway? By Chris Richardson’s own microservices.io taxonomy, yes — BFF is documented there as “a variation” of the API Gateway pattern, distinguished by cardinality (one gateway per client type instead of one shared gateway). By RFC 10017’s taxonomy, no — the RFC defines BFF by OAuth client role, a criterion Richardson’s page never mentions, and explicitly separates it from “API gateways and reverse proxies” in its own text. Both are correct; they’re using “BFF” to answer different questions.
Does RFC 10017 use the term “API gateway” anywhere? Once, in the entire 137,419-byte document (checked directly, 2026-09-18): the single sentence distinguishing its own BFF definition from “API gateways and reverse proxies” so a reader doesn’t conflate the OAuth-client role with either. It never defines what it means by “API gateway” beyond that one contrasting mention.
Can I just use my existing API gateway as my OAuth BFF? RFC 10017 doesn’t forbid it, and doesn’t require it either — it names no deployment topology at all, only three responsibilities (confidential OAuth client, token/session management, request forwarding). Curity’s own current implementation guidance recommends building the request-forwarding piece as a plugin inside an API gateway product, which is exactly that choice, made by a vendor, in production.
Why do Sam Newman’s own table of contents and heading disagree? Unknown, and probably unknowable at this distance — it reads like an editing pass that updated one location and not the other, on a live page from November 2015 that has apparently never been corrected in the eleven years since. What matters for a reader isn’t the cause; it’s that the discrepancy is a live, checkable fact in the single document most later explainers point back to.
If my backend only aggregates data and never touches an OAuth token, is it still “a BFF”? Under the Calçado/Newman definition, yes — that’s the entire original pattern, and it predates OAuth entering the conversation by roughly six years. Under RFC 10017’s definition, no — that RFC is specifically about the OAuth-client-role variant, and a pure aggregation layer with no token custody simply isn’t the architecture §6.1 describes. Both statements are true about the same word.
Do I need a separate API gateway and a separate BFF? Not necessarily. SoundCloud’s own dozens of production BFFs are described, in the company’s own words, as providing “API gateway responsibilities” — one process, both jobs. The decision to separate them (or not) should follow from the axes in the table above — ownership, cardinality, and OAuth role — not from a rule that says the two concepts must live in different boxes.
📚 Recommended Resources
Disclosure: some links below are Amazon affiliate links. If you buy through them, this site earns a small commission at no extra cost to you.
The distinction this article draws — ownership axis, cardinality axis, OAuth-protocol-role axis — is stated more precisely by the primary documents than by any book written about them, and every one of those documents is free.
Read the two founding posts side by side, in order. Phil Calçado’s original 2015 write-up is short, specific, and grounded in SoundCloud’s actual API calls. Sam Newman’s follow-up two months later is the more widely cited one — and, per this article, the one whose own table of contents disagrees with its own heading. Reading both in sequence is the fastest way to see where the pattern’s justification actually lives, before any later document repurposes the name.
Then read the independent pattern catalogue that treats BFF as a variant, not a rival. microservices.io’s API Gateway / Backends for Frontends page is Chris Richardson’s actively maintained reference — free, and the clearest short statement available of exactly how a generic gateway and a per-client BFF relate.
And read the standard that redefines the term around a completely different axis. RFC 10017, “OAuth 2.0 for Browser-Based Applications” is the IETF Best Current Practice this article’s final sections are built on. It is dense, but §6.1 — the section that actually defines the OAuth-flavored BFF — is a few paragraphs, and reading it directly is the only way to see for yourself that “team,” “aggregation,” and every name from the pattern’s 2015 origin appear in it exactly zero times.
None of these require a login, a purchase, or a summary written by somebody else. For the specific question this article answers — what does “BFF” actually mean, and does it mean the same thing as “API gateway” — the primary sources are shorter than most chapters written about them, and none of them agree on the answer, which is the whole point.
One book worth the shelf space
- Building Microservices, 2nd Edition — Sam Newman, O’Reilly. Written by the same person whose 2015 pattern post this article spends two sections on. Its chapter on API composition covers the API-gateway-vs-BFF cardinality question at book length, from the person who has now spent a decade watching the two names get used for each other.