Skip to main content
This is Moonbounce’s label-first experience. If you’re looking for the policy-first experience, switch using the version selector above.
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. 
POST /v1/labels/evaluate
Conceptually, the request carries the content you want to classify and the version ids to evaluate it against: 
{
  "content": { "...": "the content to classify" },
  "label_version_ids": ["label-version-id-1", "label-version-id-2"],
  "threshold": 0.5
}
See the API Reference 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:
LanguageMethodVersion ids field
JavaScript / TypeScriptclient.beta.evaluateLabels(...)labelVersionIds
Pythonclient.beta.evaluate_labels(...)label_version_ids
Goclient.Beta().EvaluateLabels(...)LabelVersionIDs
The request and response types are named EvaluateLabelsRequest and EvaluateLabelsResponse across all three SDKs.

JavaScript / TypeScript SDK

See the beta.evaluateLabels example.

Python SDK

See the beta.evaluate_labels example.

Go SDK

See the Beta().EvaluateLabels example.

​
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.
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.
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

Labels, Versions & Datasets

Revisit how versions and immutability work.

Building with Labels

Back to the overview of the full loop.

​
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.
  • Security, availability, or other incidents: Use the in-app Feedback button or email support@moonbounce.io. See Customer Feedback for what to include.