**Environment:** eSignature REST API v2.1, Demo (`account-d.docusign.com` / `demo.docusign.net`, editor host `apps-d.docusign.com`).**Use case:** We embed the **Template Edit View** in our web app (in an `<iframe>`) so users can tag/adjust fields on a template.---**How we create the edit view (server side):**```POST /restapi/v2.1/accounts/{accountId}/templates/{templateId}/views/editAuthorization: Bearer <JWT-grant app token, scope: "signature impersonation">{ "returnUrl": "https://<our-return-page>", "viewAccess": "template", "frameAncestors": ["https://<our-app-origin>"], "settings": { "startingScreen": "Tagger" }}```The returned `url` (a `.../managed_token/v1/redeem?slt=...` link) is set as the `<iframe src>`. The redeem redirects to `apps-d.docusign.com/send/prepare-template/{templateId}/add-fields`, and the embedded editor then uses a **managed token** for all its API calls.---**The problem — what works vs. what fails, all in the same embedded session:**- `GET .../documents/1/tabs` (load tabs) → **200** ✅- `POST .../templates/{id}/documents/1/tabs` (ADD a prefill tab) → **201** ✅- `PUT .../templates/{id}/recipients/1/tabs` (edit a RECIPIENT tab) → **200** ✅- `PUT .../templates/{id}/documents/1/tabs` (MOVE/UPDATE an existing prefill/sender tab) → **401** ❌The failing response:```{ "errorCode": "AUTHORIZATION_INVALID_TOKEN", "message": "The access token provided is expired, revoked or malformed." }```So with the **same managed token, in the same session**: adding a prefill tab (POST) works, but updating an existing one (PUT) fails with 401.---**Network evidence — three calls to the SAME `documents/1/tabs` on the SAME template; only the token differs:**```(A) ADD prefill tab POST .../documents/1/tabs Bearer <managed token> => 201 ✅ body: { prefillTabs: { textTabs: [ { new tab, no tabId } ] } }(B) UPDATE prefill PUT .../documents/1/tabs Bearer <managed token> => 401 ❌ (THE FAILURE) body: { prefillTabs: { textTabs: [ { tabId: <existing>, xPosition: 236, yPosition: 63 } ] } }(C) UPDATE prefill PUT .../documents/1/tabs Bearer <full session> => 200 ✅ body: (byte-for-byte identical to B)```(B) and (C) are the identical request except the bearer token. (A) proves the managed token *can* write `documents/1/tabs` for **create**; only **update** (B) fails.---**Token comparison (decoded claims; raw tokens omitted):**Managed edit-view token — the one that gets 401:```TokenType : 18amr : ["managed_token", "interactive"]scp : ["signature"]mtclms : Source "POSTTemplateEditView", ViewAccess 3, TemplateId <redacted>(time-valid, not expired)```Full user session token — the SAME PUT succeeds with this (used when editing the same template directly on docusign.com):```TokenType : 5amr : ["refresh_token"]scp : [44 scopes incl. signature, account_read, settings_service_write, ...]```A JWT-grant app token (`scope: signature impersonation`) also returns **200** on the same PUT from our backend.---**What we have ruled out:**- **Token expiry** — the failing managed token is time-valid (often newer than tokens that succeed on other calls).- **Verb / endpoint scope** — `POST` to the same endpoint succeeds with the managed token; only `PUT` (update existing) fails.We also tried other `viewAccess` values: only `template` (ViewAccess 3) and `envelope` (ViewAccess 2) are accepted (`templateReadonly` / `full` → `INVALID_REQUEST_BODY`). In `envelope` mode the managed token is even more restricted — even `GET .../documents/1/tabs` returns 401.---**Questions:**1. Is the Template Edit View managed token (`createEditView`, `viewAccess: template`) intentionally **not authorized to update existing document-level prefill (sender) tabs** via `PUT .../documents/{documentId}/tabs`, while it *is* allowed to `POST` (create) them? If so, is this documented?2. Is there a **supported configuration** (a `viewAccess` value, a `settings.*` flag, or a different embedded view) that lets embedded users **reposition/edit existing prefill tabs**?3. If embedded prefill/sender-tab editing is unsupported, what is the **recommended pattern** — manage prefill-tab placement server-side with an account/JWT token, use a Sender/Correct view, or anchor-based placement?Happy to share the account ID, template ID, full request/response, and a correlation/transaction ID of a specific failing call privately.
**Notes: Kindly check attached videos, I reproduced this 2 ways, inside my app + using docusign examples. check the video with detailed network inspections for the steps.**
Back to Docusign.com

