LLM-readable documentation index
ApiV3Generated

Entity Curation

Overview of the Entity Curation API

Hand off to an LLM

Curate the knowledge graph by transitioning entities through their review lifecycle and editing their metadata.

  • PATCH /v3/entities/{id} updates a single entity. Every field is optional but at least one is required:

    • status transitions curation state to approved or rejected (only from extracted/proposed; any other transition is 409 Conflict). Approving emits an entity_validated webhook; rejecting emits entity_rejected.
    • assignedTypeID sets (or, with the empty string, clears) the customer-assigned type that overrides the bem-inferred type.
    • canonical replaces the canonical surface form.
    • addSynonyms / removeSynonymIDs attach customer_defined synonyms or soft-delete existing ones (an extracted synonym cannot be removed — 409 Conflict).

    A merged-away entity id transparently resolves to its surviving canonical entity.

  • POST /v3/entities/bulk-validate transitions a batch of entities to approved or rejected in one request. Each row reports validated, skipped (not found / not authorized), or rejected-row (an illegal transition such as an already-terminal entity), alongside a summary.

On the dashboard (JWT) surface these actions additionally require the acting user to be an assigned reviewer for the entity's effective type, or to hold the admin role (or higher). On the API-key surface admin-key authorization applies and no per-user reviewer check is made.