What P2P serves without a login

Settings says the three kill switches persuade the browser rather than the API. This page is the part that sentence implies and never states: which endpoints are genuinely open, and what each of them hands out.

You need it for two decisions. First, whether this platform can run a private marketplace — a book only your signed-in customers can see. Second, what to say when a maker asks whether their offer, their terms and their trading record are visible to people who have not signed up.

The short answers are no, not without a code change and yes, all of it.

How a route becomes public

The router decides in one line, in handler/Routes.ts:

if (!metadata.requiresAuth) {
  // licence gate -> baseline rate limit -> optional user -> handler
}

It is a falsy test, not an equality test. A route that declares requiresAuth: false is public, and so is a route that never mentions requiresAuth at all. There is no default of true applied anywhere.

That matters because it means the public surface is larger than a grep for requiresAuth: false suggests. Nine P2P routes declare it. Four more are public because nobody wrote the line.

The nine that declare it

All GET. All licensed (see below). All answer an anonymous curl.

The four that are public by omission

Same behaviour, no declaration. They are worth knowing about individually because three of them return more than the curated market endpoints do.

What optionalAuth does

Five of the public routes also set optionalAuth: true. It is not an authentication requirement; it is permission for a public route to know who is asking.

Without it, a public route never runs authenticate, so data.user reaches the handler as undefined even for a caller with a valid session — and every "public, personalised when signed in" branch runs its signed-out half for everybody. On the market that was visible: nothing knew whose offers were whose, so the picks shelf could recommend a maker their own offer, which 404s when taken.

With it, one read resolves the caller from the access token or, past the 15-minute token expiry, from the sessionId cookie. It never refuses — a missing, expired or revoked token simply leaves the caller anonymous and the request proceeds.

What it changes on each route:

What these endpoints disclose about your users

Nothing here returns an email address — that was fixed deliberately on the listing, the board and the offer permalink. What it does return, to anyone:

• Full name and avatar of every offer maker and every trader on the board.
• Presence. The board and the traders lens return lastSeenAt as the trader's exact lastLogin timestamp. The offer permalink deliberately does not: it deletes lastLogin and emits a floored age instead, so a consumer can learn "between three and four hours ago" and no more. The two are inconsistent, and the board is the permissive one.
• A trading record. Completed trades, completion rate, average release time in seconds, review average and review count — see Reputation.
• Country list. GET /api/p2p/location reads profile.location.country across the whole user table, not just P2P participants.

An offer id is enough

GET /api/p2p/offer/{id} has exactly one visibility rule: a DRAFT is answered as "Offer not found" unless you are its author. There is no status filter and no PRIVATE filter on this route.

So anyone holding an id can read the offer's price model, its limits, its written terms, its payment methods, its taker requirements and its maker — including offers that are PAUSED, REJECTED, CANCELLED or EXPIRED, and including offers whose maker set visibility: PRIVATE precisely so they would not appear on the board. PRIVATE means "excluded from listings", not "protected". Creating offers describes the setting from the maker's side; make sure your own support copy does not describe it as private in a stronger sense than that.

The switches do not gate any of this

p2pEnabled, p2pMaintenanceMode and p2pAllowGuestBrowsing are read by five frontend client components and by no backend route. Grepping the backend for them returns a single comment.

And on most pages they do less than "hide the UI":

p2pAllowGuestBrowsing in particular adds a "feature restricted" banner for a signed-out visitor on the market page and then draws the market underneath it. It does not gate the fetch, and the endpoint it calls would answer regardless.

To actually take P2P offline, switch the extension row off at /admin/system/extension — and read the drain procedure first, because doing it with live offers strands their escrow behind gated routes.

The licence gate does cover them

This is the one gate that is genuinely in front of the public routes. licenseEnforcementGate runs on the public branch of the router, before the handler, and the extension map binds the whole /api/p2p and /api/admin/p2p prefixes to the p2p extension.

That last row is worth internalising. Fail-open is the platform's long-standing behaviour for every addon except the two newest, so a transient database or filesystem error during licence verification serves the market board rather than refusing it. An unlicensed install is closed; an install whose licence cannot be checked is open.

This is also why step 4 of the install verification is a plain curl against the market board: a licence or forbidden error there means the licence has not validated, not that authentication is missing.

Rate limits: what actually applies

Running a private marketplace

There is no supported way to do it today. A setting that made the P2P API signed-in-only would have to flip these routes onto the authenticated branch of the router, and no such setting or gate exists. Faking it in the settings screen was rejected for the same reason the Security tab was removed: a switch that claims to lock the door when it only takes the sign down is worse than no switch.

Three things you can actually do, none of them equivalent:

Whichever you choose, write it down. "Is our order book public?" is a question that gets asked once, by somebody senior, usually after it has already been answered by a screenshot.

Checking your own install

# Every one of these should answer with data, signed out, on a licensed install.
for p in \
  "/api/p2p/market/board?side=buy&limit=1" \
  "/api/p2p/market/traders?limit=1" \
  "/api/p2p/market/picks" \
  "/api/p2p/market/locale" \
  "/api/p2p/market/stats" \
  "/api/p2p/market/top" \
  "/api/p2p/market/highlight" \
  "/api/p2p/cryptocurrencies" \
  "/api/p2p/landing" \
  "/api/p2p/location" \
  "/api/p2p/offer?perPage=1" \
  "/api/p2p/offer/popularity?limit=1"
do
  printf '%-46s %s\n' "$p" \
    "$(curl -s -o /dev/null -w '%{http_code}' "https://YOUR_HOST$p")"
done

A 403 on all of them means the licence has not validated. A 200 on all of them is the documented, expected state — it is not a misconfiguration you can correct from the admin panel.

The thirteenth, GET /api/p2p/offer/{id}, needs a real offer id; take one from the board response and confirm for yourself what comes back.