calls.create() (POST /call) and campaign create (POST /campaign, POST /v2/campaign) are retried by the SDK's default retry policy on any 5xx, 408 or 409, and on a connection dropped before the reply (httpx.RemoteProtocolError). Those errors can come back after Vapi has already started dialling: a gateway timeout, or a proxy losing the reply. POST /call takes no idempotency key, so the retry places a second call.

Against a local mock that dials and then answers the first POST /call with 502, one client.calls.create(...) on vapi 3.0.0 placed two calls to the same number, and the caller only got back the second call id. In production that means the customer's phone rings twice and the org pays for two calls.

Suggested fix: for the three call-placing endpoints, retry only on 429 or when the connection never opened (httpx.ConnectError), and leave every other request as it is.

Since the SDK is generated, I've opened a PR as a proof of concept, with tests, so the change can be carried over to the generator: see the linked PR.