feat(credentials): keyless Snowflake, Microsoft app-only and Google keyless, GitHub and Bitbucket tokens, DocuSign JWT (#9869)

* feat(credentials): keyless Snowflake connections through workload identity federation

A Snowflake connection can now trust Sim's OIDC issuer instead of holding a
programmatic access token. Sim signs a short-lived token (audience
snowflakecomputing.com) for the credential's own random subject; the customer
creates a SERVICE user with WORKLOAD_IDENTITY = (TYPE = OIDC ISSUER SUBJECT).

- Save verifies by minting a token and running the identity statement at the
  pinned account host through the guarded egress path; Snowflake's refusals
  keep the shared codes (invalid_credentials, site_not_found,
  provider_unavailable). Subjects bind to their creator like AWS/Databricks.
- Runtime: the resolver returns authStyle 'snowflake-workload-identity' for a
  keyless credential, and the tools and selectors send Bearer WIF.OIDC.<token>
  with the WORKLOAD_IDENTITY_FEDERATION token type. authStyle and domain are
  authoritative on every Snowflake tool, so a caller can no longer choose the
  token type or steer the account host of a saved credential.
- PAT credentials resolve and verify exactly as before.
- Connect dialog offers the keyless service user with the CREATE USER
  statement; it falls back to the token dialog where keyless is unavailable.
- Docs: Snowflake connections page with keyless setup, troubleshooting, and
  the 60-minute Snowflake key cache on signing-key rotation.

* fix(snowflake): run Cortex Analyst SQL with the resolved credential and reopen keyless reconnects as keyless

Cortex Analyst's "run the SQL" went through a nested snowflake_execute_sql
call carrying the already-resolved token and host. With authStyle and domain
now authoritative, the executor cleared both before the nested call, so it
failed for every credential (and a keyless token would have been sent as a
PAT). The generated SQL now runs as one guarded statement request built from
the parent call's credential-derived host, token, and token type, through the
same requestTarget egress the tool transport uses, with redirects refused.

The Snowflake connect dialog opened every reconnect on the programmatic
access token. The workload-identity prepare call now takes the reconnected
credential and reports whether it is keyless (only to an admin of that
credential in the same workspace), and the dialog opens on that mode.

Docs: the 60-minute wait applies before signing with a new key; removing the
old key needs 10 minutes with keyless Snowflake connections.

* fix(snowflake): cancel Cortex Analyst's generated SQL with the run

The generated SQL used to run as a nested tool call, which inherited the run's
abort signal; running it directly dropped that. postProcess now receives the
executor's effective abort signal as an optional fourth argument (the same
signal the tool's own request used), and Cortex Analyst forwards it to the DNS
check, the guarded fetch, and the response read. Other tools' postProcess
hooks are unchanged.

* feat(credentials): saved GitHub personal access tokens and Bitbucket access tokens

GitHub: a saved personal access token credential (fine-grained or classic),
verified against api.github.com/user with the tools' own headers. GitHub's
workflow block authenticates with an inline token rather than OAuth, so it
follows the token-block pattern: github_v3 is the credential-only successor
of github_v2, which stays exactly as it was, marked legacy and hidden from the
toolbar. Every GitHub tool declares the optional saved-token policy; inline
tokens keep working. The GitHub App installation credential (Search) is a
separate service and is untouched: the Assistant still projects GitHub tools
onto the person's connected GitHub account, and Search policy now follows the
visible GitHub block (github_v3).

Bitbucket: a workspace, project, or repository access token as a second
option next to OAuth (the Linear pattern), verified by listing one repository
of the typed workspace on api.bitbucket.org; the slug is validated so it
cannot steer the path. List Workspaces needs a signed-in user, so it now
refuses a saved access token before any request.

Also: isHostNotFound no longer lets an outer error code mask ENOTFOUND on its
cause.

* fix(credentials): close wave 2a review findings on GitHub and Bitbucket tokens

- The GitHub token service is `github-token`, so it no longer shares an id
  with the GitHub sign-in provider: parseProvider and getProviderIdFromServiceId
  answer for sign-in exactly as before, and a token-only service is never
  marked connected from a sign-in account whose id prefixes it.
- Suggested connect rows offer each integration once and count it connected
  when any of its services' OAuth or service-account credentials is saved
  (GitHub's Search App and saved tokens share one integration).
- Assistant GitHub calls bind through the connected-account policy the
  Assistant projects (the person's github-repositories OAuth account) in the
  token resolver too, on both the ordinary and managed paths; workflow runs
  and saved workspace tokens are unaffected.
- Bitbucket verification reads one repository (`workspace/repository`), the
  request Atlassian documents for workspace, project, and repository access
  tokens alike; listing a workspace is not documented for repository tokens.
- prepare-workload-identity test uses the central credentials-access mock.

* feat(credentials): DocuSign JWT Grant credentials next to OAuth

A saved DocuSign credential that authenticates with JWT Grant (an
integration key, an impersonated user ID, the app's RSA private key, and an
environment), offered as a second option beside the existing OAuth
connection, which is unchanged.

The minter signs an RS256 assertion (iss = integration key, sub = user,
aud = the environment's authentication host without a scheme, scope
"signature impersonation"), exchanges it at that host's /oauth/token, then
reads /oauth/userinfo on the same host to bind the pinned account (or the
user's default) and returns its eSignature REST base. Both hosts come only
from the stored environment; a base_uri outside that environment's
docusign.net shape is never trusted with the token. GUIDs and the key are
checked before any request, and tokens are re-minted about 15 minutes
before they expire, as DocuSign advises.

DocuSign tools take the account base as an authoritative credential param,
so a caller can never supply it, and DocuSignClient skips its
deployment-host userinfo lookup when one is bound. OAuth tokens resolve
exactly as before.

Save-time failures map to consent_required (the connect modal shows the
exact consent URL for the key and environment) and account_not_found (a
pinned account the user does not belong to), alongside the shared
invalid_credentials and provider_unavailable codes.

* fix(credentials): close wave 2b review findings on DocuSign JWT Grant

- The DocuSign knowledge connector now honours a JWT Grant credential's
  bound account. The resolved token's instanceUrl reaches the connector as
  credentialInstanceUrl in the sync context (seeded on every path through
  syncContextForToken). The connector re-validates it with the same parser
  as DocuSignClient, lists and fetches from that account in the
  credential's environment, links envelopes to that environment's web app,
  and validates without asking the deployment host. A seeded value of the
  wrong shape fails closed. OAuth syncs are unchanged.
- RSA keys under 2048 bits are refused as invalid_credentials with copy
  that names the size, instead of jose's raw TypeError.
- A short expires_in no longer makes every call re-mint: the cached
  lifetime floors at six minutes while staying a minute under the real
  expiry.
- The connect modal shows the consent URL as a link with a copy button,
  and account_not_found says "pinned account" only when one was entered.

* feat(credentials): Microsoft Entra app-only credentials for Entra ID, SharePoint, Dataverse, and Dynamics 365

A saved Microsoft app credential (OAuth 2.0 client credentials) as an
additional option next to Microsoft OAuth, which is unchanged. One app
registration serves the four services whose tools run without a signed-in
user; Outlook, OneDrive, Excel, Word, Planner, and Teams never offer it and
token resolution refuses it for them (provider mismatch).

- Modes: client secret; certificate (PS256 client assertion with the
  certificate's x5t#S256 thumbprint, aud = the tenant token endpoint, 5-minute
  lifetime; key/certificate pairing, RSA size, and expiry checked before any
  request); keyless federated credential (a Sim workload-identity token for the
  credential's own subject, audience api://AzureADTokenExchange, subject bound
  to the saving user, refused if the app also accepts an unheld subject).
- The token resource comes from the tool's service, passed from the
  server-validated tool policy: Graph for Entra ID and SharePoint, the stored
  environment for Dataverse and Dynamics 365. Any other service is refused.
- The environment URL is stored on the credential (public-cloud Dynamics
  hosts, https root only). Dataverse tools take credentialType and instanceUrl
  as authoritative params; an app credential's request goes only to its own
  environment and a block environment that names another is refused. OAuth
  requests keep the block environment exactly as before. Dynamics 365 already
  matched instanceUrl against the block environment.
- Save check: a Graph token reading the app's own service principal (no
  permission needed), plus Dataverse WhoAmI when an environment is set. Entra
  AADSTS codes map to actionable copy; runtime failures keep the shared
  invalid_credentials / provider_unavailable split. Tokens cache per
  credential, resource, and stored-secret version in an LRU.
- Azure AD Reset password refuses app-only credentials: Graph does not
  support application permissions for resetPassword.
- Connect dialog with tenant ID, client ID, environment URL, and the
  issuer/audience/subject to paste; docs page with per-mode setup.

* fix(credentials): close wave 3 review findings on Microsoft app credentials

- SharePoint selectors (workspace and organization paths) and knowledge
  connectors now pass the service they resolve for (the selector's own
  serviceId, the connector's declared auth provider), so a Microsoft app
  credential browses SharePoint with a Graph token instead of being refused.
  The resolution option is renamed from toolService to service; it is only
  ever set from server-side policy.
- AADSTS700211 and 700212 are no longer mapped: Microsoft documents only
  70021 and 700213 for federated credential mismatches. Other keyless
  refusals still name the mismatch.
- DocuSign minter test mocks carry account_name, and the connector
  access-token test narrows its tokens with a guard instead of non-null
  assertions.

* feat(credentials): keyless Google Cloud credentials via Workload Identity Federation

A keyless mode of the existing Google service account credential
(google-service-account) for Google Cloud APIs. JSON-key credentials, their
connect flow, and their token minting are unchanged.

- Flow: Sim signs a short-lived token for the credential's own subject with
  aud = the customer's provider resource name
  (https://iam.googleapis.com/projects/<number>/locations/global/
  workloadIdentityPools/<pool>/providers/<provider>), exchanges it at
  sts.googleapis.com/v1/token (token-exchange, jwt subject token,
  cloud-platform scope, audience //iam.googleapis.com/...), then calls
  iamcredentials generateAccessToken for the service account with the tool's
  scopes and a 1h lifetime. Impersonation rather than direct federated access:
  some Cloud APIs reject federated tokens, and the service account keeps the
  same identity and roles a JSON key uses.
- Inputs validated against Google's documented formats before any request:
  numeric project number, pool/provider IDs (4-32 [a-z0-9-], no gcp-), and a
  user-managed *.iam.gserviceaccount.com email, so nothing can steer the STS
  audience or IAM URL. Requests never follow redirects.
- Scope: refuses domain-wide delegation (an impersonated user) and any service
  but BigQuery and Vertex AI before reading further or contacting Google, with
  a new shared unsupported_use code and copy pointing to a JSON key. Workspace
  blocks never offer the mode.
- Save check: STS exchange, impersonation, and tokeninfo (no IAM role or
  enabled API needed), plus a probe that a subject no credential holds cannot
  impersonate the service account. Subject bound to the saving user with the
  signed proof; kept across reconnects.
- STS/IAM failures map to actionable copy (provider settings, issuer
  reachability, the exact workloadIdentityUser binding) without Google's
  descriptions or any token; runtime keeps the invalid_credentials /
  provider_unavailable split. Tokens cache per credential, secret version, and
  scopes in an LRU.
- Per-credential audiences: audiences.ts gains google without a fixed
  audience; the setup response omits audience for it and reports a keyless
  reconnect. Connect dialog shows the issuer, audience, subject, and filled-in
  gcloud commands (pool, OIDC provider with attribute condition on the
  subject, IAM binding); docs section added.

* fix(credentials): close wave 4 review findings on keyless Google Cloud credentials

- Drop the tokeninfo check: a token from generateAccessToken already proves
  the provider accepted Sim's token and the impersonation binding, and
  tokeninfo puts a live token in a query string.
- Test that saving fails closed when the stray-subject pin probe hits an STS
  outage or an unreachable IAM endpoint.
- Pass --project=<project number> on all three gcloud setup commands, drop
  the unused Resource Manager API from the docs, and raise the shared
  validation error for an empty scope list.

* fix(credentials): keep Snowflake, Microsoft app, and Google keyless subjects unique

The subject-uniqueness scan from #9866 covered only AWS and Databricks. It now
also scans Snowflake, Microsoft app, and Google service account credentials,
so no two live credentials of an owner hold one keyless subject. Their keyed
secrets that carry no config (a Google JSON key, a Snowflake programmatic
access token) hold no subject and no longer read as unreadable. The three
keyless save paths report a newly bound subject so create checks it.

* fix(credentials): close round-1 CI and review findings on alt auth

- Knowledge connector tests expect the service now passed with Google
  service-account token requests; a new test proves a JSON-key mint signs the
  same request with or without it.
- Re-record the tool-registry-boundary baseline: the keyless Snowflake,
  Microsoft app, and Google modules add 5 modules behind credential-service,
  which tipped credit-usage past its allowance on top of staging's drift.
- Docs compatibility baseline: record the new code examples in the Google and
  Snowflake service account pages.
- Generate the Microsoft certificate test fixture at run time instead of
  committing a PEM key and certificate.
- A Microsoft app credential reconnect opens on keyless only when the stored
  credential is federated (the prepare step now reports it), like Snowflake;
  new connections still default to keyless.
- TSDoc on the Google project number, pool/provider ID, and service account
  email validators.

* fix(credentials): offer keyless Google setup only in a Google Cloud context

Reconnecting a keyless Google service account from a Workspace integration
(Gmail, Drive, ...) offered the keyless form, saving a credential that
integration can never use. The dialog now offers keyless only for a Google
Cloud service (new or reconnect) or on the credential's own page; from a
Workspace integration it explains the credential works only with BigQuery and
Vertex AI and does not save. The chat connect control passes its service so
it gets the same gate.

* test(credentials): match the stable part of the subject-in-use refusal

Author: waleedlatif1

apps/docs/components/ui/icon-mapping.ts

@@ -481,6 +481,7 @@ export const blockTypeToIconMap: Record<string, IconComponent> = {
   generic_webhook: Webhook,
   github: GithubIcon,
   github_v2: GithubIcon,
+  github_v3: GithubIcon,
   gitlab: GitLabIcon,
   gitlab_v2: GitLabIcon,
   gmail: GmailIcon,

apps/docs/content/docs/integrations/aws-credentials.mdx

@@ -65,9 +65,9 @@ Generate a key with `openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:204
 To rotate the signing key without failed runs:
 
 1. Set the new key as `WORKLOAD_IDENTITY_PREVIOUS_KEY` and redeploy (including any background workers that run workflows). Sim publishes it but keeps signing with the current key.
-2. Wait at least 5 minutes, so every cached copy of the published keys includes the new one.
+2. Wait at least 5 minutes, so every cached copy of the published keys includes the new one. If any keyless [Snowflake connection](/integrations/snowflake-service-account#keyless-service-user) exists, wait 60 minutes instead: Snowflake caches an issuer's keys for up to an hour.
 3. Swap them: set the new key as `WORKLOAD_IDENTITY_SIGNING_KEY` and the old key as `WORKLOAD_IDENTITY_PREVIOUS_KEY`, and redeploy everything that runs workflows.
-4. Once every instance signs with the new key, wait 5 more minutes, then remove `WORKLOAD_IDENTITY_PREVIOUS_KEY`.
+4. Once every instance signs with the new key, wait 5 more minutes (10 with keyless Snowflake connections, whose tokens last that long), then remove `WORKLOAD_IDENTITY_PREVIOUS_KEY`.
 
 Without a signing key, the keyless option is unavailable and access keys work as usual.
 

apps/docs/content/docs/integrations/bitbucket-service-account.mdx

@@ -0,0 +1,66 @@
+---
+title: Bitbucket access tokens
+description: Connect Bitbucket Cloud to Sim with a workspace, project, or repository access token instead of a personal account
+---
+
+import { Callout } from '@/components/ui/callout'
+import { Step, Steps } from '@/components/ui/steps'
+
+Connect Bitbucket Cloud with an access token when a workflow should act as an integration rather than as the person who connected it. An access token belongs to a workspace, project, or repository, not to a user, so it keeps working when people leave and its reach is limited to what it was created for.
+
+Bitbucket shows actions taken with the token (comments, merges, pipeline runs) under the token's name.
+
+## Prerequisites
+
+Admin access to the workspace, project, or repository the token is for. Workspace access tokens require a Bitbucket Cloud Premium plan; project and repository access tokens do not.
+
+## Create the access token [#creating-the-access-token]
+
+<Steps>
+  <Step>
+    Open the repository, project, or workspace settings in Bitbucket Cloud and go to **Access tokens**
+  </Step>
+  <Step>
+    Click **Create access token** and give it a name (e.g. `Sim workflows`) — this is the name Bitbucket shows on everything the workflow does
+  </Step>
+  <Step>
+    Select **Repositories: Read** (`repository`). Add **Pull requests**, **Repositories: Write**, or **Pipelines** scopes for the actions the workflow takes
+  </Step>
+  <Step>
+    Create the token and copy it right away — Bitbucket shows it only once
+  </Step>
+</Steps>
+
+<Callout type="warn">
+A repository access token can only reach its repository, and a project access token only the repositories in its project. Treat the token like a password; Sim encrypts it at rest.
+</Callout>
+
+## Add the access token to Sim [#adding-the-access-token-to-sim]
+
+<Steps>
+  <Step>
+    Open **Integrations** from your workspace sidebar
+  </Step>
+  <Step>
+    Search for "Bitbucket" and open it, then click **Add to Sim** and choose **Add access token**
+  </Step>
+  <Step>
+    Paste the token and enter a repository it can read as `workspace/repository` (the `my-workspace/my-repository` in `bitbucket.org/my-workspace/my-repository`). For a repository access token, that is its own repository
+  </Step>
+  <Step>
+    Click **Add access token**. Sim verifies the token by reading that repository once, so the token needs the `repository` scope
+  </Step>
+</Steps>
+
+## Use the credential in workflows [#using-the-credential-in-workflows]
+
+Add a Bitbucket block and select the saved access token in the account dropdown, then choose the workspace and repository. The block calls `api.bitbucket.org` with the token, exactly as it does with a connected account.
+
+Two things need a signed-in account and do not work with an access token:
+
+- **List Workspaces** lists the workspaces of the person who connected the account, so Sim refuses to run it with an access token. Use a connected account for it.
+- The workspace picker lists a person's workspaces, so it cannot load them for an access token. Switch the workspace field to manual entry and type the slug.
+
+## Rotate tokens and handle permission failures
+
+If validation succeeds but an action fails, the token is likely missing that action's scope, or the repository is outside the token's project or repository. Access tokens cannot be edited after creation: create a replacement with the right scopes, update the credential in Sim, test the workflow, and then revoke the old token. See [Bitbucket's access token documentation](https://support.atlassian.com/bitbucket-cloud/docs/access-tokens/).

apps/docs/content/docs/integrations/bitbucket.mdx

@@ -12,9 +12,11 @@ import { ReferenceDetails } from "@/components/ui/reference-details"
 {/* MANUAL-CONTENT-START:intro */}
 Use [Bitbucket](https://bitbucket.org/) Cloud to read repositories, branches, commits, files, and diffs; create or delete branches; and manage pull requests and comments. Pipeline actions list runs and steps, start or stop runs, and retrieve step logs.
 
-Connect a Bitbucket account through OAuth. Triggers can start workflows on pushes, repository changes, build status updates, and pull request events; Sim manages their webhooks. For example, a workflow can read a failed pipeline's logs or review a newly opened pull request.
+Connect a Bitbucket account through OAuth, or a workspace, project, or repository [access token](/integrations/bitbucket-service-account). Triggers can start workflows on pushes, repository changes, build status updates, and pull request events; Sim manages their webhooks. For example, a workflow can read a failed pipeline's logs or review a newly opened pull request.
 {/* MANUAL-CONTENT-END */}
 
+Connection guides: [Access tokens](/integrations/bitbucket-service-account).
+
 ## OAuth scopes [#oauth-scopes]
 
 Sim requests these scopes when someone connects a Bitbucket account. For a self-hosted deployment, register your own app with the provider using the settings below. See [Integrations and OAuth](/platform/self-hosting/integrations-oauth) for setup.

apps/docs/content/docs/integrations/docusign-service-account.mdx

@@ -0,0 +1,88 @@
+---
+title: DocuSign JWT Grant
+description: Connect DocuSign to Sim with an integration key and RSA keypair that acts as one DocuSign user, instead of a personal OAuth connection
+---
+
+import { Callout } from '@/components/ui/callout'
+import { Step, Steps } from '@/components/ui/steps'
+
+Connect DocuSign with JWT Grant when a workflow should keep working without anyone signing in again. Sim signs a short-lived assertion with your app's RSA private key, exchanges it for an access token that acts as one DocuSign user, and repeats that every hour. DocuSign issues no refresh token for JWT Grant, so nothing expires as long as the key and the user's consent stay in place.
+
+Every envelope, template, and download runs as the impersonated user, with that user's DocuSign permissions. Use a dedicated user when you can.
+
+## Prerequisites
+
+- A DocuSign account in the environment you want: a free developer account (demo) or a production account
+- Admin access to **Apps and Keys** in that account, to create the integration key
+
+## Create the integration key [#creating-the-integration-key]
+
+<Steps>
+  <Step>
+    In DocuSign, open the **Apps and Keys** page and add an app. Give it a name (e.g. `Sim workflows`) and click **ADD**
+  </Step>
+  <Step>
+    Copy the integration key DocuSign assigns (a GUID)
+  </Step>
+  <Step>
+    Under **RSA key pair**, click **GENERATE RSA**. Copy the private key before you close the dialog, including its `BEGIN` and `END` lines. DocuSign masks it afterwards and can't show it again
+  </Step>
+  <Step>
+    Under **Redirect URI**, click **ADD URI** and enter the address you open Sim at (for example `https://sim.ai`). DocuSign requires a redirect URI for the consent step; Sim never uses what it receives there
+  </Step>
+  <Step>
+    Leave **User Application** set to **Yes** (the default) and click **SAVE**
+  </Step>
+</Steps>
+
+<Callout type="warn">
+The private key lets anyone holding it act as any user who has consented to this integration key. Sim encrypts it at rest and never shows it again. Treat it like a password.
+</Callout>
+
+## Find the user ID [#finding-the-user-id]
+
+The **Apps and Keys** page shows your **User ID** and **API Account ID**, both GUIDs. To act as a different user, use that user's ID instead. Use the user ID, not an email address.
+
+The account ID is optional. Sim uses the user's default account unless you enter one, so you only need it when the user belongs to more than one account.
+
+## Add the credential to Sim [#adding-the-credential-to-sim]
+
+<Steps>
+  <Step>
+    Open **Integrations** from your workspace sidebar
+  </Step>
+  <Step>
+    Search for "DocuSign" and open it, then click **Add to Sim** and choose **Add JWT Grant app**
+  </Step>
+  <Step>
+    Choose the **Environment** the integration key was created in: **Developer (demo)** or **Production**. A key that hasn't gone live only works in the developer environment
+  </Step>
+  <Step>
+    Paste the integration key, the impersonated user ID, the RSA private key, and optionally the account ID
+  </Step>
+  <Step>
+    Click **Add JWT Grant app**. Sim requests a token and reads the user's accounts once to check everything matches
+  </Step>
+</Steps>
+
+## Grant consent [#granting-consent]
+
+DocuSign won't issue tokens for a user until that user (or an organization admin) consents to the integration key. The first time you add the credential, Sim shows an error with the exact consent link for your integration key and environment. Open the link signed in as the impersonated user and click **Accept**. DocuSign then redirects to the redirect URI you added; the page it lands on doesn't matter, so close it and add the credential again.
+
+You only need to consent once per user and integration key, unless the user revokes it.
+
+## Use the credential in workflows [#using-the-credential-in-workflows]
+
+Add a DocuSign block and select the saved credential in the account dropdown. Every DocuSign operation works with it the same way as with a connected account. Sim calls the eSignature REST API for the account it found when it last requested a token, in the environment stored on the credential.
+
+Knowledge base syncs from DocuSign can use the credential too. They read the same account in the same environment, and envelope links open in that environment's DocuSign web app.
+
+## Fix connection errors
+
+| Error | What to check |
+| ----- | ------------- |
+| Needs the impersonated user's consent | Open the consent link from the error signed in as that user, accept, and add the credential again. Consent can also be revoked later, which stops runs until it is granted again |
+| Couldn't authenticate | The integration key, user ID, and private key must belong to the same app, in the environment you chose. A key created in the developer environment isn't valid in production until it goes live. A private key from a deleted keypair no longer works |
+| User isn't a member of the account | The account ID you entered isn't one the user belongs to. Check it, or leave it blank |
+
+To rotate the key, generate a new RSA keypair on the integration key, reconnect the credential in Sim with the new private key, test a workflow, then delete the old keypair. DocuSign allows up to five keypairs per integration key. See [DocuSign's JWT Grant documentation](https://developers.docusign.com/platform/auth/jwt/jwt-get-token/).

apps/docs/content/docs/integrations/docusign.mdx

@@ -11,8 +11,12 @@ import { ReferenceDetails } from "@/components/ui/reference-details"
 
 {/* MANUAL-CONTENT-START:intro */}
 Use [DocuSign](https://www.docusign.com) to send envelopes for e-signature, create them from templates, inspect recipients and signing status, and download completed documents. Pending envelopes can be voided with a reason.
+
+Connect a DocuSign account through OAuth, or an integration key that acts as one user through [JWT Grant](/integrations/docusign-service-account).
 {/* MANUAL-CONTENT-END */}
 
+Connection guides: [JWT Grant](/integrations/docusign-service-account).
+
 ## OAuth scopes [#oauth-scopes]
 
 Sim requests these scopes when someone connects a DocuSign account. For a self-hosted deployment, register your own app with the provider using the settings below. See [Integrations and OAuth](/platform/self-hosting/integrations-oauth) for setup.