Security and data
What is protected, and where.
This page describes the access model and the data the product handles. It states what the interface does, not a certification or an uptime commitment.
Server-side sessions
Sign-in state belongs to a session the server issues and validates. The browser holds an opaque cookie, not a token the interface can inspect or rewrite.
Authorization off the client
The console hides and disables what your role cannot use. That is a usability layer — the API is the boundary that decides whether a request is allowed.
Scoped API keys
Keys are issued per account with an explicit permission scope, so a key embedded in a deployment can be restricted to inference or revoked on its own.
Recorded changes
Administrative changes to plans, subscriptions and content are recorded with the acting identity and a before/after summary.
How API keys are handled
Rules that apply to every key issued from the console.
- Revealed once at creationThe full key is shown when it is created. Afterwards the console keeps only the masked form, so a key that was not saved has to be rotated rather than recovered.
- Scoped, not sharedEach key carries its own permission set and last-used state. Issue one per environment or per service so a single leak does not span everything you run.
- Revocation is immediateRevoking a key stops it from authenticating. The key stays in the list marked as revoked, so the history of what was issued is not lost.
- Never client-side secretA key belongs on your server or in your secret manager. Anything shipped to a browser bundle is readable by whoever loads the page.
Data the service handles
Grouped by what it is used for and how long it is relevant.
Payment data
What the product deliberately does not hold.
Card numbers and security codes are entered on the payment provider's own page. The billing screens in this product display a reference to the stored payment method — brand, last four digits, expiry — and never accept raw card data.
[email protected]Where enforcement lives
The interface and the API have different jobs.
The console presents state and blocks actions a role cannot take. It is not a security boundary: anything it hides has to be refused by the API too.
The API authenticates the caller, checks the entitlement against the account's current plan, and only then forwards the request upstream.
A limit shown in the product is a statement about your plan. It is enforced where requests are authenticated, not by the page that displays it.
What this page does not claim
Stated plainly.
- PrByCode does not display compliance badges, audit certificates or a security rating on this site.
- No uptime percentage or response-time guarantee is published here. Current component health is on the status page, which reports state rather than a promise.
- Retention windows depend on the deployment's storage configuration. Exact periods are confirmed in the agreement for your account rather than asserted here.
Reporting a security issue
One channel, monitored directly.
Send a description of the issue and, where possible, the request that reproduces it. Include a way to reach you. Do not include live API keys, customer prompts or payment data in the report — rotate any credential you believe was exposed first.
https://api.prbycode.com/v1