REST API Reference
PhronEdge exposes a REST API for every operation available in the SDK, CLI, and Console. This reference is for non-Python clients, custom integrations, and automation outside the SDK.
Base URL: https://api.phronedge.com/api/v1
Enterprise self-hosted: Replace the host with your gateway URL (for example https://phronedge.yourbank.internal/api/v1).
Authentication
Most endpoints require the X-PhronEdge-Key header:
A small set of endpoints are Console-only and authenticate through the Console UI. These are called out explicitly.
A small set of endpoints require no authentication (public key discovery, gateway health). These are called out explicitly.
Rate limits
Requests may be rate-limited per tenant. When the limit is exceeded, responses return 429 Too Many Requests with a Retry-After header. Clients should implement exponential backoff on 429 responses.
Response format
All JSON responses use the following structure for errors:
Some endpoints return structured error objects:
---
Credentials
GET /auth/credential
Fetch the signed credential for an agent.
Headers:
Query parameters:
| Parameter | Type | Required | Description |
|---|---|---|---|
agent_id | str | No | Agent ID to fetch. Without this, returns the first available credential under your tenant |
Request:
Response (200):
Error responses:
| Status | Reason |
|---|---|
| 401 | Missing or invalid API key |
| 404 | No credential found. Sign a policy first |
POST /auth/keys/create
Create a new API key. Console-only endpoint.
API keys are provisioned through the Console at phronedge.com/brain, under API Keys in the sidebar. Click Create Key, optionally set a label, and copy the key immediately. It starts with pe_live_ and is shown only once.
API keys cannot be created programmatically from outside the Console. This is intentional. Key provisioning is a governance action and requires authenticated Console access.
---
Governance
POST /governance/build
Sign a policy. With deploy: false (default), returns the signed artifact for preview. With deploy: true, issues credentials and registers tools.
Headers:
Request:
The `deploy` field is critical:
| Value | Behavior |
|---|---|
false (default) | Policy is signed for review. No credentials issued. Tool calls using this policy will fail. |
true | Policy is signed, credentials are issued to every agent, tools are registered in the governance registry. Agents become governable immediately. |
Response (200, compliant):
Response (200, non-compliant):
Error responses:
| Status | Reason |
|---|---|
| 400 | Policy validation failed. Missing required tool fields (jurisdictions, permissions, data_classification) |
| 401 | Missing or invalid API key |
POST /governance/build (amendment flow)
To amend an existing policy, POST the updated policy to /governance/build with deploy: true. The Brain evaluates the diff against the currently signed policy. If compliant, old credentials are revoked and new credentials are issued.
Events anchored on successful amendment:
POLICY_AMENDEDPOLICY_DIFF_EVALUATEDCREDENTIAL_REVOKED(per agent whose credential was reissued)CREDENTIAL_REISSUED(per agent)
The previous policy remains in the immutable chain.
GET /governance/registry
Show all registered agents and tools for the tenant.
Response (200):
---
Agent Lifecycle
GET /tenant/agents
List all agents under the tenant.
Response (200):
POST /agent/{agent_id}/quarantine
Suspend an agent. All tool calls from this agent will be rejected at Checkpoint 1 until reinstatement.
Request:
Response (200):
Anchors AGENT_QUARANTINED to the chain.
POST /agent/{agent_id}/reinstate
Reinstate a quarantined agent. No-op on killed agents.
Request:
Response (200):
Anchors AGENT_REINSTATED to the chain.
---
Gateway
POST /gateway/proxy/{tool_name}
Governed tool call. Runs the 7-checkpoint pipeline. This endpoint is typically called by the SDK, but can be invoked directly.
Headers:
The X-Constitutional-Credential header contains the raw credential JSON obtained from /auth/credential.
Request:
Response (200, allowed):
Response (403, blocked):
POST /gateway/scan
Pre-scan text for PII and prompt injection. No credential required, only API key.
Request:
Response (200):
GET /gateway/status
Gateway health and session activity. No authentication required.
Response (200):
| Field | Description |
|---|---|
status | operational when the gateway is serving traffic |
active_sessions | Number of active agent sessions in the last window |
Additional implementation fields may appear in the response. Clients should not rely on any field beyond status and active_sessions.
---
Chain
GET /tenant/chain
Read audit chain events.
Query parameters:
| Parameter | Type | Default | Description |
|---|---|---|---|
limit | int | 50 | Number of events to return |
agent | str | none | Filter by agent ID |
type | str | none | Filter by event type |
since | int | none | Unix timestamp. Return events after this time |
Response (200):
GET /tenant/chain/verify
Recompute and verify chain integrity.
Response (200):
Response when break detected:
---
Signing Keys
GET /tenant/signing-key
Get the current active signing key metadata.
Response (200):
POST /tenant/signing-key/rotate
Rotate the signing key. Creates a new version, archives the previous. Console-only.
Key rotation is a privileged operation and is only available through the Console under Settings > Security > Rotate Signing Key. Rotating keys through an API client is intentionally not supported.
Effect on existing credentials: Existing credentials remain valid and verifiable under the previous key. New policies are signed with the new key. Re-sign policies to move agents to the new key.
GET /tenant/signing-key/{key_id}
Get metadata for a specific key version.
Response (200):
---
Public Key Discovery
GET /.well-known/phronedge/{tenant_id}/keys.json
Public signing keys for a tenant. No authentication required.
This is the verification surface. Auditors, regulators, and third parties can fetch the public keys and verify any signed policy or credential without PhronEdge being in the loop.
Response (200):
The status: "archived" keys remain published so that previously issued credentials can still be verified.
See the signing and verification guide for a complete independent verification example.
---
Signature Format
Every signed artifact (policies, credentials) contains a phronedge_signature field:
| Field | Description |
|---|---|
algorithm | Always ES256 (ECDSA P-256 with SHA-256) |
key_id | Which version of the tenant key signed this artifact |
value | Hex-encoded DER signature over the canonical JSON of the artifact |
Canonical JSON:
- Keys sorted alphabetically
- Whitespace removed
phronedge_signature,anchor_hash,anchor_txexcluded from the payload before signing
---
Error Reference
| Status | Meaning | Common causes |
|---|---|---|
| 200 | Success | Request accepted and processed |
| 400 | Bad request | Missing required fields, invalid data class, missing tool jurisdictions |
| 401 | Unauthenticated | Missing or malformed X-PhronEdge-Key header |
| 403 | Forbidden | Tool call blocked by a checkpoint. detail has structured block info |
| 404 | Not found | Credential does not exist, agent not registered |
| 409 | Conflict | Agent ID already exists, policy hash collision |
| 429 | Rate limited | Tenant-level rate limit exceeded. Check Retry-After header |
| 500 | Server error | Contact support |
| 503 | Service unavailable | Gateway temporarily down. Safe to retry with backoff |
---
Next steps
- Quickstart. End-to-end example
- SDK reference. Python client
- CLI reference. Command-line interface
- Signing and verification. Independent verification
- Enterprise deployment. Self-hosted gateway