Usage Limits & Endpoint Expiration

Usage limits

Currently free. No account is required.

Anonymous and Developer are free. No credit card required.

Raw incoming body limit: 256 KiB for guests; 1 MiB for accounts. Oversized bodies return HTTP 413 and are not captured.

After expiry, ingestion and history access stop. Expired addresses cannot be reactivated. Account owners can renew active addresses to at least 7 days from the operation, without accumulating time. Renewals are unlimited and preserve the URL.

Request retention from receipt: 1 day for guests and 7 days for accounts, independently of endpoint lifetime. Expiry, deletion, count eviction or lost management access can end access earlier. Extending an address does not renew captures. Requests admitted before the correction keep their original 30-day deadline. New arrivals on existing endpoints follow the new policy. Claim and account deletion never change assigned deadlines. Periodic physical cleanup can be delayed.

Count caps apply to endpoints created after activation. Older endpoints remain count-uncapped, including after claim. Incoming quotas reserveadmitted arrivals before body read, including oversized bodies, disconnects, persistence failures and built-in tests. Reset is at midnight UTC. Guest endpoints share a creator-IP scope, including shared networks; accounts share one aggregate quota. Legacy guests temporarily use session or endpoint attribution. Clearing history, deleting endpoints or changing cookies does not reset quotas.

Creation and traffic may be restricted to prevent abuse. No guaranteed request rate is published. On HTTP 429, pause and follow Retry-After when present. Aggregate storage quota is unspecified. A verification challenge may be required at creation.

Deleting captures removes them from the active database. Deleting an endpoint also stops its address. Backup handling is separate.

Endpoint expiration

Expiration is the receiving address’s deadline, shown with timezone in the workspace. It stops ingestion and history access even if captured records have not reached retention age. Expired addresses cannot be reactivated; create a new endpoint and update the sender.

Signing in does not extend lifetime. An explicit extension by the signed-in owner of an active, unexpired endpoint keeps the URL and sets the deadline to at least the current extension window from the operation, without accumulating days.

Request retention

Count caps apply only to endpoints created after plan-policy activation; see the shared limits table above. Existing endpoints remain uncapped by count, including after claim. Claim adopts the account count cap for a capped guest endpoint. Count eviction can remove replay sources and ends access earlier than the age cutoff.

After plan-policy activation, incoming quotas count admitted arrivals before reading raw bytes, shared by guest creator-IP scope or across an account per UTC day. Oversized bodies, disconnects, persistence failures and built-in tests count. Clear, delete and cookie changes do not reset counters. Legacy guests use session or endpoint attribution. Admission 429 uses INCOMING_DAILY_LIMIT_REACHED with Retry-After; a configured 429 response is still captured. Admission-store failure returns 503. Independent safety limits apply. Aggregate storage quota is unspecified.

The published limits above are in effect. Existing endpoints above the current active-endpoint limit remain usable, but new creation and claims follow the current limit. Anonymous quotas are shared by creator IP, including users behind the same NAT. New admissions, including arrivals on existing endpoints, use the current retention periods shown above. Earlier captures keep their original 30-day deadline. Claim, renewal and account deletion never reset a capture deadline. Retention is measured from each request’s original receipt time, independently of endpoint lifetime or extensions. At the retention cutoff records become inaccessible. Periodic cleanup removes old records physically and can be delayed by downtime or backlog.

Retention does not promise access for that entire period: expiration, deletion or lost authorization may end access sooner. Explicit deletion removes captures from the active database; backup handling is separate.

History visibility

The workspace initially loads the latest 100 requests and has no older-page navigation. Search and list filters cover loaded records; reconnect refreshes latest saved history. A known selected request may load independently.

Export NDJSON can include matching accessible retained records beyond that page, subject to size/time bounds. It cannot bypass expiration, deletion or ownership requirements.

Traffic restrictions

Endpoint creation can require a challenge or be temporarily restricted. Daily incoming quotas are published in the limits table above; they do not guarantee a per-second request rate. Independent safety controls may restrict ingress; a saved custom 429 is also possible.

Pause on HTTP 429 and follow Retry-After when present. Do not rapidly recreate endpoints to work around restrictions. If current numeric limits cannot load, the static lifecycle guidance here remains available; retry loading limits before relying on a quota.