Introduction

Prompt Hub API Vault API Rule Engine API Manage Models API Scanner API

Product surfaces

In addition to the SDK-facing endpoints above, the Shield360 client ships an interactive OpenAPI reference at Settings → OpenAPI Spec (/openapi-spec). That catalog also covers:

• AI Analysis — GET/POST /api/chat/improvement/{spanId} for saved runs and streaming reviews of traces/spans
• Ask Otter — /api/chat/* for config, conversations, streaming messages, SQL execute, widgets, and usage
• Telemetry — logs, metrics, traces, exceptions, and span hierarchy APIs
• Scanner — POST /api/scanners/{id}/scan, GET /api/scanners, and GET /api/scanners/findings for Trustabl jobs and findings

See AI Analysis, Chat with Otter, and Scanner connectors for product docs.

Request context headers

Shield360 scopes data by Organisation → Project → Environment. Signal routing (latest) picks the connector for each signal from the active project + environment.

Authorization: Bearer <shield360-api-key>
x-shield360-organisation-id: <organisation-id>
x-shield360-project-id: <project-id>
x-shield360-environment: production

Non-SDK APIs (telemetry, Ask Otter, AI Analysis, Scanner, …)

Use signal routing headers only. Do not send x-shield360-database-config-id. The API key still binds a vault/credential database config (middleware injects x-database-config-id).

SDK-facing APIs (Prompt Hub, Vault, Rule Engine)

Prefer signal routing (project + environment) to resolve the intelligence ClickHouse that stores prompts, secrets, and rules. Existing SDKs that only send Authorization: Bearer … keep working via the API key’s bound database config. Those endpoints also accept an explicit x-shield360-database-config-id when it belongs to the same project as the key.

Authentication

All documented endpoints require an Authorization header:

Authorization: Bearer <api-key>

Manage Models UI pages also accept a signed-in Shield360 session in the browser. The public pricing export requires no auth.