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.
Use these endpoints to manage labels programmatically — for example, when a platform customer stores many downstream rules in a single Moonbounce account. Authenticate with an API key for that account. There is no tenant or customer field on these requests; labels live flat in the authenticated account. Exact request and response shapes are in the API Reference.

​
Labels

A label is a mutable container: a name, an optional description, and an optional dataset of examples. Examples attach to the label, not to a version, so every version of a label is measured against the same accumulated set. A label may have zero versions. That is a valid state — you can create a bare label, attach examples later, and add rule text when you are ready. Cross-account IDs return NOT_FOUND.

​
Create

Creating with only name is supported. On create, description is stored on the initial version when initial_version_text is also sent. To set the label’s own human-facing description, PATCH the label after create.

​
Patch is metadata only

PATCH cannot create, mutate, or delete versions. Unknown JSON fields such as rule text are ignored. To change a rule, create a new version.

​
Delete does not cascade versions

DELETE fails with FAILED_PRECONDITION if the label has any versions (including soft-deleted versions). Versions are immutable and have no delete RPC. Archive the label in the dashboard when it still has versions you need to keep.

​
Label versions

A version is the evaluable artifact: the rule text and its compiled form. Versions are immutable. There is no update, delete, or promote/publish-as-live operation. There is no “current” version — evaluation always uses an explicit version ID that you store on your side. List and get-label return versions in stable order: sequential_version ascending (oldest first), then version ID. A label with zero versions returns an empty list. When a label has more versions than fit in one page, responses include next_page_token; continue with GET /v1/labels/{labelId}/versions. Reading a version at any later time returns the same rule content and compiled form. Changing behavior means creating a new version and pointing your own customer → version ID mapping at it.

​
Evaluation

Evaluate by version ID, never by label ID:
label_version_ids is required. A label with no versions has nothing to evaluate; sending an empty label_version_ids list is rejected as invalid argument. See Integrating a Label.

​
Where to next

Integrating a Label

Evaluate content against published version IDs.

API Reference

Request and response shapes for every label endpoint.

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