Skip to content

Commit 183f3db

Browse files
committed
feat(credentials): client-credentials service accounts — Zoom, Box, Salesforce + Pipedrive API tokens
Second service-account kind (follow-up to #5682): client-credential pairs (client ID + secret + org identifier) that mint short-lived tokens at execution — in-memory cache with ciphertext-fingerprint validation (rotation-correct across instances), single-flight coalescing, 30s failure memo, no refresh-token storage. - Zoom Server-to-Server OAuth, Box Client Credentials Grant, and Salesforce client-credentials (integration user) are the first minters; Salesforce's live instance_url rides the existing instanceUrl plumbing so all 40 tools work unchanged - Pipedrive lands as a token-paste provider with explicit authStyle threading: descriptor declares x-api-token, one shared header helper drives all 18 tools + both selector routes, OAuth Bearer behavior untouched - SSRF-allowlisted Salesforce My Domain host (production/sandbox/developer partitioned domains); ENOTFOUND maps to site_not_found, EAI_AGAIN stays provider_unavailable; 408/429 from token endpoints never blamed on creds - Create route forwards clientId/clientSecret/orgId to the builder, pinned by a route-level regression test - Zoom user-scoped tools document that server-to-server tokens don't support 'me' - 4 setup-guide docs pages verified against current vendor flows (incl. Salesforce External Client Apps — the classic Connected App wizard is disabled by default since Spring '26); integrations sidebar gains a Service Accounts & API Keys section
1 parent 58e4b75 commit 183f3db

67 files changed

Lines changed: 4046 additions & 292 deletions

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.
Lines changed: 131 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,131 @@
1+
---
2+
title: Box Service Accounts
3+
description: Set up a Box Platform app with Client Credentials Grant so your workflows can use Box through its Service Account
4+
---
5+
6+
import { Callout } from 'fumadocs-ui/components/callout'
7+
import { Step, Steps } from 'fumadocs-ui/components/steps'
8+
import { FAQ } from '@/components/ui/faq'
9+
10+
Box Platform apps with **Server Authentication (with Client Credentials Grant)** let your workflows authenticate to Box as the app's own **Service Account** instead of through a person's OAuth login. You create the app once, a Box admin authorizes it for the enterprise, and Sim mints short-lived access tokens from the app's credentials on demand — no user consent to expire, and access that's controlled entirely by which folders the Service Account is invited into.
11+
12+
This is the recommended way to use Box in production workflows: nothing depends on a user staying logged in, the app's scopes are explicit, and the Service Account's reach is auditable folder by folder.
13+
14+
## Prerequisites
15+
16+
Anyone with Developer Console access can create the app, but a Box **admin or co-admin** must authorize it in the Admin Console before it can mint tokens. Free developer accounts are authorized automatically.
17+
18+
## Setting Up the Platform App
19+
20+
### 1. Create the App
21+
22+
<Steps>
23+
<Step>
24+
Go to the [Box Developer Console](https://app.box.com/developers/console), open **My Apps**, click **Create Platform App**, and choose **Server Authentication (with Client Credentials Grant)**
25+
26+
{/* TODO(screenshot): Box Developer Console Create Platform App dialog with Server Authentication (with Client Credentials Grant) selected */}
27+
</Step>
28+
<Step>
29+
On the **Configuration** tab, set the **App Access Level**. **App Access Only** (the default) is sufficient — choose **App + Enterprise Access** only if the Service Account should also reach existing managed users' content via admin APIs
30+
</Step>
31+
<Step>
32+
Under **Application Scopes**, check **Read all files and folders stored in Box** and **Write all files and folders stored in Box**. If you'll use Sim's Box Sign operations, also check **Manage signature requests**
33+
34+
{/* TODO(screenshot): Application Scopes section with read, write, and signature scopes checked */}
35+
</Step>
36+
<Step>
37+
Copy the **Client ID** and **Client secret** from **Configuration****OAuth 2.0 Credentials** (revealing the secret may prompt for two-factor verification)
38+
39+
{/* TODO(screenshot): OAuth 2.0 Credentials panel showing the Client ID and the client secret reveal */}
40+
</Step>
41+
<Step>
42+
Copy the **Enterprise ID** — a numeric value. In the Developer Console, click your account icon in the top right and choose **Copy Enterprise ID**; a Box admin can also find it in **Admin Console****Account & Billing****Account Information**
43+
</Step>
44+
</Steps>
45+
46+
### 2. Authorize the App in the Admin Console
47+
48+
Token requests fail with `unauthorized_client` ("This app is not authorized by the enterprise admin") until a Box admin authorizes the app:
49+
50+
<Steps>
51+
<Step>
52+
A Box admin or co-admin opens **Admin Console****Apps****Platform Apps Manager** (in some tenants this appears as **Platform****Platform Apps**)
53+
</Step>
54+
<Step>
55+
Click **Add App** and enter the app's **Client ID**
56+
57+
{/* TODO(screenshot): Platform Apps Manager Add App dialog with the Client ID entered */}
58+
</Step>
59+
</Steps>
60+
61+
Alternatively, the developer can click **Review and Submit** on the app's **Authorization** tab in the Developer Console to send the request to the admin.
62+
63+
<Callout type="warn">
64+
**Authorization is a snapshot.** If you later change the app's scopes or access level — for example, adding the signature scope — the admin must **re-authorize** the app in the same Platform Apps Manager section before the change takes effect. Until then, token minting keeps succeeding but the new scopes don't apply, which surfaces as persistent `403` errors on tools despite correct-looking configuration.
65+
</Callout>
66+
67+
### 3. Give the Service Account Access to Folders
68+
69+
The Service Account is a brand-new Box user — its email looks like `AutomationUser_AppServiceID_RandomString@boxdevedition.com` and is shown on the app's **General Settings** tab. Its folder tree starts **empty**: a fully valid credential sees zero items and gets `404`s on real files and folders until you grant it access.
70+
71+
<Steps>
72+
<Step>
73+
In Box, invite the Service Account's `@boxdevedition.com` email as a **collaborator** on each folder your workflows should work with — use the **Editor** role for read/write access
74+
75+
{/* TODO(screenshot): Box folder collaboration dialog inviting the AutomationUser email as Editor */}
76+
</Step>
77+
<Step>
78+
Verify by running Sim's Box **List Folder Items** on folder ID `0` — the collaborated folders should appear
79+
</Step>
80+
</Steps>
81+
82+
<Callout type="info">
83+
Community reports indicate the Service Account can't be collaborated into a user's root folder itself — invite it into individual folders instead.
84+
</Callout>
85+
86+
## Adding the Service Account to Sim
87+
88+
<Steps>
89+
<Step>
90+
Open **Integrations** from your workspace sidebar
91+
</Step>
92+
<Step>
93+
Search for "Box" and open it, then click **Add to Sim** and choose **Add service account**
94+
95+
{/* TODO(screenshot): Box integration page with the Add service account connect option */}
96+
</Step>
97+
<Step>
98+
In the **Add Box service account** dialog, paste the **Client ID**, **Client secret**, and **Enterprise ID** (numeric), and optionally set a display name and description
99+
100+
{/* TODO(screenshot): Add Box service account dialog with all three fields filled in */}
101+
</Step>
102+
<Step>
103+
Click **Add service account**. Sim verifies the credentials by minting a real access token from Box — if it fails, the error tells you whether Box rejected the credentials or couldn't be reached. A rejection usually means bad credentials, an app the admin hasn't authorized yet, or values that don't all belong to the same app and enterprise.
104+
</Step>
105+
</Steps>
106+
107+
## Using the Service Account in Workflows
108+
109+
Add a Box block to your workflow. In the credential dropdown, your Box service account appears alongside any OAuth credentials. Select it and configure the block as you normally would.
110+
111+
{/* TODO(screenshot): Box block in a workflow with the Box service account selected as the credential */}
112+
113+
The block calls `api.box.com` with a freshly minted access token — the same requests as the OAuth flow, so every Box operation works, subject to the app's scopes and the folders the Service Account can see.
114+
115+
<Callout type="info">
116+
Sim's Box block includes Box Sign operations. These need the **Manage signature requests** scope on the app *and* Box Sign enabled on your enterprise's plan — without either, signature operations fail while file and folder operations keep working.
117+
</Callout>
118+
119+
## Token Behavior
120+
121+
Access tokens minted from the app are short-lived (typically one hour) and there is no refresh token — Sim simply mints a new token when one is needed. The stored Client ID, secret, and Enterprise ID stay valid until you rotate the secret in the Developer Console or the admin removes the app's authorization. If you rotate the secret, update the credential in Sim right away — reconnecting asks you to re-enter all three values.
122+
123+
<FAQ items={[
124+
{ question: "Why a Service Account instead of OAuth?", answer: "The Service Account is its own Box user, owned by the app — nothing expires when someone leaves or their login lapses. Access is granted folder by folder through collaborations, which makes the credential's reach explicit and auditable." },
125+
{ question: "The credential validates but every block returns nothing or 404s — why?", answer: "The Service Account's folder tree starts empty. It only sees folders it has been invited into as a collaborator. Invite its @boxdevedition.com email (shown on the app's General Settings tab) as an Editor on the folders your workflows use." },
126+
{ question: "Adding the credential fails and Box's token endpoint reports 'This app is not authorized by the enterprise admin' — what now?", answer: "Sim surfaces this as its general authentication error. A Box admin or co-admin must authorize the app in Admin Console → Apps → Platform Apps Manager (or Platform → Platform Apps in some tenants) by adding its Client ID. Until then, all token requests fail." },
127+
{ question: "I added a scope but tools still fail with 403 — why?", answer: "Authorization is a snapshot of the app's scopes at the time the admin approved it. After any scope or access-level change, the admin must re-authorize the app in Platform Apps Manager before the new scopes apply." },
128+
{ question: "Box rejects the token request with 'The grant type is unauthorized for this client_id' — why?", answer: "The app was created with user authentication (OAuth 2.0) instead of Server Authentication, and Sim reports it couldn't authenticate with those credentials. Create a new Platform App and choose Server Authentication (with Client Credentials Grant)." },
129+
{ question: "Box rejects the token request with 'Grant credentials are invalid' — why?", answer: "Either the Client ID, Client secret, and Enterprise ID don't all belong to the same Box app and enterprise (most often a mismatched ID/secret pair), or the app hasn't been authorized in the Admin Console yet. Re-copy all three values from the same app in the Developer Console, and make sure an admin has authorized the app in Platform Apps Manager." },
130+
{ question: "Do Box Sign operations work with a service account?", answer: "Yes, if the app has the Manage signature requests scope, the admin has (re-)authorized the app since it was added, and Box Sign is enabled on your enterprise plan. File and folder operations work regardless." },
131+
]} />

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

Lines changed: 20 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,32 @@
11
{
22
"pages": [
33
"index",
4+
"---Service Accounts & API Keys---",
5+
"airtable-service-account",
6+
"asana-service-account",
7+
"atlassian-service-account",
8+
"attio-service-account",
9+
"box-service-account",
10+
"calcom-service-account",
11+
"google-service-account",
12+
"hubspot-service-account",
13+
"linear-service-account",
14+
"monday-service-account",
15+
"notion-service-account",
16+
"pipedrive-service-account",
17+
"salesforce-service-account",
18+
"shopify-service-account",
19+
"trello-service-account",
20+
"wealthbox-service-account",
21+
"webflow-service-account",
22+
"zoom-service-account",
23+
"---All Integrations---",
424
"a2a",
525
"agentmail",
626
"agentphone",
727
"agiloft",
828
"ahrefs",
929
"airtable",
10-
"airtable-service-account",
1130
"airweave",
1231
"algolia",
1332
"amplitude",
@@ -16,12 +35,9 @@
1635
"appconfig",
1736
"arxiv",
1837
"asana",
19-
"asana-service-account",
2038
"ashby",
2139
"athena",
22-
"atlassian-service-account",
2340
"attio",
24-
"attio-service-account",
2541
"azure_devops",
2642
"box",
2743
"brandfetch",
@@ -30,7 +46,6 @@
3046
"browser_use",
3147
"buffer",
3248
"calcom",
33-
"calcom-service-account",
3449
"calendly",
3550
"circleback",
3651
"clay",
@@ -81,7 +96,6 @@
8196
"gitlab",
8297
"gmail",
8398
"gong",
84-
"google-service-account",
8599
"google_ads",
86100
"google_appsheet",
87101
"google_bigquery",
@@ -108,7 +122,6 @@
108122
"greptile",
109123
"hex",
110124
"hubspot",
111-
"hubspot-service-account",
112125
"hubspot-setup",
113126
"huggingface",
114127
"hunter",
@@ -133,7 +146,6 @@
133146
"leadmagic",
134147
"lemlist",
135148
"linear",
136-
"linear-service-account",
137149
"linkedin",
138150
"linkup",
139151
"linq",
@@ -152,14 +164,12 @@
152164
"millionverifier",
153165
"mistral_parse",
154166
"monday",
155-
"monday-service-account",
156167
"mongodb",
157168
"mysql",
158169
"neo4j",
159170
"neverbounce",
160171
"new_relic",
161172
"notion",
162-
"notion-service-account",
163173
"obsidian",
164174
"okta",
165175
"onedrive",
@@ -206,7 +216,6 @@
206216
"sftp",
207217
"sharepoint",
208218
"shopify",
209-
"shopify-service-account",
210219
"similarweb",
211220
"sixtyfour",
212221
"slack",
@@ -228,7 +237,6 @@
228237
"thrive",
229238
"tinybird",
230239
"trello",
231-
"trello-service-account",
232240
"trigger_dev",
233241
"twilio",
234242
"twilio_sms",
@@ -239,9 +247,7 @@
239247
"vanta",
240248
"vercel",
241249
"wealthbox",
242-
"wealthbox-service-account",
243250
"webflow",
244-
"webflow-service-account",
245251
"whatsapp",
246252
"wikipedia",
247253
"wiza",
Lines changed: 74 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,74 @@
1+
---
2+
title: Pipedrive API Tokens
3+
description: Connect Pipedrive to Sim with a personal API token instead of an OAuth login
4+
---
5+
6+
import { Callout } from 'fumadocs-ui/components/callout'
7+
import { Step, Steps } from 'fumadocs-ui/components/steps'
8+
import { FAQ } from '@/components/ui/faq'
9+
10+
Pipedrive personal API tokens let your workflows authenticate to Pipedrive without a person's OAuth login. The token is issued per user per company, doesn't expire on its own, and stays valid until it's regenerated or the user is deactivated — no OAuth consent to renew.
11+
12+
The token carries the full data access of the Pipedrive user it belongs to, in that one company. For production workflows, create it from a dedicated Pipedrive user so a teammate leaving or regenerating their token doesn't break your automations.
13+
14+
## Prerequisites
15+
16+
Any Pipedrive user with API access enabled can copy their token. If the API page is hidden, a Pipedrive admin may have disabled API access for non-admin users — an admin can enable it from the company's user settings.
17+
18+
<Callout type="warn">
19+
Each user has exactly **one** active API token per company. Regenerating it immediately invalidates the old value everywhere it's used, with no grace period. If the token is shared with other integrations, coordinate before regenerating.
20+
</Callout>
21+
22+
## Finding the API Token
23+
24+
<Steps>
25+
<Step>
26+
In Pipedrive, click your profile picture in the top right, then **Personal preferences****API** — or go directly to `https://app.pipedrive.com/settings/api`
27+
</Step>
28+
<Step>
29+
Copy **Your personal API token** (generate one if the field is empty)
30+
</Step>
31+
</Steps>
32+
33+
<Callout type="warn">
34+
The API token grants everything its user can see and do in Pipedrive. Treat it like a password — do not commit it to source control or share it publicly. Sim encrypts the token at rest.
35+
</Callout>
36+
37+
## Adding the API Token to Sim
38+
39+
<Steps>
40+
<Step>
41+
Open **Integrations** from your workspace sidebar
42+
</Step>
43+
<Step>
44+
Search for "Pipedrive" and open it, then click **Add to Sim** and choose **Add API token**
45+
</Step>
46+
<Step>
47+
Paste the **API token**, and optionally set a display name and description
48+
</Step>
49+
<Step>
50+
Click **Add API token**. Sim verifies the token against Pipedrive (`GET /v1/users/me`) and names the credential after the Pipedrive user and company — if verification fails, you'll see a specific error explaining what went wrong.
51+
</Step>
52+
</Steps>
53+
54+
## Using the API Token in Workflows
55+
56+
Add a Pipedrive block to your workflow. In the credential dropdown, your Pipedrive API token appears alongside any OAuth credentials. Select it and configure the block as you normally would.
57+
58+
Sim sends the token in Pipedrive's `x-api-token` header (the documented scheme for personal API tokens), so every Pipedrive tool works unchanged.
59+
60+
<Callout type="info">
61+
Pipedrive gives API-token traffic lower burst rate limits than OAuth (roughly a quarter of the OAuth allowance, by plan), and every company shares one daily API budget across all users and both auth methods. Heavy workflow schedules can eat into the budget your other Pipedrive integrations use.
62+
</Callout>
63+
64+
## Rotating the Token
65+
66+
Pipedrive tokens don't expire on a schedule. To rotate one, regenerate it on the same **Personal preferences****API** page, then paste the new value into the credential in Sim right away — the old token stops working the moment a new one is generated.
67+
68+
<FAQ items={[
69+
{ question: "Why an API token instead of OAuth?", answer: "The token doesn't depend on any user staying logged in or re-consenting, and it never expires on its own. Issued from a dedicated Pipedrive user, it's a stable credential for automated workflows." },
70+
{ question: "What can the token access?", answer: "Everything the Pipedrive user it belongs to can access, in that one company. There are no scopes to narrow it — pick the issuing user accordingly." },
71+
{ question: "My token validates but a mailbox or projects block fails — why?", answer: "API tokens ignore scopes, but features like Mailbox and Projects still depend on your Pipedrive plan. A valid token doesn't unlock endpoints your plan doesn't include." },
72+
{ question: "What happens if the user who owns the token is deactivated?", answer: "The token stops working immediately. Issue a new token from an active user (ideally a dedicated integration user) and update the credential in Sim." },
73+
{ question: "Why are my workflows hitting rate limits more than with OAuth?", answer: "Pipedrive gives API-token requests about a quarter of the OAuth burst allowance, and the company-wide daily API budget is shared across all users and integrations. Space out heavy schedules or switch busy workflows to OAuth credentials." },
74+
]} />

0 commit comments

Comments
 (0)