OGuardAI
API Reference

API Changelog

Breaking changes, new endpoints, and deprecations by version for the OGuardAI API

Track breaking changes, new endpoints, and deprecations across OGuardAI API versions.


Versioning Policy

The OGuardAI API follows semantic versioning. All endpoints are served under the /v1 prefix. Within a major version:

  • Patch releases (e.g., 0.1.1) contain bug fixes only. No API changes.
  • Minor releases (e.g., 0.2.0) may add new endpoints, new optional fields, or new enum values. Existing endpoints and fields remain backward-compatible.
  • Major releases (e.g., 1.0.0) may introduce breaking changes to existing endpoints, request/response schemas, or authentication mechanisms.

New optional fields in responses are not considered breaking changes. Clients should ignore unknown fields.


v0.1.0 -- Initial Release

Date: 2026-04-01

Status: Current

This is the first public release of the OGuardAI API. All endpoints, request/response schemas, and error codes documented below represent the initial API surface.

No breaking changes yet -- this is the first release.

Core Endpoints

MethodPathDescription
POST/v1/transformTransform text, replacing detected entities with semantic tokens
POST/v1/rehydrateRestore semantic tokens in LLM output to original values
POST/v1/detectDetect entities in text without transforming
POST/v1/evaluate-policyEvaluate policy against entities (dry run)
GET/v1/healthRuntime health check (always public)
GET/v1/capabilitiesList entity types, languages, and detectors (always public)
GET/v1/diagnosticsRuntime diagnostics -- detector mode, config, versions (Admin scope required)
GET/metricsPrometheus metrics endpoint (Admin scope required)

Streaming Endpoints

MethodPathDescription
POST/v1/transform/streamStreaming transform via Server-Sent Events (SSE)
POST/v1/rehydrate/streamStreaming rehydrate via SSE

File and Image Endpoints

MethodPathDescription
POST/v1/transform/fileTransform an uploaded file (multipart form data)
POST/v1/transform/imageTransform text detected in an image via OCR
POST/v1/rehydrate/fileRehydrate an uploaded file (multipart form data)
POST/v1/redact/imageRedact PII regions in an image

Batch Endpoints

MethodPathDescription
POST/v1/batch/transformBatch transform multiple inputs in one request
POST/v1/batch/detectBatch detect entities in multiple inputs

RAG Endpoints

MethodPathDescription
POST/v1/rag/ingestIngest a document for RAG with PII protection
POST/v1/rag/queryQuery RAG index with PII-safe context
POST/v1/rag/contextRetrieve RAG context chunks (tokenized)
POST/v1/rag/answerGenerate a RAG answer with automatic rehydration
POST/v1/rag/deleteDelete ingested RAG documents

Revocation Endpoints

MethodPathDescription
POST/v1/revokeRevoke a single entity (makes it permanently non-restorable)
POST/v1/revoke/bulkRevoke multiple entities in one request
GET/v1/revocations/countGet the count of revoked entities

Admin Endpoints

MethodPathDescription
POST/v1/admin/policy/validateValidate policy configuration files (requires admin scope)

Authentication

Two authentication methods are supported:

  • API Key: Send in the X-API-Key header
  • JWT Bearer Token: Send in the Authorization: Bearer <token> header

Five authorization scopes are available: transform, rehydrate, detect, policy, admin. When auth is disabled (default for development), all endpoints are accessible without credentials.

Request/Response Format

  • All request and response bodies use JSON (Content-Type: application/json), except file upload endpoints which use multipart form data.
  • Transform accepts three input modes: input (plain text), input_json (structured JSON), or input_messages (OpenAI-format chat messages). Exactly one is required.
  • Session state is returned as an encrypted blob in transform responses and must be passed back to rehydrate requests.
  • Six restore modes are supported: full, partial, masked, formatted, abstract, none.

Error Codes

CodeHTTP StatusDescription
GUARDAI_INVALID_INPUT400Malformed request, missing fields, type mismatch
GUARDAI_BAD_REQUEST400Generic bad request
GUARDAI_AUTH_FAILED401Missing or invalid credentials
GUARDAI_POLICY_DENIED403Policy blocks the entity type or insufficient scope
GUARDAI_SESSION_EXPIRED410Session TTL elapsed or sealed blob integrity check failed
GUARDAI_PAYLOAD_TOO_LARGE413Request exceeds configured size limit
GUARDAI_OUTPUT_BLOCKED422Output guard blocked response due to hallucinated PII
GUARDAI_TOKEN_REPAIR_FAILED422Token repair could not resolve tokens in LLM output
GUARDAI_DETECTION_FAILED500Detector service down or detection failed
GUARDAI_INTERNAL_ERROR500Unexpected server error

Known Limitations in v0.1.0

  • RAG and revocation scopes: The rag and revoke authorization scopes are not yet implemented. RAG and revoke endpoints currently require one of the existing scopes (typically transform or admin).
  • Streaming error recovery: If a detection error occurs mid-stream, the SSE connection is closed. Partial results are not recoverable.
  • Batch size limits: Batch endpoints accept a maximum of 100 items per request. This limit is not yet configurable.

Upcoming Changes

The following changes are planned for future releases. These are not commitments -- they reflect current development direction and may change.

v0.2.0 (Planned)

  • New scopes: Dedicated rag and revoke authorization scopes for RAG and revocation endpoints.
  • Configurable batch limits: Server-side configuration for maximum batch size.
  • Webhook notifications: Optional webhook delivery for async batch completion events.

v1.0.0 (Planned -- Stable Release)

  • API stability guarantee: All v1 endpoints will follow strict backward compatibility. Breaking changes will only occur in v2.
  • Potential breaking changes from v0.x:
    • Error code prefix may change from GUARDAI_ to a shorter form.
    • The entities array in transform responses may move to a separate diagnostic endpoint to reduce default response size.
    • Session state format may change (existing sealed blobs from v0.x will not be compatible with v1.0).

These potential breaking changes will be documented in detail before the v1.0.0 release, with migration guidance.