> ## Documentation Index
> Fetch the complete documentation index at: https://docs.starfort.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Request format

> The Starfort Guard API request body: messages array, processType, additionalData, and optional Opticon tracing, with examples (Starfort v1.4 docs)

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

```json theme={"dark"}
{
  "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.                                                                   |

<Note>
  The request uses **camelCase** (`processType`). These are the field names the production API expects.
</Note>

### `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](/en/v1.4/api/errors).
* 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](/en/v1.4/api/errors).

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](/en/v1.4/admin/monitoring-opticon) 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](/en/v1.4/admin/monitoring-opticon).

For multimodal content (images, audio, files, video) inside `messages`, see [Multimodal inputs](/en/v1.4/api/multimodal).