Core concepts
Normalize Panicly product vocabulary before implementing or operating it
Current docs should prefer the new product names: Sentry Mode, Network Controls, Region Rules, Workspace Audit, Requests, Usage, Credits, Rules, Models, and Insights.
The top-level operator boundary. It owns plan tier, members, projects, billing state, credits, audit events, and global controls.
A protected unit of traffic inside a workspace. It owns environment, Panicly API keys, provider connection, thresholds, and request history.
The credential your app sends to Panicly. Keys are project-scoped, returned once, and stored as prefix plus hash.
The upstream provider credential Panicly uses for approved requests. Current storage allows one provider key per project.
The public emergency stop control. The database column still uses the older panic_mode name.
Paid workspace capacity used after included monthly request volume is exceeded. The repo still mixes “requests”, “logs”, and “credit-backed logs”, so docs must define this carefully.
Why does plus appear in code if the plan is called Pro?
The internal tier key is plus, but the public-facing plan name is Pro. Public docs should use Pro and mention plus only in internal implementation contexts.
Plan limits are request-based, while credit packages include fields named logAllowance. Public usage docs should describe included monthly requests separately from credit-backed capacity.
Not today. The schema currently has a unique provider-key row per project, so docs should not promise multi-provider project configuration.