Three numbers, and nothing else. Leed meters identified contacts, marketing emails per month and analytics history, and no other quantity anywhere in the product — no traffic, no bandwidth, no storage, no seats, no page count.
The three do not fail the same way, which is the part worth learning. Contacts are capped on display, never on capture: you keep collecting past the limit and the excess is hidden until you upgrade. Marketing email is a hard block before anything sends: a blast that would cross the line is refused whole. Analytics history is a query window: nothing is ever deleted, and a request that reaches too far back is either trimmed or refused.
| Quota | Free | Starter | Growth | Enterprise | What happens when you reach it |
|---|---|---|---|---|---|
| Identified contacts | 250 | 1,000 | 10,000 | Unlimited | Capture continues. Your newest contacts lock and become invisible. |
| Marketing emails per month | 0 | 5,000 | 50,000 | Custom | The whole batch is refused before anything queues. Never a half-sent blast. |
| Analytics history | 30 days | 1 year | 2 years | Unlimited | A range that straddles the cutoff is trimmed; one entirely outside it is refused. |
- Contacts
- Marketing emails
- Analytics history
You see nothing at all until you look. A form fill, an import or a reader sign-in past the cap still succeeds, and the contact is still stored. What changes is that the contact does not appear in the contact list, in search, in a segment, in a group or in an export — and asking for it directly returns the same 404 as a contact that never existed.
The only place the state is announced is the meter on Settings → Plans & billing, which turns red and adds a banner: “280 captured — 30 locked above your 250 limit”. Administrators also get an email.
You see a refusal, at the moment you try to send, before anything is queued. The send returns 402 with reason: "quota_exceeded" and feature: "marketingEmail", and the CMS shows a message naming the limit and how much of it you have used.
Nothing partial happens. The batch is rejected in full — no half-sent list, no partially delivered blast to reconcile afterwards.
You usually see nothing wrong, because the common case is silent: a date range that starts before your retention cutoff and ends inside it has its start moved forward to the cutoff, and the chart draws from there. The numbers are correct for the window that was actually queried, not the one you asked for.
A range lying entirely outside the window is refused with 402, feature: "analyticsRetention". In the date picker, presets that cannot fit inside your window render disabled with an upgrade affordance rather than returning an error.
Your usage meters
Two cards sit at the top of Settings → Plans & billing: Identified contacts and Marketing emails.
Each card shows a title, a usage line and a bar. The usage line reads 1,052 of 10,000 for contacts and 12,000 of 50,000 this month for email; on an unlimited plan it reads 12,004 · Unlimited instead, and the bar is rendered but invisible so the two cards keep the same height. Over the limit, the bar turns red and the usage line goes bold red.
The numbers are live counts taken when the page loads. There is no cache and no refresh interval to wait for — reload the page and you have the current figure.
{
"tier": "growth",
"contacts": { "captured": 1052, "visible": 1052, "locked": 0, "limit": 10000 },
"marketingEmails": {
"used": 12000,
"limit": 50000,
"periodStart": "2026-09-01T00:00:00.000Z",
"periodEnd": "2026-10-01T00:00:00.000Z"
}
}That is the shape returned by GET /billing/usage, which the meters render. A null limit means unlimited. The endpoint is gated on company:read rather than on billing access, deliberately: these are non-personal aggregates, and someone who cannot buy anything should still be able to establish that the workspace is over its limit before they go asking. Reaching the billing screen itself does require billing access — see Billing and developer access.
Your meters always read your workspace’s own stored limits, which is what makes the next three sections true regardless of any negotiated arrangement.
Identified contacts
This is the most-misunderstood mechanic in Leed, and it is worth reading slowly, because the intuitive model is wrong in two separate ways.
Capture never stops
A form submission, a CSV import, a capture through an MCP client and a reader signing in on your documentation site all record the contact. Every time. There is no plan on which capture is refused, and no point at which a form starts throwing away submissions.
The consequence is that your captured total — the number the meter shows — can and does exceed your plan’s number. 280 of 250 is a normal, expected state, not a corrupted one.
What “locked” means
The cap is applied on read. Leed keeps a visibility window of the oldest contacts by creation time, as many as your plan allows, and everything past that window is locked.
visible = min(captured, quota)
locked = max(0, captured - quota)
A locked contact is absent from the contact list, from search, from segments, from contact groups, from exports and from the shortcode journey lookup. It also cannot be emailed — recipient resolution runs through the same window, so a locked contact can never end up in a send.
Requesting a locked contact directly returns 404 — the same answer as a contact that never existed. Leed does not confirm that a locked record is there, on purpose: the alternative would be an endpoint that reports the existence of records the workspace is not entitled to read.
flowchart TD
A["Form fill, import, MCP capture<br/>or reader sign-in"] --> B["Contact is stored<br/>capture NEVER blocks"]
B --> C{"Inside the visibility window?<br/>oldest N by creation time,<br/>N = your plan's contact quota"}
C -- "Yes — visible" --> D["Appears in lists, search,<br/>segments, groups, exports<br/>and email recipients"]
C -- "No — locked" --> E["Absent everywhere.<br/>Direct request returns 404,<br/>indistinguishable from<br/>a contact that never existed"]
E -. "upgrade widens N" .-> D
Unlocking
Upgrading widens the window, and locked contacts become visible immediately. There is no reprocessing step, no re-import and no queue to drain — the records were never modified, only filtered out of reads, so raising the number restores them in the next request.
The banner on the meter says exactly that, and it is literal: “Locked contacts are still captured and unlock instantly when you upgrade.”
The one place Leed fails open
Every plan gate in Leed fails closed: if the workspace record cannot be read, the request is treated as unentitled. The contact cap is the single deliberate exception. If the workspace record cannot be read, the contact quota resolves to unlimited rather than to zero.
The reasoning is that the failure modes are not symmetrical. Wrongly granting a paid feature for the duration of a storage blip is a billing inconvenience; wrongly locking a customer out of their own contact database for the same blip is a data emergency. Nothing about that asymmetry applies to features, which is why they behave the other way.
A locked contact is invisible everywhere contacts appear — Contacts describes the record and what a visible one shows you, and a large CSV can push you past the cap in one go, so Importing contacts is worth reading before a bulk load.
Marketing emails per month
The email allowance is the one quota that stops you rather than hiding something from you.
The block is pre-send
A blast whose recipient count would cross the allowance is rejected in full, before anything queues. Leed compares the month’s usage plus the size of the batch you are about to send against the allowance, and refuses the whole thing if the sum is over. There is no partial send, no half-drained list and nothing to reconcile afterwards.
The rejection is a 402 with reason: "quota_exceeded" and feature: "marketingEmail", carrying your allowance and how much of it you have used:
| Quota | Where you hit it | HTTP status | Body identifies | What the CMS shows you |
|---|---|---|---|---|
| Marketing email | The send step, before the batch queues | 402 | feature: "marketingEmail", plus quota and used | A message naming the limit and your usage, with an upgrade route if you hold billing access |
| Analytics retention | An analytics query whose whole range predates your window | 402 | feature: "analyticsRetention", quota = your retention days, used = how far back you asked | A disabled preset, or a chart that refuses the range |
Contacts are absent from that table because they never produce an error. That is the whole distinction between a visibility cap and a hard block.
What counts
The meter covers the current UTC calendar month, and resets at the start of the next one. A row counts if it was sent this month, or if it is still unsent on a batch that was created this month. The second half exists so that two blasts fired back to back cannot both pass the check against a stale count and overshoot the allowance between them — an accepted batch reserves its recipients immediately.
Free is zero
The Free allowance is 0, and Leed renders that as a gate rather than as a meter — there is no bar, because a bar at zero would suggest a quantity you could exhaust.
The card reads “Marketing email is available on the Starter plan” over “Not included on the Free plan — upgrade to send marketing email.” This is a different state from a paid workspace that has used its whole allowance, which keeps its bar and gets “You’ve used all 5,000 marketing emails for this month” over “Further sends are blocked until your next cycle — upgrade for a bigger allowance.”
Analytics history
Retention is a query window, not a retention policy in the usual sense.
Nothing is deleted
Analytics data is never removed. Every event your site captures is stored on every plan, indefinitely, and retention is applied at the moment you run a query as a cutoff on how far back that query may reach.
What the picker does at the edge
Two different things happen depending on how your range sits against the cutoff:
- A range that straddles the cutoff has its start silently moved forward to the cutoff. You get a chart, and it is correct for the window that was queried rather than for the one you typed. This mirrors what the date picker does client-side, so the two agree.
- A range lying entirely outside the window is refused with
402, naminganalyticsRetention, and carrying your retention days as the quota and how many days back you asked for as the usage.
In the picker itself, presets that cannot fit inside your window render disabled with an upgrade affordance instead of failing when you select them. Date ranges and retention covers the picker, the presets and the comparison period in full.
t_{cutoff} = now - retentionDays \times 86400000
The 365-day rule is not a plan limit
Every plan, Enterprise included, is capped at a 365-day span in a single analytics query. Exceeding it returns 400 with the message “Range cannot exceed 365 days” — not a 402, and no upgrade will change it.
Growth’s two-year retention therefore still needs two queries to cover two years, and unlimited retention on Enterprise still means at most a year at a time. This catches people precisely because it looks like a plan wall and is not one; it sits alongside the upload ceilings and batch sizes in Limits that are not plan limits.
The over-limit email
A daily check compares every workspace’s usage against its stored limits and emails every active Administrator when one is over. The reminder repeats every 7 days until usage is back inside the plan, and stops as soon as it is.
| Trigger | Subject line | Who receives it | Repeat |
|---|---|---|---|
| Contacts captured above the cap | <Workspace> has passed its contact limit on Leed | Every active Administrator | Every 7 days until usage is back inside the plan |
| The month’s marketing email allowance exhausted | <Workspace> has reached its monthly marketing email limit on Leed | Every active Administrator | Every 7 days until the allowance resets or the plan changes |
The two thresholds are deliberately different, and the difference is visible. Contacts notify when usage genuinely exceeds the cap, because capture is unconditional and can overshoot. Marketing email notifies when usage reaches the allowance, because the send gate stops it from ever passing — an exhausted allowance is already the “further sends are blocked” state the nudge exists for. The email check also requires an allowance above zero, which is why a Free workspace never receives an email-limit notice: it has nothing consumable to exhaust.
Every one of these emails closes with the same line, and it is the reason the notice goes to Administrators rather than to whoever crossed the line: “Upgrading requires billing permission on your account. If you don’t manage billing, ask your account admin to upgrade the plan.”
When a limit does stop you, the error you see and the prompt that accompanies it are described in When a feature is gated. Raising a limit means changing plan, which is Managing your subscription.
Bespoke limits
An Enterprise workspace can carry negotiated numbers that differ from the published table. Your meters read your workspace’s own stored limits rather than the tier defaults, so a negotiated allowance shows its real number everywhere usage is displayed and everywhere it is enforced.
There is no marker on the screen saying a number is bespoke — it is shown as your number, because it is. If you need one changed, talk to us.