From zero to a signed verdict in one call.

The free tier is anonymous. Send a stable per-install token in X-Pentonym-Install and you get three checks before any signup. Always pass goods — the field of use. Trademark conflict is judged relative to it; without it the trademark axis can only return CANNOT_DETERMINE.

The response is a signed verdict. Trimmed for readability — the real body carries full per-axis evidence and the verbatim signed_payload:

Only gating aspects (the trademark axes) can return DO_NOT_PROCEED. Material aspects — domains, handles, web use, cultural flags — shape how you proceed; they never bar. The signature covers signed_payload exactly (the normalised name, decision, issued-at and per-aspect states) — not the evidence lists, which are large and unordered.

Auth is a header, never a cookie — safe to call cross-origin from a browser. The free tier is a real, first-class path, so an unauthenticated call is legitimate (it is metered, not rejected). There are two ways to identify a caller:

• Bearer API key — Authorization: Bearer pk_…. Identifies a keyed account (the BearerApiKey scheme in the OpenAPI spec). Mint one at POST /v1/connect; the key is the identity — there are no passwords or sessions.
• Install token — X-Pentonym-Install: <opaque>. A stable per-install token for the anonymous free tier (MCP clients and the web app carry it). Persist it client-side so the three free checks are counted against the same install.

• 3 anonymous checks per install token — no signup.
• +10 checks once you connect a free account: POST /v1/connect with an email returns a pk_… key (shown once) carrying a one-time signup bonus.
• After that, a paid plan. When the free tier is exhausted the API returns HTTP 402 with an upgrade_prompt field written to be surfaced verbatim by a calling LLM — never a bare error.

Check your balance any time with GET /v1/account (send the Bearer key). Batch requests and a per-user OAuth connector are on the roadmap (coming soon).

• POST /v1/screen — the signed three-state clearance verdict (PROCEED / DO_NOT_PROCEED / CANNOT_DETERMINE). Metered.
• POST /v1/classify — free-text product description → Nice class(es) + verbatim USPTO ID Manual identification language, with a surcharge_free flag for accepted entries (surcharge avoidance).
• POST /v1/watch — register a watch on a mark and run the first register scan immediately, returning a signed alert.
• GET /v1/watch/{watch_id} — re-scan a registered watch; returns a fresh signed alert.
• GET /v1/account — the account behind a Bearer key: tier, checks remaining, bonus balance.
• POST /v1/connect — issue an account key (+10 signup bonus, once per email).
• GET /v/{verdict_id} — independently verify a signed receipt (HTML page or JSON, content-negotiated).
• GET /.well-known/pentonym-signing-key — the Ed25519 public key, algorithm and canonicalisation rule. Unauthenticated.
• GET /mcp — the streamable-HTTP MCP server (discovery + live smoke).
• GET /openapi.json & GET /docs — the full machine-readable spec and interactive Swagger UI.
• GET /health — liveness plus whether signing, EUIPO and metering are configured.

The /v1/screen body accepts more than name and goods: classes (Nice classes), markets, in_use, filing dates for a filing plan, and deep (the slow, thorough Instagram/TikTok handle checks — off by default). Unknown fields are rejected rather than silently dropped, so a typo can't quietly run an unconstrained search.

Pentonym ships as an MCP server over streamable-HTTP, so an assistant can clear a name mid-conversation and return a real signed verdict rather than a guess. Point your client at https://mcp.pentonym.com and pass your key as a Bearer header:

The tool descriptions carry the honesty rails so the model repeats them, and instruct it to always pass goods — which it usually knows from the conversation.

Every verdict is an independently verifiable Ed25519 receipt. A downstream product — or a founder's lawyer months later — can confirm a verdict was genuinely ours, two ways:

• Hosted: open https://pentonym.com/v/{verdict_id}. A browser gets a PASS/FAIL page; curl and SDKs get the same fields as JSON. The server re-checks the signature over the exact bytes it persisted.
• Yourself: fetch the public key from /.well-known/pentonym-signing-key and verify the signature_b64 against the canonicalised signed_payload — no call back to Pentonym required.

Canonicalisation is JSON with sorted keys, compact separators and UTF-8. verified: true means the signature matches; false means the receipt was altered or signed by another key; null means the server has no key configured and cannot answer — never a false PASS or FAIL.

• Three states, no number. There is no score anywhere in any response, and the verdict shape provides no way to add one. Averaging non-commensurable axes is exactly the false precision Pentonym refuses.
• CANNOT_DETERMINE is not an error. It means a gating aspect could not be screened — absence of evidence is not evidence of absence. Treat it as "unknown", never as "clear".
• US & EU, not worldwide. The US register is screened for full likelihood-of-confusion; the EU is a live EUIPO exact-wordmark knockout. No other national registers — don't present it as global.
• Not legal advice. Pentonym is the front of the clearance funnel, not a written clearance opinion. It is not a law firm, and no attorney-client relationship is formed. Every response repeats this.