PesaGuard DocsGetting started
Create an API key Pilot-scoped
Credentials are issued with the pilot team, scoped to the integration that needs them. A key is never "full access" — it is a scope, an expiry and a tenant, nothing more.
What a credential carries
| Property | Behaviour |
|---|---|
scopes | Explicit resource scopes, e.g. reconciliation:read, transactions:export. Access outside the scope returns 403. |
tenant | Every query the key runs is bounded by this tenant at the database layer. |
expiry | Short-lived by default, with rotation metadata. |
last_used | Recorded, so dormant credentials are visible in review. |
| Storage | Hashed at rest. The raw value is shown once at issuance. |
Handling rules
- Keep credentials out of source control. The infra README requires the deployment's
.envto be ignored — the same rule applies to your integration's secrets. - One credential per integration. A shared "team key" makes rotation pointless.
- Rotate on a schedule and immediately on suspicion. Revocation takes effect at once; there is no grace window to exploit.
- Audit entries never contain secret material — tokens are excluded from logs by design.
Issuance is manual today
There is no self-serve key rotation endpoint in the pilot. Ask the team that runs your deployment; treat the request like a production change, with the scope list written down first.
Next
- First request — put the credential to work.
- Tenant isolation — what your key's tenant bounds.