Request format - Starfort

POST https://bastion-guardian-api.starfort.io/v1/guard/api with Content-Type: application/json.

{
  "messages": [
    { "role": "user", "content": "Please share John Smith's number 010-1234-5678." }
  ],
  "processType": "input",
  "opticon": {
    "trace_id": "your-trace-id",
    "session_id": "your-session-id",
    "user_id": "end-user-id",
    "metadata": { "any": "value" },
    "tags": ["your-tag"]
  }
}

Fields

Field	Type	Required	Notes
`messages`	array	yes	OpenAI Chat Completions-style messages.
`processType`	string	yes	A label the Guardian declares (commonly `input` / `output`). Case-insensitive. Must be one the Guardian supports.
`opticon`	object	no	Tracing hints. Omit entirely if you don’t need tracing.

The request uses camelCase (processType). These are the field names the production API expects.

`processType`

processType is a free-form label the Guardian defines — not a fixed enum. Most Guardians declare input (guard a request on the way in) and output (guard a model response on the way out), but a Guardian can declare any names it supports.

Case-insensitive — the value is trimmed and lowercased before matching, so "input", "INPUT", and " Input " are the same call.
The value must be one the called Guardian supports. If it isn’t, the call is rejected during pre-validation and the error message lists the supported process types. See Errors & states.
Some process types are policy-not-required (the Guardian declares no compatible policy types for them). A call with such a process type carries no Guard Policy, so there is nothing to evaluate — it returns PASS without inspection.

Message roles — every message is inspected

The Guardian evaluates everything you send, regardless of role. PII rules run on each content part of every message — user, assistant, system, and any other role — so sensitive data in an assistant reply or a system prompt is masked or blocked just like user input. Topic policies evaluate the request once as a whole, over the merged conversation, system messages included. There is no role that skips inspection: send exactly the conversation you want guarded.

Opticon tracing (optional)

The opticon object attaches tracing metadata to the trace Starfort records for the call:

Field	Purpose
`trace_id`	Your own trace identifier (auto-generated if omitted).
`session_id`	Groups related calls into a session.
`user_id`	End-user identifier.
`metadata`	Arbitrary key/values.
`tags`	Your tags; Starfort also auto-adds action and policy tags.

Alongside your fields, Starfort enriches each trace automatically: the trace name is the Project Guardian’s name; the root action, each policy_type:action / policy_name:action, and the API key’s name are added as tags; processType, the masked API-key identifier, and the resolved Model Configuration go to metadata; and per-policy detection counts are recorded as scores. On a key conflict the system value wins. Tracing is best-effort and never blocks the call. See Opticon monitoring. For multimodal content (images, audio, files, video) inside messages, see Multimodal inputs.

​Fields

​processType

​Message roles — every message is inspected

​Opticon tracing (optional)

Fields

`processType`

Message roles — every message is inspected

Opticon tracing (optional)