Resolved on October 26, 2026.
Summary Between 12:00 UTC 23th October and 16:00 26th October UTC, some requests to update a subaccount through our public API failed with a 400 error if they included the operation_type or products fields. The cause was an internal infrastructure change that moved some accounts to a new system for subaccount settings before that system supported these two fields. We reverted the change for all affected accounts, and updates are working normally again. Impact • Affected endpoint: PUT /v2/subaccounts/{subaccount_id} • Symptom: requests that included operation_type or products returned 400 "Not supported for this workspace." No changes from those requests were saved, including other fields sent in the same request. • Not affected: creating, listing, retrieving and deleting subaccounts; updates that did not include these two fields; live agents and calls. Root cause A recent update to how we process subaccount changes did not support the operation_type and products fields, so requests that included them were rejected. Our pre-release checks did not catch the change in API behaviour. Resolution We reverted the change for all affected accounts. Subaccount updates that include operation_type and products are now accepted and saved as expected. Prevention We are strengthening our checks so that changes cannot alter documented API behaviour without being caught before release. We are also reviewing the other subaccount fields to confirm they are not affected. What you need to do If you received a 400 error on a subaccount update during this window, please retry the request. The failed request saved nothing, so a retry is safe. We apologise for the disruption. If you have questions, please contact [email protected].
Update timeline
- resolved Oct 26, 2026, 03:17 PM UTC
Summary Between 12:00 UTC 23th October and 16:00 26th October UTC, some requests to update a subaccount through our public API failed with a 400 error if they included the operation_type or products fields. The cause was an internal infrastructure change that moved some accounts to a new system for subaccount settings before that system supported these two fields. We reverted the change for all affected accounts, and updates are working normally again. Impact • Affected endpoint: PUT /v2/subaccounts/{subaccount_id} • Symptom: requests that included operation_type or products returned 400 "Not supported for this workspace." No changes from those requests were saved, including other fields sent in the same request. • Not affected: creating, listing, retrieving and deleting subaccounts; updates that did not include these two fields; live agents and calls. Root cause A recent update to how we process subaccount changes did not support the operation_type and products fields, so requests that included them were rejected. Our pre-release checks did not catch the change in API behaviour. Resolution We reverted the change for all affected accounts. Subaccount updates that include operation_type and products are now accepted and saved as expected. Prevention We are strengthening our checks so that changes cannot alter documented API behaviour without being caught before release. We are also reviewing the other subaccount fields to confirm they are not affected. What you need to do If you received a 400 error on a subaccount update during this window, please retry the request. The failed request saved nothing, so a retry is safe. We apologise for the disruption. If you have questions, please contact [email protected].
Your product runs on more than Synthflow AI
Add the vendors you depend on and get one message when any of them reports trouble. Free for 3 vendors, no card.
Amazon Web Services