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

# Integrating a Label

> Take a published label version to production: get a label version id, send it to the evaluate API, and reference an explicit, immutable version you roll forward through config.

<Note>
  This is Moonbounce's label-first experience. If you're looking for the
  policy-first experience, switch using the version selector above.
</Note>

Once you've crafted, tested, and published a label, the last step is
integration: classifying real content in production. The key fact to internalize
is that **you always evaluate against a specific published version** — and that
version is identified by a **`label_version_id`**.

## Get a label version id

Every time you publish, Moonbounce mints an immutable version with its own
`label_version_id`. That id is your handle into production. Because the version
it points to never changes, sending the same id always evaluates against the
same frozen snapshot — which is what makes your results reproducible.

## Send it to the evaluate API

To classify content you call the evaluate endpoint with one or more version
ids. The request accepts an array, **`label_version_ids`** (up to **10** per
request), so you can evaluate a piece of content against several labels at once.

```http theme={null}
POST /v1/labels/evaluate
```

Conceptually, the request carries the content you want to classify and the
version ids to evaluate it against:

```json theme={null}
{
  "content": { "...": "the content to classify" },
  "label_version_ids": ["label-version-id-1", "label-version-id-2"],
  "threshold": 0.5
}
```

See the [API Reference](/api-reference/labels/evaluate-labels) for the exact request and response shapes.

### SDKs

The SDKs expose this under their beta namespace. The method and field names
differ slightly per language:

| Language                | Method                              | Version ids field   |
| ----------------------- | ----------------------------------- | ------------------- |
| JavaScript / TypeScript | `client.beta.evaluateLabels(...)`   | `labelVersionIds`   |
| Python                  | `client.beta.evaluate_labels(...)`  | `label_version_ids` |
| Go                      | `client.Beta().EvaluateLabels(...)` | `LabelVersionIDs`   |

The request and response types are named `EvaluateLabelsRequest` and
`EvaluateLabelsResponse` across all three SDKs.

<CardGroup cols={3}>
  <Card title="JavaScript / TypeScript SDK" icon="js" href="/integrations_and_developer_tools/api-docs-sdks/javascript_typescript_sdk">
    See the `beta.evaluateLabels` example.
  </Card>

  <Card title="Python SDK" icon="python" href="/integrations_and_developer_tools/api-docs-sdks/python_sdk">
    See the `beta.evaluate_labels` example.
  </Card>

  <Card title="Go SDK" icon="golang" href="/integrations_and_developer_tools/api-docs-sdks/go_sdk">
    See the `Beta().EvaluateLabels` example.
  </Card>
</CardGroup>

## Managing versions in production

Evaluation always requires an explicit `label_version_id` — it never tracks the
newest version for you. That's a deliberate safeguard, and it shapes how you
roll out new versions.

<Note>
  You always pass an explicit `label_version_id` by design. Because evaluation
  never resolves "latest" on its own, editing or publishing a label in the web
  app can **never** change what your live production traffic evaluates against.
  Your production behavior only changes when you deliberately change the version
  id you send — nothing shifts under you.
</Note>

Store the `label_version_id` in your application **configuration** — a config
file or environment variable — rather than hardcoding it in your code. Adopting
a new version then becomes a config change, with no code edit or logic redeploy.
The recommended flow: publish a new version, test it against the label's
dataset, and once you're confident, update the version id in your config to roll
forward on your own schedule.

## Where to next

<CardGroup cols={2}>
  <Card title="Labels, Versions & Datasets" icon="layer-group" href="/v2/labels_versions_datasets">
    Revisit how versions and immutability work.
  </Card>

  <Card title="Building with Labels" icon="layer-group" href="/v2/building_with_labels">
    Back to the overview of the full loop.
  </Card>
</CardGroup>

***

## We'd Love to Hear From You

Whether you have a suggestion, feedback, or a bug to report, here are the best ways to get in touch:

* **In the App:** Use the **Feedback button** for direct suggestions.
* **On Slack:** Reach out to the team in your shared channel.
* **With your AM:** Talk to your dedicated account manager.
* **Via Email:** Send a message to [**support@moonbounce.io**](mailto:support@moonbounce.io).
* **Security, availability, or other incidents:** Use the in-app **Feedback button** or email [**support@moonbounce.io**](mailto:support@moonbounce.io). See [Customer Feedback](/feedback/customer_feedback) for what to include.