feat(credentials): add Atlassian service account credentials (#4432)

* v0.6.29: login improvements, posthog telemetry (#4026)

* feat(posthog): Add tracking on mothership abort (#4023)

Co-authored-by: Theodore Li <theo@sim.ai>

* fix(login): fix captcha headers for manual login  (#4025)

* fix(signup): fix turnstile key loading

* fix(login): fix captcha header passing

* Catch user already exists, remove login form captcha

* feat(credentials): add Atlassian service account credentials

* improvement(credentials): tighten Atlassian service account plumbing

- Collapse fetchOAuthTokenBundle into fetchOAuthToken (returns the bundle)
- Reuse serviceAccountJsonSchema in the JSON form instead of hand-rolled checks
- Use parseAtlassianErrorMessage for log details; drop one-line bearer helper
- Extract ATLASSIAN_SERVICE_ACCOUNT_PROVIDER_ID/_SECRET_TYPE constants
- Use Drizzle .returning() instead of post-insert SELECT
- Helper for the duplicated 401/403 + non-OK pattern in the validator

* docs(credentials): add Atlassian service account setup guide

- New /integrations/atlassian-service-account doc covers token creation,
  scope selection, and adding the credential to Sim
- Form's "View setup guide" link now points at the doc
- Fix the existing Google form link that pointed to the wrong path

Screenshot TODOs left inline as MDX comments for the docs team.

* docs(credentials): add Atlassian service account screenshots

- Auth type picker, Sim add-credential modal, Jira block credential dropdown
- Scope-picker screenshot still TODO

* docs(credentials): add Atlassian scope picker screenshot

* fix(credentials): address greptile feedback on Atlassian SA

- Drop stale 'email and API token' copy from the service description
  (we only collect a token + domain, no email field)
- Move duplicate display-name check inside the create transaction so
  concurrent POSTs can't both pass the check and insert duplicates

* fix(docs): move Atlassian screenshots to docs/public

Docs site serves /static/* from apps/docs/public, not apps/sim/public —
matches the existing google-service-account screenshot convention.

* fix(credentials): address review feedback on Atlassian SA

- SSRF: only accept *.atlassian.net / *.jira-dev.com hosts before fetching
  tenant_info, blocking probes against localhost/internal IPs
- Confluence spaces selector: pull cloudId from the SA secret instead of
  calling accessible-resources, which 401s for scoped service-account tokens
- Case-insensitive https?:// strip so HTTPS://team.atlassian.net normalizes
  correctly

* chore: merge staging and bump API validation route baseline to 727

* perf(credentials): single-resolve in confluence spaces selector

Atlassian SAs were hitting resolveOAuthAccountId twice (once via
refreshAccessTokenIfNeeded, once directly to read cloudId) and
decrypting the secret twice (via getAtlassianServiceAccountToken
inside refresh, then again via getAtlassianServiceAccountSecret).

Resolve once up front and branch the whole flow on the result —
SA path skips refresh entirely and pulls token+cloudId from a
single secret read.

* refactor(credentials): consolidate Atlassian SA creation into /api/credentials

Atlassian service-account creation lived in its own route, contract, and
mutation hook, copy-pasting ~140 lines of insert/membership/audit/posthog
boilerplate from /api/credentials. Two endpoints means two authz paths,
two audit shapes, two TOCTOU stories — they will drift.

Fold Atlassian into the existing service_account branch of /api/credentials,
dispatching by providerId. The Atlassian validator (tenant_info + Bearer
/myself, SSRF host allowlist, typed error codes) lives in
lib/credentials/atlassian-service-account.ts and is the only Atlassian-
specific piece left. AtlassianValidationError maps to a {code, error} 400
in the existing catch block; the rest of the flow (transaction, members,
audit, posthog, dup-check) is now shared with Google SA + env credentials.

Delete:
- /api/auth/atlassian-service-account route
- contracts/atlassian-service-account.ts + barrel export
- useCreateAtlassianServiceAccount hook
- API audit baseline 727 → 726

Both forms (Google JSON-key, Atlassian token+domain) now call
useCreateWorkspaceCredential with the appropriate body shape.

* fix(credentials): close TOCTOU and restore typed errors after consolidation

- Add inner duplicate-guard inside the create transaction (DuplicateCredentialError)
  to close the race that the outer findExistingCredentialBySource leaves open.
  service_account rows have no DB-level unique index on (workspaceId, providerId,
  displayName), so this is the actual safety net. Tx-internal check applies to
  Google + env_workspace too — race-safety win for all credential types.
- Re-emit {code: 'duplicate_display_name', error: ...} on conflict so the form's
  ERROR_MESSAGES.duplicate_display_name mapping is reachable again.
- Thread Atlassian-specific audit metadata (atlassianDomain, atlassianCloudId)
  back into recordAudit; consolidation had dropped them.
- Use ATLASSIAN_SERVICE_ACCOUNT_PROVIDER_ID constant in contract superRefine.
- Drop `error: any` in catch in favor of `error: unknown` + getPostgresErrorCode.

* chore(credentials): drop dead createWorkspaceCredentialBodySchema + updateWorkspaceCredentialBodySchema

Both shadowed the actually-used schemas (createCredentialBodySchema /
updateCredentialByIdBodySchema) and were missing the apiToken/domain
Atlassian fields. A future change could pick the wrong one and silently
drop those fields. Confirmed zero non-definition references in the repo
(grep across apps/, packages/, scripts/ minus build artifacts).

* fix(credentials): scope inner duplicate re-check to service_account

OAuth dedupes by accountId, env_* by envKey — both have DB-level partial
unique indexes that surface as 23505. The previous inner re-check fired
for all types and always threw DuplicateCredentialError, which mapped to
'duplicate_display_name' in the UI even when the real conflict was a
duplicate OAuth account or env key. Restrict the in-tx re-check to
service_account (the only type without a DB-level index) and let the
23505 handler emit a generic message for everything else.

---------

Co-authored-by: Waleed <walif6@gmail.com>
Co-authored-by: Siddharth Ganesan <33737564+Sg312@users.noreply.github.com>
Co-authored-by: Vikhyath Mondreti <vikhyathvikku@gmail.com>

Author: 4 people

apps/docs/content/docs/en/integrations/atlassian-service-account.mdx

@@ -0,0 +1,166 @@
+---
+title: Atlassian Service Accounts
+description: Set up an Atlassian service account with a scoped API token to use Jira and Confluence in Sim workflows
+---
+
+import { Callout } from 'fumadocs-ui/components/callout'
+import { Step, Steps } from 'fumadocs-ui/components/steps'
+import { Image } from '@/components/ui/image'
+import { FAQ } from '@/components/ui/faq'
+
+Atlassian service accounts let your workflows authenticate to Jira and Confluence as a non-human bot user — independent of any individual employee's account. Each service account has its own email, its own permissions, and its own API tokens, all managed centrally in admin.atlassian.com.
+
+This is the recommended way to use Jira and Confluence in production workflows: no one person's OAuth consent expires, the bot's permissions are auditable, and access can be revoked without touching anyone's personal account.
+
+## Prerequisites
+
+You need an Atlassian organization admin to create the service account. Service accounts are an Atlassian organization-level feature — they cannot be created from a regular user account.
+
+## Setting Up the Service Account
+
+### 1. Create the Service Account
+
+<Steps>
+  <Step>
+    Open [admin.atlassian.com](https://admin.atlassian.com/) and go to **Directory** → **Service accounts**
+
+    {/* TODO(screenshot): admin.atlassian.com directory page with the "Service accounts" tab highlighted */}
+  </Step>
+  <Step>
+    Click **Create service account**, give it a name (e.g. `sim-jira-bot`), and finish creation
+  </Step>
+  <Step>
+    Grant the service account access to the Atlassian sites and products it needs. Open the service account, go to **Product access**, and add Jira and/or Confluence on the relevant site
+
+    {/* TODO(screenshot): service account "Product access" tab showing Jira granted on a site */}
+  </Step>
+</Steps>
+
+<Callout type="info">
+The service account inherits permissions from the project/space roles you grant it — exactly like a human user. If a workflow needs to write to a specific Jira project, give the service account write access to that project in Jira's project settings.
+</Callout>
+
+### 2. Create a Scoped API Token
+
+<Steps>
+  <Step>
+    From the service account's page in admin.atlassian.com, open the **API tokens** tab and click **Create API token**
+
+    {/* TODO(screenshot): service account API tokens tab with "Create API token" button */}
+  </Step>
+  <Step>
+    Choose **API token** as the authentication type (not OAuth 2.0 — Sim uses the API token flow)
+
+    <div className="flex justify-center">
+      <Image
+        src="/static/credentials/atlassian/admin-auth-type-picker.png"
+        alt="Atlassian admin — Choose authentication type with API token selected"
+        width={700}
+        height={500}
+        className="my-4"
+      />
+    </div>
+  </Step>
+  <Step>
+    Select the scopes the token needs. The minimum set Sim's Jira and Confluence blocks expect is:
+
+    **Jira (granular):**
+    ```
+    read:jira-user
+    read:jira-work
+    write:jira-work
+    ```
+
+    **Confluence (granular):**
+    ```
+    read:confluence-content.all
+    read:confluence-space.summary
+    write:confluence-content
+    read:page:confluence
+    write:page:confluence
+    ```
+
+    Add more scopes only if you need the corresponding operations (delete, manage webhooks, etc.). The full list of scopes Sim's blocks may use is documented in [Atlassian's developer reference](https://developer.atlassian.com/cloud/jira/platform/scopes-for-oauth-2-3LO-and-forge-apps/).
+
+    <div className="flex justify-center">
+      <Image
+        src="/static/credentials/atlassian/admin-scope-picker.png"
+        alt="Atlassian token scope picker filtered to App: Jira and Scope type: Classic"
+        width={1000}
+        height={600}
+        className="my-4"
+      />
+    </div>
+
+    <Callout type="info">
+      Use the **App** and **Scope type** filters to narrow the list to the scopes you need. Filter by `App: Jira` (or `Confluence`) and `Scope type: Classic` to find the three core Jira scopes; switch to **Granular** if your org doesn't expose Classic.
+    </Callout>
+  </Step>
+  <Step>
+    Copy the token when it's shown. Atlassian only displays it once — if you close the dialog, you'll have to create a new token.
+  </Step>
+</Steps>
+
+<Callout type="warn">
+The API token is bearer credentials for the service account. Treat it like a password — do not commit it to source control or share it publicly. Sim encrypts the token at rest.
+</Callout>
+
+### 3. Find Your Site Domain
+
+Your Atlassian site domain is the URL you use to access Jira or Confluence in your browser — for example, `your-team.atlassian.net`. Open Jira or Confluence, look at the address bar, and copy the part before the first `/`.
+
+## Adding the Service Account to Sim
+
+<Steps>
+  <Step>
+    Open your workspace **Settings** and go to the **Integrations** tab
+  </Step>
+  <Step>
+    Search for "Atlassian Service Account" and click it
+
+    {/* TODO(screenshot): Integrations page with "Atlassian Service Account" in the service list */}
+  </Step>
+  <Step>
+    Paste the API token, enter the site domain (e.g. `your-team.atlassian.net`), and optionally set a display name and description
+
+    <div className="flex justify-center">
+      <Image
+        src="/static/credentials/atlassian/sim-add-modal.png"
+        alt="Add Atlassian Service Account dialog with API token and site domain filled in"
+        width={420}
+        height={560}
+        className="my-6"
+      />
+    </div>
+  </Step>
+  <Step>
+    Click **Add Service Account**. Sim verifies the token by calling Atlassian's `/myself` endpoint through the gateway — if it fails, you'll see a specific error explaining what went wrong.
+  </Step>
+</Steps>
+
+The token, domain, and discovered cloudId are encrypted before being stored.
+
+## Using the Service Account in Workflows
+
+Add a Jira or Confluence block to your workflow. In the credential dropdown, your Atlassian service account appears alongside any OAuth credentials. Select it and configure the block as you normally would.
+
+<div className="flex justify-center">
+  <Image
+    src="/static/credentials/atlassian/sim-jira-block-credential.png"
+    alt="Jira block in a workflow with the Atlassian service account selected as the credential"
+    width={1000}
+    height={500}
+    className="my-4"
+  />
+</div>
+
+The block calls Atlassian's API gateway (`api.atlassian.com/ex/jira/{cloudId}/...`) using the service account's token. There's no impersonation step — the service account acts as itself, with whatever permissions you granted it in admin.atlassian.com.
+
+<FAQ items={[
+  { question: "Why an API token instead of OAuth?", answer: "API tokens for service accounts don't have a 1-hour expiry and don't require any user to consent. They're issued by an org admin and are stable until you revoke them — which is what you want for an automated workflow." },
+  { question: "Can a regular user create a service account?", answer: "No. Service accounts are an Atlassian organization-level feature and only an organization admin can create them." },
+  { question: "Can the same service account work with both Jira and Confluence?", answer: "Yes — give the service account access to both products on your site, and include scopes for both when you create the API token. Then connect it once in Sim and use it from either Jira or Confluence blocks." },
+  { question: "What if my workflow needs different permissions than the token has?", answer: "Either widen the token's scopes (revoke it and create a new one with more scopes), or grant the service account higher project/space roles in Jira or Confluence. Scope failures look like 401/403 errors with descriptive messages." },
+  { question: "How do I rotate the API token?", answer: "Create a new token from the same service account in admin.atlassian.com, update the credential in Sim with the new token, and once it's working, revoke the old one." },
+  { question: "Does this work with Atlassian Data Center / on-prem?", answer: "No — this integration uses Atlassian Cloud's API gateway (`api.atlassian.com`). For Data Center, use the OAuth flow or set up a self-hosted bot user." },
+]} />

apps/docs/content/docs/en/integrations/meta.json

@@ -1,5 +1,5 @@
 {
   "title": "Integrations",
-  "pages": ["index", "google-service-account"],
+  "pages": ["index", "google-service-account", "atlassian-service-account"],
   "defaultOpen": false
 }

apps/docs/public/static/credentials/atlassian/admin-auth-type-picker.png

@@ -9,7 +9,9 @@ import { authorizeCredentialUse } from '@/lib/auth/credential-access'
 import { AuthType, checkSessionOrInternalAuth } from '@/lib/auth/hybrid'
 import { generateRequestId } from '@/lib/core/utils/request'
 import { withRouteHandler } from '@/lib/core/utils/with-route-handler'
+import { ATLASSIAN_SERVICE_ACCOUNT_PROVIDER_ID } from '@/lib/oauth/types'
 import {
+  getAtlassianServiceAccountSecret,
   getCredential,
   getOAuthToken,
   getServiceAccountToken,
@@ -118,6 +120,17 @@ export const POST = withRouteHandler(async (request: NextRequest) => {
       }
 
       try {
+        if (resolved.providerId === ATLASSIAN_SERVICE_ACCOUNT_PROVIDER_ID) {
+          const secret = await getAtlassianServiceAccountSecret(resolved.credentialId)
+          return NextResponse.json(
+            {
+              accessToken: secret.apiToken,
+              cloudId: secret.cloudId,
+              domain: secret.domain,
+            },
+            { status: 200 }
+          )
+        }
         const accessToken = await getServiceAccountToken(
           resolved.credentialId,
           scopes ?? [],

apps/docs/public/static/credentials/atlassian/admin-scope-picker.png

@@ -11,6 +11,10 @@ import {
   isMicrosoftProvider,
   PROACTIVE_REFRESH_THRESHOLD_DAYS,
 } from '@/lib/oauth/microsoft'
+import {
+  ATLASSIAN_SERVICE_ACCOUNT_PROVIDER_ID,
+  ATLASSIAN_SERVICE_ACCOUNT_SECRET_TYPE,
+} from '@/lib/oauth/types'
 
 const logger = createLogger('OAuthUtilsAPI')
 
@@ -44,6 +48,7 @@ export interface ResolvedCredential {
   usedCredentialTable: boolean
   credentialType?: string
   credentialId?: string
+  providerId?: string
 }
 
 /**
@@ -61,6 +66,7 @@ export async function resolveOAuthAccountId(
       type: credential.type,
       accountId: credential.accountId,
       workspaceId: credential.workspaceId,
+      providerId: credential.providerId,
     })
     .from(credential)
     .where(eq(credential.id, credentialId))
@@ -73,6 +79,7 @@ export async function resolveOAuthAccountId(
         credentialId: credentialRow.id,
         credentialType: 'service_account',
         workspaceId: credentialRow.workspaceId,
+        providerId: credentialRow.providerId ?? undefined,
         usedCredentialTable: true,
       }
     }
@@ -208,6 +215,53 @@ export async function getServiceAccountToken(
   return tokenData.access_token
 }
 
+interface AtlassianServiceAccountSecret {
+  type: typeof ATLASSIAN_SERVICE_ACCOUNT_SECRET_TYPE
+  apiToken: string
+  domain: string
+  cloudId: string
+  atlassianAccountId?: string
+}
+
+/**
+ * Loads the decrypted Atlassian service account secret blob for a credential.
+ * Throws if the credential is missing or not an Atlassian service account.
+ */
+export async function getAtlassianServiceAccountSecret(
+  credentialId: string
+): Promise<AtlassianServiceAccountSecret> {
+  const [credentialRow] = await db
+    .select({ encryptedServiceAccountKey: credential.encryptedServiceAccountKey })
+    .from(credential)
+    .where(eq(credential.id, credentialId))
+    .limit(1)
+
+  if (!credentialRow?.encryptedServiceAccountKey) {
+    throw new Error('Atlassian service account secret not found')
+  }
+
+  const { decrypted } = await decryptSecret(credentialRow.encryptedServiceAccountKey)
+  const parsed = JSON.parse(decrypted) as AtlassianServiceAccountSecret
+  if (
+    parsed.type !== ATLASSIAN_SERVICE_ACCOUNT_SECRET_TYPE ||
+    !parsed.apiToken ||
+    !parsed.cloudId
+  ) {
+    throw new Error('Stored Atlassian service account secret is malformed')
+  }
+  return parsed
+}
+
+/**
+ * For Atlassian service accounts, the API token IS the access token —
+ * blocks call api.atlassian.com/ex/jira/{cloudId}/... with `Authorization: Bearer {apiToken}`.
+ * No exchange or refresh is needed; we just decrypt and return the raw token.
+ */
+export async function getAtlassianServiceAccountToken(credentialId: string): Promise<string> {
+  const secret = await getAtlassianServiceAccountSecret(credentialId)
+  return secret.apiToken
+}
+
 /**
  * Safely inserts an account record, handling duplicate constraint violations gracefully.
  * If a duplicate is detected (unique constraint violation), logs a warning and returns success.
@@ -374,6 +428,10 @@ export async function refreshAccessTokenIfNeeded(
   }
 
   if (resolved.credentialType === 'service_account' && resolved.credentialId) {
+    if (resolved.providerId === ATLASSIAN_SERVICE_ACCOUNT_PROVIDER_ID) {
+      logger.info(`[${requestId}] Using Atlassian service account token for credential`)
+      return getAtlassianServiceAccountToken(resolved.credentialId)
+    }
     if (!scopes?.length) {
       throw new Error('Scopes are required for service account credentials')
     }