Request format

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.

Inspection limits — enforced at a single point, the Guardian

Starting with v1.4, the inspection limits configured on the project (text length, file size) are enforced at a single point: the Guardian. The gateway merely passes the project’s limit values along; the Guardian applies the same limits to all content it sees — not just top-level inputs but text extracted from files and archive members. A limit violation therefore always surfaces as a consistent Guardian rejection, and the request is refused as an error. Separately, the platform has an intake ceiling on request-body size — an infrastructure guard independent of any setting. The project’s inspection limits are configured freely below it.

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.

Guard API

Batch API

Fields

`processType`

Message roles — every message is inspected

Inspection limits — enforced at a single point, the Guardian

Opticon tracing (optional)

​Fields

​processType

​Message roles — every message is inspected

​Inspection limits — enforced at a single point, the Guardian

​Opticon tracing (optional)

Fields

`processType`

Message roles — every message is inspected

Inspection limits — enforced at a single point, the Guardian

Opticon tracing (optional)