Rate limits

Monolith does not enforce per-second rate limits on the v1 API. What it does enforce — driven by your subscription tier — is a set of caps on resources created, plus light caching on read paths.

Tier-driven caps

Every Artifact and every Mark counts against the billing context that owns it. For organization-owned Marks, the organization’s tier applies; for personal Marks, the user’s tier applies.

Cap	Scope	Reset
`dailyArtifactLimit`	Artifacts per 24-hour window	Daily, at next UTC midnight
`lifetimeArtifactLimit`	Total Artifacts, ever	Never (raise by upgrading)
`maxMarks`	Marks owned	Never
`maxOrganizations`	Organizations owned	Never
`maxOrganizationMembers`	Members per organization	Never

A value of -1 on any cap means unlimited. The current numbers per tier are returned by the in-app /api/tier/limits endpoint and shown on the pricing page ; see Tiers & limits for the policy.

Cap exhaustion

When a cap is hit, the relevant create endpoint returns:


HTTP/1.1 403 Forbidden
Content-Type: application/json
 
{ "error": "Daily artifact limit reached", "code": "TIER_RESTRICTION" }

Branch on the TIER_RESTRICTION code. Daily caps reset at the next UTC midnight. Lifetime caps clear only on upgrade.

Read-path caching

GET /api/v1/marks (the Mark list) is cached server-side for 60 seconds per user. A Mark list change (new Mark, membership change) takes up to 60 seconds to surface for that user. All other reads are uncached.

Best practices

Batch local work, then submit. Compute fingerprints offline; create Artifacts sequentially or in moderate parallel (4–8 in flight is safe).
Watch for lastUsedAt drift. API key rotation doesn’t change lastUsedAt until the key is used.
Don’t poll Artifact status aggressively. A new Artifact transitions pending → submitting → submitted over seconds-to-minutes. Poll the per-fingerprint or per-Mark endpoint at most once every few seconds per Artifact.
Cache GET /api/v1/marks on your side too. Honour the implicit 60-second TTL — 1-second polls don’t return fresher data.