We are executing a large-scale migration of our SIP infrastructure. I developed a script utilizing the Platform API to programmatically update the properties of 150 External Trunks via the PUT /api/v2/telephony/providers/edges/trunks/{trunkId} endpoint. The objective is to bulk-update the inbound routing identifiers. However, every PUT request fails with a 409 Conflict error. The error message indicates an ‘Invalid Version’. I am passing the exact same JSON body that I received from a previous GET request. What is the correct method for handling versioning when updating trunk configurations?
During our migration from PureConnect, we encountered this exact API behavior. In Genesys Cloud, nearly all configuration endpoints implement optimistic concurrency control. When you execute the GET request, the response includes a version integer.
To successfully execute the PUT request, your JSON payload must explicitly include this exact version integer. If another user or system modifies the trunk between your GET and PUT requests, the version increments, and your PUT will be rejected with a 409 to prevent accidental overwrites.
You must extract the version from the GET response and append it to your PUT payload.
Hello! I manage three different organizations for staging and production. I want to add that when you do bulk updates across different environments, you must be very careful with the state of the trunk! You cannot update a trunk configuration if the trunk is currently in an ‘In-Service’ state! The API will reject the PUT request even if your version number is completely correct. You must first send a request to change the trunk state to ‘Out-Of-Service’, then you send your PUT request with the correct version to update the settings, and finally you put it back ‘In-Service’!
Ural requirement elegantly if you utilize the built-in models. However, if you are utilizing raw HTTP requests via the requests library, you must manually parse the JSON dictionary. A common programmatic error is failing to update the version integer within your script’s memory after the initial PUT.
If your script attempts a secondary update on the same trunk without executing a new GET request to retrieve the newly incremented version integer, the subsequent PUT will result in a 409 Conflict.