From 2c606dd49e95039f27370bdbaafa1a1db51181ad Mon Sep 17 00:00:00 2001 From: Nicolas Fry Date: Fri, 9 Oct 2026 07:23:44 -0400 Subject: [PATCH] docs(python): create_signing_url never throws NotSignersTurn The API's only turn refusal is RecipientNotInTurn. The SDK still accepts NotSignersTurn for cross-SDK parity, so say it is reserved. Part of TurboDocx/Docs#213. --- skills/turbodocx-sdk/references/python.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/skills/turbodocx-sdk/references/python.md b/skills/turbodocx-sdk/references/python.md index cae8fd9..b98139a 100644 --- a/skills/turbodocx-sdk/references/python.md +++ b/skills/turbodocx-sdk/references/python.md @@ -448,7 +448,7 @@ Returns `documentId` plus `recipients`; each entry has `recipientId`, `name`, `e - `'pending'` — an earlier signer hasn't finished; `embedUrl` is `None`. Re-mint with `create_signing_url` once earlier signers complete. - `'completed'` — they already signed; `embedUrl` is `None`. -This is one underlying condition seen from both methods: `create_signing_url` **throws** `RecipientNotInTurn` / `NotSignersTurn` / `RecipientAlreadySigned`, while `create_embedded_signature` **catches exactly those codes** and degrades them to `pending` / `completed`. Any other error propagates. An SMS-OTP recipient with no `phone` (E.164) raises `PhoneRequiredForSmsOtp` before the send. +This is one underlying condition seen from both methods: `create_signing_url` **throws** `RecipientNotInTurn` / `RecipientAlreadySigned`, while `create_embedded_signature` **catches exactly those codes** and degrades them to `pending` / `completed` (it also accepts `NotSignersTurn`, a reserved code the current API never returns). Any other error propagates. An SMS-OTP recipient with no `phone` (E.164) raises `PhoneRequiredForSmsOtp` before the send. ### The three identity modes