# Resolve a website to a code

> Map a roster or court website you already know to the neutral jurisdiction code to use in a search. A one-directional lookup: your site in, our code out.

- **HTML:** https://offendersearch.app/docs/criminal/resolve
- **Base URL:** https://api.offendersearch.app
- **Authentication:** `X-API-Key` request header
- **OpenAPI:** https://offendersearch.app/openapi.json · https://offendersearch.app/openapi.yaml
- **Criminal reference as markdown:** https://offendersearch.app/docs/criminal.md

## Your site in, our neutral code out

You may already know the **roster or records website** for a place you care about — a county sheriff's inmate page, a court portal — without knowing our jurisdiction code for it. The resolver maps a website to that code, so you can drive a search from a URL. It is **one-directional**: your site in, a neutral code out. It never returns, logs, or reveals our own data sources.

## POST /v1/criminal/resolve

**Authentication:** `X-API-Key`. Available on every account exactly like search — no entitlement required. **Not metered** — a cheap in-memory lookup that consults no data source, so it emits no `criminal_call`. A request with neither `website` nor `websites` returns `422 no_website`.

```bash
curl -X POST "https://api.offendersearch.app/v1/criminal/resolve" \
  -H "X-API-Key: $OFFENDERSEARCH_KEY" -H "Content-Type: application/json" \
  -d '{ "website": "https://sheriff.examplecounty.gov/inmates" }'
```

One website → one result object. A list of `websites` → a `results[]` wrapper, one entry per input, in order.

```json
{
  "input": "https://sheriff.examplecounty.gov/inmates",
  "supported": true,
  "code": "TX-DALLAS",
  "state": "TX",
  "county": "Dallas",
  "note": "equivalent data available for this jurisdiction"
}
```

| Field | Type | Meaning |
| --- | --- | --- |
| `input` | string | Your website, echoed back verbatim so you can line results up with inputs. |
| `supported` | boolean | `true` = we have equivalent data and `code` is populated. `false` = not covered. |
| `code` | string \\| null | The **public jurisdiction code** to use in a search. `null` when unsupported. |
| `state` | string \\| null | The jurisdiction's state, when we can identify it — even for an unsupported site. |
| `county` | string \\| null | The jurisdiction's county, when we can identify it. |
| `note` | string | A plain-language explanation — e.g. `"equivalent data available for this jurisdiction"` or `"Baldwin, AL is not currently covered"`. |

> An unsupported site is `supported: false` with a plain-language reason — **not** an error. Only a request with no site at all is a `422 no_website`.

## Using a website inline in a search

You don't have to resolve first. `query.website` **scopes** a cached search to the resolved jurisdiction; `live.websites` **live-verifies** the resolved jurisdictions, exactly as if you had listed their codes. Whenever a search resolves a website, the response carries a top-level `resolution[]` array so you can see which code each site mapped to.

---

## Related

- Previous: [Jurisdictions & codes](https://offendersearch.app/docs/criminal/jurisdictions.md)
- Next: [Async live jobs & polling](https://offendersearch.app/docs/criminal/async.md)
- Index: [Criminal Search API reference](https://offendersearch.app/docs/criminal.md)
