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

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.