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

# Research a place

> Use place APIs to understand local civic actors, coverage, sources, and context.

## Overview

Places are the most useful lens for public civic discovery. A place lets a user
ask a concrete local question, inspect who appears, and understand whether the
available evidence is broad or thin.

Use place APIs when your workflow starts with a city, region, or local issue
rather than a known actor name.

For exact endpoint shapes, use the
[API reference](/docs/api/reference).

## Place keys

Atlas uses normalized place keys in the format `city,state` (lowercase, hyphenated):

| Place                 | Key                    |
| --------------------- | ---------------------- |
| Kansas City, Missouri | `kansas-city,missouri` |
| Boise, Idaho          | `boise,idaho`          |
| Garden City, Kansas   | `garden-city,kansas`   |

State-level queries use just the state name: `kansas`, `idaho`, `missouri`.

Use place keys in URLs after you have chosen the canonical place. Store the key
with any exported record so the result can be refreshed later.

## A good place-first workflow

<Steps>
  <Step title="Confirm the place">
    Resolve the canonical place record so the rest of the workflow uses the same
    key and display name.

    ```bash theme={null}
    curl "https://atlas.rebuildingus.org/api/places/kansas-city,missouri"
    ```
  </Step>

  <Step title="Find actors">
    Search entities inside the place, then narrow by issue area, actor type, or
    text only when the result set is too broad.

    ```bash theme={null}
    curl "https://atlas.rebuildingus.org/api/places/kansas-city,missouri/entities?issue_area=housing_affordability"
    ```
  </Step>

  <Step title="Check coverage">
    Use coverage to understand the shape of the local directory before drawing a
    conclusion from the actors that appear.

    ```bash theme={null}
    curl "https://atlas.rebuildingus.org/api/places/kansas-city,missouri/coverage"
    ```
  </Step>

  <Step title="Inspect sources">
    Use place or entity sources to keep the evidence attached to the local claim.

    ```bash theme={null}
    curl "https://atlas.rebuildingus.org/api/places/kansas-city,missouri/sources"
    ```
  </Step>
</Steps>

## Read coverage carefully

Coverage helps you understand what the data can support. High counts can point
to active local source coverage; low counts can point to a real local gap, a
taxonomy mismatch, or a search that needs a different issue area.

Use coverage before:

* Publishing a local actor roundup.
* Launching outreach from a place-based list.
* Starting a discovery run for missing source coverage.
* Comparing issue strength across cities.

Do not treat coverage counts as impact measurement. They describe Atlas's
source-backed records for a place, not the full civic reality of the place.

## Add place context only when it helps

Place profiles and issue signals are useful when context changes how a user
interprets a result.

Use them to answer questions like:

* Is the place record the one I meant?
* Which issues have visible source-backed activity?
* Where does the local evidence look thin?
* What context should travel with a brief or export?

Keep actor evidence separate from place context. A demographic profile can help
interpret a place; it does not prove that an actor works on an issue.

## Next steps

<CardGroup cols={2}>
  <Card title="Find source-backed actors" icon="users" href="/docs/api/guides/entities">
    Search actors and preserve the source trail.
  </Card>

  <Card title="Use issue taxonomy" icon="tags" href="/docs/api/guides/taxonomy">
    Choose the right issue area slugs before filtering.
  </Card>

  <Card title="Trust and provenance" icon="shield-check" href="/docs/resources/trust">
    Understand what local source evidence can and cannot prove.
  </Card>

  <Card title="API reference" icon="code" href="/docs/api/reference">
    Check exact place endpoint parameters and response schemas.
  </Card>
</CardGroup>