Skip to main content
PATCH
Update an entity by ID

Overview

Updates an existing entity’s attributes and data. When the entity has an assigned risk matrix whose triggers include entity_updated, the rules engine may run automatically after the update (respecting optional matrix watchFields and skipRulesExecution). Real-time update events and audit trails are always recorded.

Endpoint

Authentication

Requires a valid API key in the Authorization header:

Path Parameters

string
required
The gu1 ID of the entity to update

Request Body

All fields from the create schema are available except type (entity type cannot be changed). All fields are optional - only include the fields you want to update.
string
Update the entity’s display name
External ID cannot be updated with this endpoint. Use Change external ID (POST /entities/change-external-id) with a mandatory reason (min. 5 characters). PATCH update routes ignore externalId in the body.
string
Update tax identification number
string | null
Update root-level contact email. Omit to leave unchanged; send null to clear.
string | null
Update root-level contact phone. Omit to leave unchanged; send null to clear.
string | null
Root nationality (ISO 3166-1 alpha-2 when stored). Omit to leave unchanged; null clears. Updating entityData person/company nationality may refresh the root field when sent together.
string
Update ISO 3166-1 alpha-2 country code
object
Update custom attributes (merges with existing top-level keys).Attributes are stored verbatim — the shape you send is the shape you get back on read.Uncategorized (flat): scalar or array values at the top level.
Categorized (nested): a top-level object groups its inner keys under that category. The object key is the category — use identifier-safe keys (e.g. contact, category_billing) so they work in rule paths.
Rules and webhooks read the stored shape: flat keys as attributes.phone, nested keys as attributes.contact.phone.
object
Update type-specific data (merges with existing entityData)
string
Entity lifecycle status (active, inactive, blocked, under_review, suspended, pending_verification, expired, rejected, deleted).Required with reason: Any status change must include reason for audit.
string
Reason for the update (especially important when changing status to blocked or rejected).Required when: Changing status to blocked, rejected, or suspended.Best practice: Always provide a reason for audit trail purposes, even when not required.
boolean
default:"false"
When true, automatic status updates are disabled for this entity: risk matrix rules and automation actions such as set_entity_status do not change status. Manual updates via this endpoint (or the UI) still apply.
  • Default: false (rules and automations may change status when configured).
  • Set to false explicitly to remove the lock and allow automatic status changes again.
  • Does not disable risk score calculation or other rule side effects—only status writes from rules/automations.
Required with reason: if changeStatusManual changes (enable or disable), send reason in the same PATCH body for audit (same as status changes).

Risk Matrices

Assign or replace which risk matrices apply to this entity. Same semantics as Create entity (riskMatrixId / riskMatrixIds).
string | string[] | null
Legacy: one UUID, an array of UUIDs, or null to clear all assigned matrices. When riskMatrixIds is sent non-empty, it takes precedence over this field.
string[]
Preferred for multiple matrices: ordered list of UUIDs belonging to your organization. Send [] (or riskMatrixId: null) to remove all assignments. Each UUID must exist in your org; otherwise the API returns 400 with code INVALID_RISK_MATRIX.
boolean
default:"false"
When true, skips automatic risk matrix evaluation on update even if assigned matrices include the entity_updated trigger.
Updating matrices assigns them on the entity record only; assignment alone does not run rules.Rules on update: If the entity has at least one assigned matrix with trigger entity_updated, and skipRulesExecution is not true, the API runs the rules engine after a successful field change. Matrices may optionally restrict this with watchFields (only run when listed paths change, e.g. email, attributes.clientTypes). The entity.updated webhook includes rulesExecutionSummary when rules ran or were skipped with a reason.The same body fields apply to Update by external ID and PATCH /entities/by-tax-id/{taxId}.

Response

object
The updated entity object with all current values
object
The entity state before the update (for audit/comparison)
The HTTP response body does not include rulesExecutionSummary. When rules run (or are skipped), summary details are attached to the entity.updated webhook payload.

Behavior

When you update an entity, the system:
  1. Records the change in the audit trail with before/after values
  2. Runs risk matrices when assigned matrices include entity_updated, skipRulesExecution is not true, and optional watchFields on the matrix match changed paths
  3. Emits real-time event to notify connected clients of the update
  4. Fires entity.updated webhook with changes and optional rulesExecutionSummary

Examples

Update Person Income

Update Company Information

Update Custom Attributes Only

Update Transaction Status

Response Example

Error Responses

404 Not Found

400 Bad Request - Invalid Data

401 Unauthorized

500 Internal Server Error

Use Cases

Update After KYC Verification

Progressive Profile Enrichment

Transaction Resolution

Best Practices

  1. Partial Updates: Only send the fields you want to change - no need to send the entire entity
  2. Monitor Re-evaluations: Check the returned evaluation ID to track risk score recalculation
  3. Audit Trail: Use the previousEntity in the response to maintain change history
  4. Real-time Sync: Updates emit WebSocket events for real-time UI synchronization
  5. Idempotency: Safe to retry - updates with same data will not create duplicate events

Next Steps