Every column in the database. Documented once, exactly.

One row per domain, one column per fact

The database is a flat table: domain is the primary key, and every other field describes something true about that domain as of the last classification pass. There is no nested schema to parse beyond the page_types field itself, which carries up to 28 verified URLs.

Two design choices matter for anyone integrating against this schema. First, absence is recorded, not omitted: if a domain has no verified checkout URL, the schema says so explicitly rather than leaving a lookup to guess whether the field was never checked or genuinely does not exist. Second, every URL in page_types is verified from the domain's live link structure at classification time, never a guessed path pattern like assuming /login exists because most sites use it.

The 28 page types, grouped and flagged

Field 2 in the table above, page_types, is itself a map of up to 28 keys. This is the full enumeration, grouped the way the underlying classification pipeline groups them.

The 8 fields tagged action type ship with the current reclassification cycle. Not every domain has verified URLs for all 8 yet; where one is missing, page_types records its absence rather than omitting the key. A full narrative walkthrough of each group lives on the page-types database overview.

Coverage of the schema across the sample

These figures describe the schema's structure, not a claim about any specific domain's data quality.

Why the page_types field grew from 20 keys to 28

The schema is not static, and it is worth documenting the one structural change that matters for anyone who integrated against an earlier version.

The original classification pipeline covered 20 page types, all of them read-oriented: documentation, pricing, login, contact, careers and the rest of the research and identity surfaces a browsing agent needs to navigate to safely. The current reclassification cycle added 8 additional keys, all of them action types: signup, password_reset, cart, checkout, upload, post_create, comment and subscribe. The distinction between the original 20 and the newer 8 is meaningful, not cosmetic: action types describe pages where an agent would do something — create an account, submit a payment, publish content — rather than simply read something, which is exactly the category of page most agent-safety policies need to deny by default.

Because the 8 action types shipped more recently, coverage across the 40M-domain repository for them is still filling in; not every domain has a verified signup or checkout URL yet, even domains that are otherwise richly classified across the original 20 read types. The num_distinct_page_types field, described above, is the fastest way to see how deep a given domain's classification actually goes, including whether it has been reached by the action-type reclassification pass yet.

From a database row to a single API answer

The full schema above is what a licensed on-prem database delivers per row. The self-serve lookup API returns a narrower, decision-focused slice of the same underlying classification for a single URL at a time.

A licensed database consumer typically loads the full 19-field schema into their own data warehouse or policy store and queries it however their infrastructure prefers. A lookup API consumer instead sends one URL and receives a decision plus the matched page type, for example a request to /api/check?url=https://stripe.com/login returning "result":"deny","id":"login". Both paths draw from the identical classification work; they differ only in whether the schema is delivered wholesale or resolved per request. Rate limits, authentication and full response shapes for the API path are documented at the API docs.

Which path fits depends mostly on call volume and latency tolerance, not on which fields are available. A team making a small number of navigation decisions per agent run, or evaluating the product before committing, is usually better served by the lookup API's per-URL simplicity. A team running a high-volume gateway checking every outbound request from a large agent fleet typically outgrows the API's fair-use ceiling on live lookups and moves to an on-prem license precisely to remove the network round-trip and the per-call cost, running the same schema as a local index instead.

What field 2 actually stopped in 2026

A schema is easy to admire in the abstract. It is worth grounding this one in a specific, documented case where a single field made the difference.

In the 2026 account-takeover campaign analyzed on this site, agents from the same operation reached four third-party accounts by requesting login pages, and in some cases signup or password-reset flows, on services they did not control. Our analysis shows that this is precisely the login, signup and password_reset triad inside the page_types field, all three tagged identity-group fields in the table above. Denying those three keys by default, rather than trying to infer intent from what the agent claimed it was trying to do, is what our analysis shows would have stopped every documented authentication hop in that campaign before it happened. The full incident walkthrough, including why login coverage is deliberately checked twice, by both the verified database key and a pattern-matching egress rule, is on the account-takeovers incident analysis.

Page-type database schema