# Legacy search

Source: https://capacms.com/docs/legacy/search

Full-text search across a project with /v2/api/search and /v3/api/search.

```bash
curl 'https://cdn.capacms.com/v2/api/search?q=preview' -H "x-api-key: $CAPA_KEY"
```

```json
{
  "data": [
    { "id": "61001acc-e032-48cb-aeff-0f2d0bb69e6b", "title": "A Preview You Can Trust" },
    { "id": "7dd101af-5a84-4d46-8c52-f2227ec42f82", "title": "Pages Are a Map, Not a Tree" },
    { "id": "49583221-3d95-440a-9ea0-962100e1629d", "title": "The Edit Is the Product" }
  ],
  "meta": { "total": 3, "totalPages": 1, "currentPage": 1, "limit": 50,
            "hasNextPage": false, "hasPrevPage": false }
}
```

Search is full text with typo tolerance (`q=previw` finds the same three),
ranked by relevance. It covers every model marked **Searchable Model** in the
admin, which a new model is by default. Each hit is the entry id and its
`title` value, or `""` when the entry has no `title` field.

| Parameter                   | Default     | Range               | Notes                                                                                                      |
| --------------------------- | ----------- | ------------------- | ---------------------------------------------------------------------------------------------------------- |
| `q`                         | required    |                     | trimmed. Empty or blank answers `200` with no results. Missing answers `500`                               |
| `size`                      | `50`        | 1 to 500            | results per page. Above 500 is 500. `0` or text is 50                                                      |
| `page`                      | `1`         | 1 and up            |                                                                                                            |
| `modelNamespace`            | all models  |                     | limit hits to one model. An unknown namespace finds nothing                                                |
| `extended`                  | off         |                     | any non-empty value, even `false`, returns full entries. Leave it out or empty to get `{ id, title }` hits |
| `depth`                     | `0`         | 0 to 4              | with `extended`, as on a list                                                                              |
| `nestedLimit`, `nestedPage` | `100`, `1`  |                     | with `extended`, as on a list                                                                              |
| `structure`                 | `relations` | `relations`, `tree` | v2 only, with `extended`                                                                                   |
| `relatedFilters`            | none        |                     | with `extended`: JSON only. The `relationFilter.` form is not read here                                    |

A `pk_` key finds published entries only. An `sk_` key also finds drafts, and
matches their newest text.

Things to know before you build on it:

* **A published entry that has a newer, unpublished draft is not found by a
  `pk_` key.** Search indexes the newest version, and that version is a draft.
  The entry comes back once the draft is published or discarded.
* **With `extended`, `meta` stops describing the whole result.** `total` is
  the number of hits on this page and `hasNextPage` is `false`. Page through
  extended results by asking for the next `page` until one comes back shorter
  than `size`.
* **With `extended`, results are not in relevance order.** They come back in
  database order. Search without `extended` when order matters.
* Extended results carry the entry's full `dataModel` and a
  `lastUpdatedByUser` key that is always `null`. The key stays so existing
  parsers keep working. No editor's email, name or avatar is returned.
  `lastUpdatedBy`, the id of whoever last saved the entry, is still there.
* On `/v2/api`, an extended hit read with `depth=1` or more also carries
  internal keys that start with `_`, such as `_includedRelationIds: {}`.
  Ignore them. `/v3/api` removes them.
* Search responses carry no cache headers of their own.