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.

​
Publishing from plain rule text

text is single-label DSL by default. If your rules are written in plain language and you do not want to construct DSL, set text_format and send the rule as-is:
The rule is stored as a single signal. Quotes, newlines, and backslashes in your text are preserved. Everything else is unchanged: the same immutability, the same duplicate handling, and the same response shape. Omitting text_format, or sending TEXT_FORMAT_DSL, keeps the DSL behavior. Reading the version back returns the compiled DSL, not the text you submitted, so keep your own copy of the original rule if you need it. 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.