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

# Subject not supported

> This endpoint does not accept the `X-Exo-Subject` selector.

This page is the resolution target of the RFC 9457 `type` URI on every `subject_not_supported` problem body: `https://docs.get-exo.com/errors/subject_not_supported`.

**HTTP status: `400` Bad Request**.

```json theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}}
{
  "type": "https://docs.get-exo.com/errors/subject_not_supported",
  "title": "Subject not supported",
  "status": 400,
  "detail": "This endpoint does not support the X-Exo-Subject selector.",
  "code": "subject_not_supported",
  "requestId": "req_9f2c41ab7d0e5c18",
  "suggestedAction": "Remove the X-Exo-Subject header. To act for a provisioned subject, use a subject-aware endpoint (for example /v1/retrieve, /v1/condition/* or /v1/ingest)."
}
```

## Why it happens

The brain family, the coding-session ingestion family and `POST /v1/purge` scope by the credential's own user rather than by a selector. Accepting the header there and ignoring it would read from, or write to, the wrong partition.

Exo refuses rather than ignores, so a mistake surfaces at the call instead of as mysteriously wrong data later.

## How to fix it

* Remove the header on these routes.
* To act for a provisioned subject, use a subject-aware route. Retrieval, search, ingest, recall, graph, condition, settings and export creation all run the subject seam.

## Related

* [`subject_not_provisioned`](/errors/subject_not_provisioned)
* [Errors](/platform/errors) for the envelope and the full catalogue