> ## 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 — in the dashboard or
[over the API](/v2/managing_labels_via_api) — 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`**. Evaluation never takes a label ID;
a label with no versions has nothing to evaluate, and an empty
`label_version_ids` list is rejected.

## 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="Managing Labels via API" icon="code" href="/v2/managing_labels_via_api">
    Create labels and immutable versions programmatically.
  </Card>

  <Card title="Labels, Versions & Datasets" icon="layer-group" href="/v2/labels_versions_datasets">
    Revisit how versions and immutability work.
  </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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.