Schemas

The token from the invitation link.

The account they are now a member of.

What it calls itself, or null when nobody has named it.

Whether the account joined requires two-factor, so the page can say so before the gate does (IMPLEMENTATION-PLAN §5.3.6).

What they may do there.

The address the link is about: the account's for a confirmation or a reset, the new one for a change of address.

Which kind of link it is — verify, reset or change — so the page says what its button will do.

Its ULID.

Whether it belongs to one person or is shared.

What it calls itself, or null when nobody has named it.

Since when two-factor is required, or null while it is not.

What the account header carries to act on it.

Personal or Team, which is what the switcher labels the entry with.

What it is called, or null for a personal account nobody has named.

What the caller may do there. The same string /me reports for the current one.

Whether the account has been stopped, directly or through one of its owners.

Whose it is.

ULID of the token, which is what an owner revokes it by. A handle, not a credential.

When a request last authenticated with it, or null if never.

What they called it, which is what makes a list of them readable.

Whether it has been revoked, as a flag rather than a date.

Every account the caller may act on, oldest membership first. Never empty for a signed-in person: signing in creates an account for them, and they are its owner.

Whether a site is already answering on this hostname, which is what decides how many records the customer is asked for.

False, or absent, takes the one-record path: the certificate provider proves ownership from the CNAME and answers the challenge from the edge, at the cost of a few minutes where the hostname has no certificate. True takes the older path — two TXT records first, certificate issued before the CNAME moves, no gap — which is worth its extra steps only to somebody with traffic to lose.

Asked rather than guessed because the answer is not visible from here: a hostname that resolves somewhere today may be a live business or a parked page, and the two want opposite things.

The hostname to serve the site on, as the customer typed it. Normalized and validated on the server; what is stored is never this string directly (invariant I4).

Headers to attach to every call, values in plain text — sealed on arrival.

Methods visitors may send; GET only when left out.

https://host the site's _redirects sends calls to.

The addresses to add, as typed. Each is trimmed and lower-cased before it is stored; repeats collapse.

Whether to mail each address added, defaulting to yes. Undo sends false: putting back somebody just removed should not mail them twice.

What every address added may do: View (the default) or Comment, in any case. Comment is refused on a plan without comments. Addresses already listed keep the role they have.

The addresses newly put on the list, as stored.

The addresses sent that were on the list already, left as they were.

How many people the list now holds, the owner included.

True to hand the command line a token, false to refuse it.

The short code as typed, in any case and with or without the dash.

What was decided, echoed so a page rendering the result cannot disagree with the server.

What the command line calls itself, so the page can name it in the outcome.

OAuth 2.0 client id, safe to embed in client-side code.

Fewest characters a password may have, so the page's rule list says the server's number.

Key the sign-up form renders its Turnstile widget with, or null when this deployment has none — in which case sign-up with a password is unavailable and the page should offer Google alone.

Unpadded base64url SHA-256 of the verifier the command line kept.

What the command line calls itself; becomes the token's name.

A named server-side callback instead of a port — mcp for the remote MCP server. Never a URL.

The loopback port the command line is listening on. Exactly one of this and Callback.

The one-time code. Returned exactly once and recoverable nowhere.

When the code stops being exchangeable.

Where the consent page should send the browser, code appended as a query.

Normalized path, which the client uses to find the bytes and to name a failure.

Digest, which is also how the layout line and the object's key are built.

Always true; the provider took the request.

A comment the person wrote on the site.

Whether to delete every comment they wrote on the site as well.

How many of their comments were deleted now.

The person, as the Blocked list names them.

The token the mailed link carried.

Whose sign-in is waiting, so somebody on a shared computer can see it is not theirs.

When the step closes.

Where the sign-in was going, for a Google sign-in, whose destination the server carried; null for the other ways in, whose page kept its own.

The password the account uses now.

The password to replace it with.

Billing interval, month or year.

Id of the plan to move onto.

now, or absent, which means the same thing: the change is applied immediately and the difference is settled against the unused remainder of the current period. Kept in the contract only so that period_end — which this route offered until the provider was found to have no way of deferring anything — can be refused by name instead of being read as now and charging a customer who was told nothing would be charged.

The role to give them: Owner or Member.

How many seats to be billed for from now on — the total, not a difference. A delta would make the request depend on what the client last read, so two owners pressing "add a seat" at once would buy two seats each.

The new subdomain, as typed. Normalised the way a new site's is.

The role to give: View or Comment, in any case.

The address, as it is stored.

The role it now has.

Billing interval, month or year.

Id of the plan to buy.

The provider-hosted page to send the buyer to.

Every site the caller holds a token for.

Sites now owned by the caller.

Sites that were not claimed, each with a reason. A batch can be partly successful, so this is not an error case — the caller shows what it got and drops the rest from local storage.

ULID of the site.

Its subdomain.

Its public URL.

The address the API will rate-limit this caller by.

Header the address was taken from. X-Forwarded-For means the chain was walked and TrustedHops is what decided the answer; any other name means that header was read directly and the hop count did not apply.

Configured number of proxies in front of the API.

A display name for the site, read by the client from the <title> of the index.html being published.

Applied only to a site that has no name yet, and only on the call that takes a deploy live — so a redeploy never renames a site, and a retried completion never renames one either.

Cleaned by SiteNames before it is stored, and dropped silently when nothing usable is left. It is not worth failing a deploy whose files have already been verified over the contents of a title tag, and the owner can type a name on the settings page regardless.

ULID of the deploy that is now live.

Whether the site is read through the documents viewer rather than served as files.

Reported for the same reason as Name: the server decides it, from the files this deploy actually holds (SiteModeDetection), and a client that guessed from what it uploaded would be wrong exactly when it matters — the web app that went live inside the reader because its index.html sat one folder too deep, with nothing on the finished card saying so.

live when the edge has the deploy, pending when the deploy is live but the edge write did not land yet — Cloudflare refused it or its API budget is spent. A pending deploy is not a failure: it reaches the edge on its own, usually within the Retry-After the response carries, and calling complete again is safe but not needed.

Number of verified files.

Whether the owner chose the mode by hand, in which case no deploy changes it.

What the site is called now, or null when it has none and its subdomain should be shown instead.

Reported rather than left for the client to infer, because only the server knows the answer: it cleans the name it is sent, and it refuses to overwrite a name the site already had. A client that assumed the title it sent is the name now stored would be wrong on every redeploy.

What the anonymous flow needs. A site is remembered in the browser before its first deploy starts — the claim token is returned once and storing it cannot wait — so the name is not known at that point and arrives here instead.

Whether unmatched paths are answered with the site's index.html.

Always live on success.

Total verified size in bytes.

Public URL the site answers on. Content may take up to a minute to reach every edge.

What to call the folder. Cleaned the way a site's name is.

Folder to create it inside. Omit it, or send "root", to create it at the top level — see string SiteFolderAccess.RootToken for why a literal token rather than null.

The caller's own choice of subdomain, checked by SubdomainFormat and ReservedNames and counted against int? Plan.MaxCustomSubdomains. Null or empty falls back to a generated one.

The folder to file the new site in: a folder id of the caller's account, or root. Null or empty means the top level, which is where every site started before this field existed. Naming a folder the account does not hold is site_folder_not_found, and so is naming one at all without an account.

Plaintext claim token, present only for an anonymous site and returned only here. The server keeps nothing but its hash, so a client that loses it cannot recover ownership.

When an unclaimed anonymous site is removed. Null once the site has an owner.

ULID of the new site.

Allocated subdomain, without the parent domain.

Public HTTPS URL the site will answer on once a deploy goes live.

How long it should last, or null for a token that never expires on its own.

What to call the token, so its owner can tell it from their others.

When it was issued.

When it stops working on its own, or null.

ULID of the new token.

The name it was given.

Its first characters, which is what every later listing shows.

The plaintext. Returned exactly once and recoverable nowhere.

The mark drawn before it — ProductHunt, Gift, Sparkles or Megaphone — or null for none. A page that does not know a value draws no mark.

Which bar this is.

The link's words, or null for no link.

Where the link goes — an https URL or a path on this site — or null.

The sentence, plain text.

The address the person signs in with, typed again as confirmation.

An authenticator code, the other proof an immediate deletion accepts.

The password, asked for only when Immediately is true.

True to skip the grace period: erased within minutes, with no way back.

When the deletion takes effect. Until then it can be called off.

The folder that was removed.

How many folders were lifted one level.

Where its contents went: the deleted folder's own parent, or null when they are now at the root.

How many sites were lifted one level. Reported so the dashboard can say what happened rather than leaving somebody to find their sites somewhere they did not put them.

ULID of the deleted site.

Its subdomain, which stays reserved.

When it reached a terminal state, or null while in flight.

When it was prepared.

ULID of the deploy.

Why it failed, when it did.

Files it holds.

Whether this is the deploy currently being served.

ULID of its site.

Lowercase status name.

Its size.

The site's URL, present only when this deploy is live.

The path, normalized — which is the spelling the manifest holds.

Digest of the content as stored.

Sent so the editor can publish a change without re-reading anything: the new manifest is the old one with this entry's digest replaced, and every other file is reused by prepare.

Size in bytes, as the manifest records it.

The file's text, or null when the bytes are not valid UTF-8.

Null rather than a lossy decode, so the dashboard can say the file cannot be edited here instead of offering an editor whose contents would overwrite the original with replacement characters.

ULID of the deploy the files belong to.

Files in the whole deploy, whatever the filter matched.

This page of matches, ordered by path.

Whether the deploy is inside the retention window with its objects still on storage, the same answer as filesKept on the site's version list. The list is answerable either way — it is read from the row — so this is what separates "these files are here" from "these files were here".

Their total size, on the same terms.

Files the filter matched, equal to FileCount without one.

Path to pass back as cursor for the following page, or null when this page was the last.

Lowercase status name of that deploy.

Size of the whole deploy, whatever the filter matched.

When it reached a terminal state, or null while in flight.

When it was prepared.

ULID of the deploy.

Why it failed, when it did.

Files it holds.

Whether this version is inside the retention window with its files still on storage, and therefore whether it can be previewed or rolled back to.

It is a field rather than something a client works out because it cannot be worked out from the rest of the response. site.trim_deploys keeps the plan's retainedDeploys most recently live deploys, a rollback counting as going live, and deletes the objects of the rest, leaving the rows. A version outside that window reads false at once, before the trim has run, because promote refuses it by the same rule. The dashboard used to redraw that rule from a deploy's position in this list, and disagreed with the server in both directions — and a plan whose retention was lowered then raised has versions inside the window whose files went weeks ago.

string DeploySummary.Status does not answer it either: a superseded deploy may be fully stored or entirely gone. Nothing about the row changes when its objects are deleted except this.

URL serving this deploy on its own hostname, or null when there is no reachable preview of it.

Two reasons for null, and they are unrelated. The site's subdomain may be too long to leave room for a preview hostname (see int PreviewHostFormat.MaxSubdomainLength). Or the site's hostnames may not be answering at all — see bool SiteLifecycle.HostnamesServe(Site site): a preview resolves through the site's own hostname, so a tombstoned site has no reachable preview of any version, however sound the deploy behind it is. A site an administrator restores is exactly that, and reporting a URL for it was how the dashboard came to offer a history of versions none of which opened.

It works for any deploy whose files are still on storage, including one that was never published, and stops working once retention removes them — the same condition promote reports as a 410. Nobody is asked to log in: the URL is unlisted rather than access-controlled, and what protects it is the 80 bits of randomness in a ULID. A password-protected site's previews are behind that password like the rest of it.

Lowercase status name.

Its size.

Six digits from the app.

The account's password.

Six digits from the app; spaces are ignored.

Its ULID.

What it is called.

When it was first set.

The value's last four characters, or empty for a short value.

The name.

When its value last changed.

The one-time code the browser handed to the loopback listener.

The verifier the command line generated and never sent through the browser.

When it was issued.

That account's address, so the command line can say who it signed in as.

The name it was given, which is what the command line called itself.

Its first characters, which is what every later listing shows.

The plaintext access token. Returned exactly once and recoverable nowhere.

ULID of the token, so it can be matched to a row on the tokens page.

The account it speaks for.

The account's id.

Its invoices, when they own it.

When they joined it.

Personal or team.

The team's name.

The plan the account is on.

Their role there.

Its subscriptions, when they own it.

When it finished.

When publishing started.

How many files.

The version's id.

Where it stands.

How many bytes.

When it was added.

The hostname.

Where it stands.

What the visitor typed, as sent.

The form's name.

When it arrived.

The site it was sent to.

What was charged, in cents.

What was refunded, in cents.

The currency.

When it was issued.

The payment provider's reference.

Where it stands.

When they answered.

When they agreed to product mail, if they did.

When they last unsubscribed from it, if they did.

What they said they do.

Where they said they heard of it.

What they typed about that.

What they said they would use it for.

When they signed up.

The address they sign in with.

When the address was confirmed.

Whether Google is a way in.

Whether a password is a way in.

Their id.

When they last used the dashboard.

Their name, if they gave one.

The account it belongs to.

When it was made.

Its versions, without their files.

Its custom domains.

The site's id.

The name its owner gave it.

Where it stands.

Its address under the content domain.

When it was cancelled, if it was.

When it started.

When the paid period ends.

What it pays for.

How many seats.

Where it stands.

The short code as typed, in any case and with or without the dash.

What the waiting command line calls itself.

When the request stops being approvable.

Whether it asked from the same address as the browser now looking.

When the command line asked.

The two-letter country of that address, or null when not known.

The address it asked from, or null when that is not known.

The address the account signs in with.

Zero-based index of the page returned.

How many rows a page holds, after the cap was applied.

The page, newest first.

How many this form has in total, so the reader knows there is more.

Which deploy was live at the time, which is what explains a column being empty: the field did not exist in the HTML that was serving then.

What the visitor typed, as the JSON object it was stored as.

ULID minted at the edge when the submission arrived.

Page, host, country, truncation and the Turnstile verdict, as stored.

When the edge accepted it, not when the row was written.

Who called it spam — system, user, or nobody.

When the site stopped answering on it.

The former subdomain, which redirects to the current one.

Function calls this calendar month across every site, up to about an hour and a half behind. Resets with filesResetAt.

Calls the account's sites may make together each calendar month, seats included.

Sites that may run functions at once. A deploy that would add one past it is refused.

Sites whose live version has functions, which is what maxSites bounds.

Whether this month's calls are spent and every function of the account answers 429.

The ID token (JWT) Google's Identity Services callback handed the browser.

Extra storage it adds, in bytes, or null when it adds none.

Whether it switches on comments, for the same reason.

Whether it switches on private sharing by email, so the page can say where that came from on a tier that does not include it.

Whether it switches on password protection, for the same reason.

When it runs out, or null when it does not.

Extra custom domains it adds.

Extra sites it adds, or null when it adds none.

What to call it. The campaign's name where it came from one, and a generic label otherwise — never the administrator's own note, which is written for the console.

Whether it takes the Drop2Run badge off this account's sites.

Extra publishing operations a month, or null.

Postgres connectivity: up or down.

Overall status: ok or degraded.

verify for a confirmation link, reset for a password reset link, change for a change-of-address link.

The token the mailed link carried.

Address to invite. Compared against the accepter's own before they are let in.

What accepting grants: Owner or Member. Absent means member.

Absent rather than required, and defaulting to the lesser of the two, because an omitted field must not hand out authority nobody asked for — the same rule every capability column on a plan follows.

The link. Returned here and nowhere else — only its hash is stored, so this response is the one chance to copy it, which is what lets an owner pass it on when mail does not arrive.

The address it was sent to.

When it stops working.

Its id, for revoking.

The address it was sent to. The link only works for this one.

When it stops working on its own.

Its id, which is what withdrawing it names.

What accepting it would grant.

Amount in the smallest unit of Currency.

How much of it has been given back. Shown beside the charge rather than instead of it, so a partial reversal reads as what it is — a status alone cannot say how much of the money came back.

ISO 4217 code.

Link to the provider's own copy, or null.

Our own id for the invoice.

When the provider issued it.

End of the period covered, or null.

Start of the period covered, or null.

One of the InvoiceStatus names.

The account's invoices, newest first.

Zero-based index of this page.

How many rows a full page holds.

The rows on this page, in the order that was asked for.

How many sites match, across every page — which is what the pager is against. Equal to TotalOwned when no search was asked for.

How many sites the caller owns, ignoring any search.

Both numbers, because the listing says both: the page header counts what the account holds and the line above a searched list counts what matched. One number cannot carry that sentence, and a client holding the other from an earlier response has a number that a deletion can make wrong.

What colleagues hold on the same account, and only what an owner is entitled to know about them. Empty for a member, and empty for an owner whose colleagues have none.

A separate list rather than the same rows with fields blanked out, because a row that is sometimes missing its prefix is a row whose type is a lie — and the screen showing it has to branch on something either way.

The caller's own tokens on this account, newest first, including revoked ones.

Path relative to the deploy root, as the client sees it.

SHA-256 of the content, lowercase hex.

Exact length of the content in bytes — the length that will be uploaded. 0 only for an empty file, whose checksum is the SHA-256 of zero bytes.

Its path within the site, already normalized and always /-separated.

SHA-256 of the content, lowercase hex — what the upload was verified against.

Its size in bytes.

Every account they are in, with billing for the ones they own.

When the file was made.

What visitors sent through those sites' forms, as kept (ninety days).

The person.

The sites of the accounts they own.

The account this session is acting on.

What the account is called, or null for a personal one nobody has named.

Sent because every screen under /account is now about an account rather than about the person reading it, and a page headed with somebody's own name while describing a shared tier is the exact confusion the team screens were redesigned to remove.

Email from Google.

Extra quota this account holds outside its tier, one entry each, oldest first.

The figures in Plan already include these — every one of them is the effective number the server enforces — so this is not a second set of limits to add up. It is what lets a page say why a figure is larger than the tier it names, which is the difference between a benefit and an apparent bug in the dashboard. Empty for almost every account.

Display name from Google, if any.

pending while this person has neither answered nor skipped the first-visit questions, and done once they have.

On the person rather than the account, like the name and the address beside it: somebody in two accounts is asked once. Everybody who had an account before the questions existed reads as done, because the migration that added the table gave them a skipped row (A14).

When the account's grace for being over its plan runs out, or null while it fits.

Non-null means something will be cut on that date — the oldest sites are put to sleep and the oldest custom domains are removed, only as far as it takes to fit. It is served so the dashboard can say so beforehand: nobody should learn about this from a site going quiet.

The quota tier currently applied to this user.

How many unused two-factor recovery codes this person has, or null while two-factor is off. On the session rather than only on the profile because the reminder it drives — three or fewer — is shown on the site list, which does not read the profile.

What the signed-in person may do on that account: Owner or Member.

Served so the dashboard can leave out controls the caller cannot use — a delete button, the billing pages — rather than showing them and reporting a refusal afterwards. It is not the permission: every one of those actions is refused at the handler regardless of what the page drew, and a client that ignored this field would gain nothing but a worse error message.

How many seats the account is paying for, which is what its raised ceilings were computed from.

One on every tier not sold by the seat, where it is a constant rather than a measurement. It is not the number of members: seats are bought and members are people, and the two moving independently is the whole reason inviting somebody does not silently change an invoice.

How much of the plan is currently used.

ULID of the signed-in user.

Their address, which is how a colleague recognises them.

Whether they created the account. A founder cannot be removed or demoted while the plan is held in their name, so the members screen offers neither for this row.

When they were added.

Their display name, or null when Google gave none.

What they may do here.

Whether they have two-factor on — the column an owner reads before requiring it, and a member reads to see whether the rule would block them.

Their ULID, which is what removing them names.

Invitations still standing. Spent and withdrawn ones are history, not a list.

People who may act on it, oldest first.

Since when the owner has required two-factor of every member, or null while they have not.

Access tokens on this account held by members without two-factor. Requiring two-factor does not stop them, so the owner is told before turning it on.

Folders to move under it. May be empty when only sites move.

Sites to file there. May be empty when only folders move.

Where everything goes: a folder id, or "root" for the top level. Required — see string SiteFolderAccess.RootToken for why the root is a token rather than an absent value.

Folders that changed parent, counted the same way.

Sites that changed folder. Fewer than were sent when some were already there, which is not an error.

The folder everything is now in, or null for the top level.

Whether claiming it switches on comments.

Whether claiming it switches on private sharing by email.

Whether claiming it switches on password protection.

Its code, or null when there is none to type.

Extra storage it gives, or null when it gives none.

Extra custom domains it gives.

Extra sites it gives, or null when it gives none.

Extra sites a day the account may create, or null. Only ever set on a campaign aimed at named accounts, so only an account the operator chose ever reads a figure here.

Extra publishing operations a day, or null.

Extra publishing operations a month, or null.

When claiming closes, or null when it does not.

How long what it gives lasts, or null for good.

The campaign, which is what a button with no code to type sends back.

What to call it on the banner.

How many accounts may still claim it, or null when any number may. Read a moment ago and acted on a moment later, so it is a number to show rather than a number to trust — the redeem endpoint is what decides, and it decides in one statement.

Whether claiming it takes the Drop2Run badge off.

What this account can claim, the ones closing soonest first and the open-ended ones last.

The address the account was created with.

The password.

A bot check token, needed only after turnstile_required.

When the checkout began.

The billing interval chosen.

The plan the checkout is for.

open or completed.

The address being moved to.

When the link stops working.

When it was asked for, so the page can say how long ago the link went out.

The billing term before, or null when there was none.

The tier before.

Seats paid for before; one on every tier not sold by the seat.

When it happened.

Why it moved: one of PlanChangeReason.

The billing term after, or null when there is none.

The tier after.

Seats paid for afterwards.

The account's tier changes, newest first.

Whether the dashboard offers to save this tier's traffic figures as files.

Another statement about what the tier is sold with rather than a lock: the files are assembled in the browser from the traffic response the page already holds, so a reader who can see the page can read the same numbers off it — see bool Plan.AllowAnalyticsExport.

Whether the dashboard lets an owner edit a file of their site in the browser.

A gate rather than packaging, like the flag above: the endpoint the editor reads a file through is refused outright for a tier without it.

Whether a site on this tier can take comments on its pages (docs/IMPLEMENTATION-PLAN.md §16.7).

Served so the pricing page and the marketing pages say which tiers include comments from the table, never from a sentence: the tiers that carry it are set in the admin console and change without a release.

Whether a site on this tier may be shared with named people, each signing in with their own account. A capability beside AllowPasswordProtection — the two are the paid answers to "who can see this site" — and served for the same reason: the pricing page lists it beside the password.

Whether a site on this tier may be put behind a password. The first capability on this record rather than a quantity, so it reads as a boolean instead of a limit of zero: the tier either offers the feature or does not, and "0 passwords" would describe a countable resource nobody has any of.

Served here for the same reason every number above is — the pricing page and the site settings form both have to know, and a client that hardcoded which tiers had it would be wrong the first time an operator flipped the column.

Whether the dashboard offers a QR code for the addresses of sites on this tier.

Served rather than decided in the browser for the same reason the flag above is, and for one more: this is the only thing that decides the feature at all. The code is drawn from an address that is already public, so the tier's answer is a statement about what the tier is sold with, not a lock — see bool Plan.AllowQrCode.

Whether an owner on this tier may schedule when one of their sites comes down.

Unlike the two flags above, this one is a real gate rather than a statement about packaging: the server refuses to set a date for a tier without it. Served all the same, so the pricing page can list it and the dashboard can explain the absence rather than failing on submit.

Whether this tier's traffic page lists top pages, referrers, countries and broken links, and filters by them. Served so the pricing page and the locked panels can name the tier that includes them.

Whether this tier's traffic page splits people from bots and AI, and shows devices, browsers, campaigns and edge speed.

How many days of a site's own traffic this tier lets its owner see, or zero when it includes none.

A count where bool PlanResponse.AllowPasswordProtection is a flag, because there is something to meter here: the difference between tiers is how far back the history reaches, and a boolean would need a second field to say that. Zero reads as "not on this tier" rather than as a quantity nobody has, which is why the pricing page renders it as words rather than as the number.

Short label shown against the tier, or null for none. See string? Plan.BadgeText.

ISO 4217 code the two price fields are counted in.

Where the tier sits on the pricing page, lowest first.

Plan id, as stored.

Whether this tier is not on the pricing page, and reaches the caller only because it was agreed with them.

Always false on the anonymous route, which returns the listed tiers and therefore has nothing to say here. It exists so the dashboard can label the card: a reader meeting a price nobody else is offered, beside prices everybody is, would otherwise have no way to tell which is which — and would reasonably wonder why they cannot find it on the pricing page.

Not the same question as bool PlanResponse.IsPurchasable. A tier can be agreed before its prices are set, which is exclusive and not yet buyable, and the card has to say both.

Whether the tier can be bought right now. Separate from being listed: a tier that is listed and not purchasable shows its price and its limits with no button, which is how a tier is announced before there is a checkout behind it. See bool Plan.IsPurchasable.

Whether the two prices are the cost of one seat rather than of one period.

Served publicly because the pricing page cannot render the tier without it: fifteen dollars a seat and fifteen dollars a period are the same number in the same field and three times apart in what a customer pays. A page that showed the column would put this tier beside the one above it at an identical price.

Days before the site is deleted, or null when it is kept for good.

Maximum bytes the account may hold across every site and every kept version, or null when the tier has no total. Null on the anonymous tier, which has no owner to total by. See long? Plan.MaxAccountBytes.

New or changed files the account may publish in a calendar month, or null when the tier is not bounded by month. The one limit on this page that is a cost rather than a capacity: republishing a file that has not changed spends nothing against it.

Maximum hostnames of the customer's own that one account may be served on, counted across every site it owns. Zero means the tier does not include the feature, which is what both free tiers are seeded with — so the pricing page reads this as a capability rather than as a quantity. Never null, unlike the quotas above it: there is no unlimited version of a resource billed monthly per unit. Distinct from int? PlanResponse.MaxCustomSubdomains, which counts names on our own content domain. See int Plan.MaxCustomDomains.

Maximum sites one owner may have picked their own subdomain for, or null when the tier does not limit that at all. See int? Plan.MaxCustomSubdomains.

Maximum size of a single file, in bytes.

Maximum files in one deploy.

Maximum form submissions one account may take in a calendar month, across every site it owns. Zero means the tier does not include the feature, and every tier is seeded zero — the figure worth selling is not known yet, so it ships off and an operator raises it per row once the counter has something to read. The pricing page therefore renders this as a capability until somebody sets a number. See int Plan.MaxFormSubmissionsPerMonth.

Requests one account's sites may proxy to their owners' upstreams in a calendar month. Zero means the tier does not include the proxy. See int Plan.MaxProxyRequestsPerMonth.

Most seats it can be held with, or null for no ceiling.

Maximum total size of one deploy of one site, in bytes, or null when the tier does not bound a single publish and lets the account total do it instead. Not a storage limit either way: it is weighed against a single publish, and every kept version is stored whole. MaxAccountBytes is the storage one.

The most comments one site on this tier may hold, deleted ones not counted. Only meaningful where AllowFeedback is on; served on every tier like the other ceilings.

How many people one invite-only site may list, its owner included. Read only where AllowInvitedViewers is on; a figure on a tier without the feature describes nothing.