"Update a deal field" sounds like a one-line task until the field silently refuses to change: the request returns success, the card shows the old value. The cause is almost always one of three things — the wrong method generation, the wrong field name format, or the wrong value shape. Here is how updating deal fields actually works in Bitrix24 (Alaio), from a raw REST call to a no-code automation rule.

Which method updates a deal field?

The current answer is the universal method crm.item.update: pass entityTypeId 2 (deal), the deal id, and a fields object containing only the fields you want to change — everything you omit stays untouched.

{"entityTypeId": 2, "id": 351, "fields": {"stageId": "C1:WON", "opportunity": 50000}}

The older per-entity method crm.deal.update still works and appears in most tutorials, but it belongs to the legacy generation: same fields, different naming. New integrations should default to crm.item.update — it covers deals, leads, contacts, companies and smart processes with one contract.

Why does the field not update?

The first suspect is letter case. The legacy API and the workflow designer write field codes in upper case: TITLE, OPPORTUNITY, UF_CRM_1721244707107. The universal API writes the same fields in camelCase: title, opportunity, ufCrm_1721244707107. Send TITLE to crm.item.update and it is ignored as an unknown key — successfully. If you want the universal method to accept the original UF_CRM_* names, pass useOriginalUfNames set to Y. The second suspect is the value shape: a list field expects the item id rather than its label, a date field expects a proper date format, and an invalid value returns CRM_FIELD_ERROR_VALUE_NOT_VALID naming the field. Where to look field codes up is covered in the CRM fields guide.

How do I update phone, email and other multifields?

Phones and emails live in the multifield array fm, and its update semantics trip everyone at least once: existing rows are addressed by their id — pass a row with an id to change it in place — while rows without a known id are added as new entries. Sending a "fresh" set of values without ids does not replace the old ones; it appends, and the deal's contact quietly grows duplicate phones. Read the current fm rows first, then update by id.

How do I update a field from a webhook?

For a one-portal integration you do not need an OAuth application: an inbound webhook gives you a URL that carries authorization in itself. Create it with the crm scope, and remember that the webhook acts with the rights of the employee who created it — if that person cannot see the pipeline, the call fails with an access error even though the token is valid. Method, id and fields go into the request exactly as above. Setting one up step by step is covered in the webhooks guide; if the response comes back with an error string instead of a result, the REST API error codes map tells you which side has to fix it.

How do I update deal fields without code?

Inside the portal, most field updates do not need REST at all — an automation rule on the stage does it. The stock "Edit item" rule covers one field with a static value. When several fields change at once, or values come from previous steps, the Update deal by ID rule from the Roboteka catalog takes a JSON object in the same camelCase format as crm.item.update and writes everything in one action. Emptying a field is its own case — an empty string does not clear lists, dates or multifields, so there is a dedicated Clear field rule that nulls any type correctly. To move a value across entities — say, copy the city from the contact into the deal — use Set related entity field, and to guard against blank critical fields before a stage change, Check field is not empty returns Y/N for a condition to branch on. An action inside the workflow is also the cheap answer to "should I wire up an external scenario for this": no tokens to refresh, no request limits to budget — the update runs where the deal lives.

What next

Start from the failure you actually have: wrong case — switch to camelCase or set useOriginalUfNames; duplicates in phones — update fm rows by id; access errors — check the webhook owner's rights. For everything that runs on a schedule of deal events rather than external calls, build it as workflow automation in Bitrix24 — the update rules above are ordinary blocks there. And if the block you need is missing, describe the task: Roboteka builds missing automation rules for free and ships them to the shared library.