updateUserMeta
Update a metadata record's value by meta_id, requiring the parent database name and record ID to avoid unintended modifications across tables.
Instructions
Update a metadata record - Update an existing users_meta record's value by meta_id. Fields omitted are untouched. Writes live data.
IDENTITY RULE - (database, database_id) is ONE atomic compound identity, not two fields. ALWAYS confirm BOTH match the intended parent BEFORE updating. A users_meta row's identity is (database, database_id, key). The same numeric database_id routinely belongs to UNRELATED rows on different parent tables. Never use a meta_id blindly from an unscoped list - always either (a) getUserMeta(meta_id) first and inspect database+database_id, OR (b) obtain the meta_id from a listUserMeta whose results have been CLIENT-SIDE filtered to the intended database+database_id pair. Misidentifying a row silently overwrites unrelated resource metadata.
Use when:
Changing a metadata value on any BD table row that was previously created via
createUserMeta.For
list_seo(web page) EAV fields, useupdateWebPagedirectly — the wrapper auto-routes them throughusers_metafor you. ThisupdateUserMetaendpoint is for changing existing values on OTHER BD tables (e.g.users_data,subscription_types,data_postscustom meta), or for the rare case where alist_seoEAV field doesn't persist afterupdateWebPage— file that as a wrapper bug rather than working around it here.
Workflow: find the meta_id by calling listUserMeta with filter database=<table>, database_id=<parent_id>, key=<field>. Then call this endpoint with meta_id, value, and the same database + database_id you used for lookup. If no row exists, the row cannot be created via this endpoint — see Rule: users_meta writes. Never guess meta_id; 404 = stop, not retry.
Required: meta_id, value, database, database_id. All four - always. The identity pair (database, database_id) is enforced at the schema level to prevent cross-table corruption.
See also: listUserMeta (find the meta_id by filter), deleteUserMeta (remove permanently).
Returns: { status: "success", message: {...updatedRecord} } - the full updated record after changes applied.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| meta_id | Yes | ||
| value | Yes | ||
| database | Yes | **REQUIRED** - parent table name this meta row attaches to (e.g. `list_seo`, `users_data`, `subscription_types`, `data_posts`). MUST match the `database` value stored on the row being updated. Hard safety rule: the same `database_id` number can exist across multiple parent tables. Scoping with `(database, database_id)` together prevents cross-table metadata corruption. See **Rule: users_meta identity**. | |
| database_id | Yes | REQUIRED - PK of the parent record this meta row is attached to. MUST match the `database_id` value stored on the row being updated. Same safety rule as `database`: the same numeric ID can belong to unrelated rows on different tables. | |
| _clear_fields | No | Column names to clear to empty string. Available on every `update*` operation. Works on base columns AND EAV/`users_meta` rows (rows preserved with `value=""`). To actually clear a field you MUST use this parameter — sending the field with `""` alone is a no-op (BD drops empty values). To remove a `users_meta` row entirely, use `deleteUserMeta`. See **Rule: Clearing fields**. Example: `_clear_fields: ["h2", "hero_link_url"]`. |