Getting credentials from each provider

Where to go on each connector's own website to generate the values its credential form asks for.

Tenant Settings → Connectors asks for specific credential fields per connector — this page is a per-provider reference for where to generate each one. For Stripe, Paddle, and Dodo Payments, see Payment connectors instead, which covers their credentials alongside the Product Catalog and webhook setup. PayPal's credentials are below, because it has a separate Test Mode and Live account; its Product Catalog and checkout steps are on the Payment connectors page.

These are the provider's own pages, not ours

Every link below goes to the connector's own website or documentation. Layouts change over time — if a step doesn't match what you see, search the provider's own docs for the credential name shown here (each connector's Tenant Settings form uses the same field names as this page).

Slack — Bot Token

Each workspace needs its own Slack app

The Bot Token is a per-tenant credential — nostackai has no shared, multi-workspace Slack app to "Add to Slack." If several tenants each want Slack notifications in their own workspace, each one independently creates their own Slack app below, choosing their own workspace as the install target, and pastes their own resulting token into their own Tenant Settings. There's no way to set this up centrally for multiple tenants at once.

Create a Slack app at api.slack.com/apps → From scratch.
Under OAuth & Permissions, add the Bot Token Scopes your actions need (at minimum chat:write to post messages).
Click Install to Workspace (top of the OAuth & Permissions page) and approve it — this installs the app for your own workspace only. Nothing further to "publish": submitting to the Slack App Directory is a separate, optional step for distributing an app to *other* workspaces, and isn't needed here.
Copy the generated Bot User OAuth Token (starts xoxb-) — this is the Bot Token field.

Invite the bot to each channel it posts to

With just chat:write, Slack requires the bot to actually be a member of a channel before it can post there — installing the app alone doesn't add it anywhere. In Slack, open the target channel and either run /invite @your-bot-name or add it via Channel details → Integrations → Add an App. Skip this and posts fail with a not_in_channel error. Add the chat:write.public scope instead if you want the bot to post to any public channel without being invited first (private channels still always require an explicit invite).

See Slack's bot token reference for the full scope list.

Slack — posting under a different name or icon (optional)

The Post Message action has two optional fields beyond the channel and text: Bot Username (any display name you want — it's just a string Slack shows for that one message, not a Slack-side setting) and Icon Emoji (a :shortcode: shown as that message's avatar instead of the app's own icon). Neither is a credential — they're per-message fields, set the same way channel/text are: mapped in Org Settings' Actions tab, or inline in a Logic Block/automation. Leave either one out entirely and Slack just uses the app's own configured name/icon — nothing to fill in on your end unless you actually want the override.

Needs an extra scope to actually take effect

Bot Username/Icon Emoji are silently ignored by Slack unless the app also has the chat:write.customize scope (beyond the chat:write from setup above) — Slack gates this deliberately since overriding a bot's identity per-message is a more sensitive capability. Add it under OAuth & Permissions → Scopes, then reinstall the app, before relying on either field.

Twilio — Account SID, Auth Token, From Number

Sign in to the Twilio Console — your Account SID and Auth Token are shown on the dashboard's Account Info panel.
Under Phone Numbers → Manage → Active numbers, pick (or buy) the number you'll send SMS from — this is the From Number field, in E.164 format (e.g. +15550001234).
See Twilio's API docs for more on authentication.

Salesforce — Consumer Key, Consumer Secret, Instance URL

No manual token to obtain or refresh

nostackai mints and automatically re-mints your Salesforce access token itself, using the Consumer Key/Secret below — there's no separate OAuth flow to run, and nothing that expires on you.

In Salesforce Setup, create or use an External Client App (Setup → App Manager → New External Client App) — not "New Connected App": Salesforce restricted creating new Connected Apps as of Spring '26 and now recommends External Client Apps for new integrations (an existing Connected App you already have still works fine).
Under the app's OAuth Settings, enable OAuth and turn on the Client Credentials Flow.
Under Client Credentials Flow settings, assign a Run As user — a dedicated integration user is recommended over a real person's account.
On the app's Consumer Key and Secret, click Manage Consumer Details to reveal them — these are the Consumer Key and Consumer Secret fields.
The Instance URL is your org's own domain (e.g. https://yourorg.my.salesforce.com), shown in your browser's address bar once logged in.
See Salesforce's Client Credentials Flow guide for the current, authoritative walkthrough.

Calendly — Personal Access Token

Sign in to Calendly and go to Integrations & apps → API & Webhooks → Personal Access Tokens.
Click Generate New Token, name it, and copy the value — this is the Personal Access Token field. It authenticates as whichever Calendly user generated it, so the actions this connector exposes (listing event types, scheduled events, and invitees) only ever see that user's own data.
See Calendly's API documentation for the full reference.

Calendly — inbound webhook (optional)

Leave Webhook Signing Key blank if you only need the actions above. Fill it in only if you also want new bookings and cancellations to land automatically as entity records, via this connector's two webhook events (invitee.created, invitee.canceled).

Calendly doesn't generate this key for you

Unlike most connectors' webhook secrets, Calendly's signing key isn't something its dashboard hands you — it's a secret you make up yourself and send to Calendly when you create the subscription. Whatever string you choose has to be pasted into both places: Calendly's request body, and this connector's Webhook Signing Key field.

In nostackai, go to Tenant Settings → Webhook Key and generate (or copy) the Tenant Identifier Webhook Key — Calendly will need this appended to the URL it calls, so nostackai knows which tenant the event is for.
Calendly has no dashboard screen for creating a webhook subscription — it's API-only. Call POST https://api.calendly.com/webhook_subscriptions yourself, authenticated with the Personal Access Token above as a bearer token.
Make up your own signing secret and send it all in one request: the webhook URL (this connector's endpoint plus your tenant identifier as a query parameter), the two event names, your organization's URI (from Get Current User → current_organization, or Calendly's Get Organization endpoint), a scope of organization, and your chosen secret as signing_key.
Paste that exact same secret string into nostackai's Webhook Signing Key field — there's nothing further to copy back from Calendly's response.

http

POST https://api.calendly.com/webhook_subscriptions
Authorization: Bearer <your Personal Access Token>

{
  "url": "https://<your app domain>/app/{orgcode}/ipaas/calendly/webhook?nsa_tc_whk_key=<tenant identifier webhook key>",
  "events": ["invitee.created", "invitee.canceled"],
  "organization": "<your Calendly organization URI>",
  "scope": "organization",
  "signing_key": "<a secret you make up — paste this same value into Webhook Signing Key>"
}

See Calendly's webhook subscriptions guide for the full request shape, and its webhook signatures guide for how signing_key is used.

PayPal — Environment, Client ID, Client Secret, Webhook ID

PayPal keeps Test Mode (PayPal calls it Sandbox) and Live completely apart: each has its own app, credentials and webhook. Do Test Mode first. Everything below is done in the PayPal Developer Dashboard: use the app's Sandbox credentials for Test Mode and its Live credentials for Live. For Test Mode you also need PayPal's test accounts, a Business one to sell with and a Personal one to pay with: they are under Testing Tools → Sandbox Accounts, and the Payment connectors page walks through creating them.

Environment — a choice in nostackai, not something PayPal gives you: pick Test Mode for Sandbox credentials or Live for live ones. A Client ID only works in the mode it was created in.
Client ID and Client Secret — Apps & Credentials → Create App (set the Type to *Merchant*), then copy both from the app's page. They are also under Testing Tools → Sandbox Accounts → (…) → View/Edit Account → API Credentials.
Webhook ID — in the same app, Webhooks → Add webhook. For the URL, copy Inbound webhook URL from the PayPal card under Tenant Settings → Connectors (it already contains your tenant's key). Tick the events listed under *Events to subscribe to* on the Payment connectors page. PayPal then shows the Webhook ID.

PayPal does not give you a webhook secret

There is no signing secret to copy, unlike Stripe, Paddle or Dodo Payments. nostackai checks each event by asking PayPal, using the Webhook ID together with the Client ID and Client Secret. So all three, and the right Environment, must be filled in for webhooks to be accepted.

The plan ID is not a credential

The PayPal plan you sell (an ID starting with P-) goes in the connector's Product Catalog under a label such as monthly, not in these fields. Creating the plan, the catalog row and a test purchase are covered step by step under Setting up a PayPal account on the Payment connectors page.

Zapier — Webhook URL

In the Zap you want to trigger, add Webhooks by Zapier as the trigger step → choose Catch Hook.
Zapier generates a unique Catch Hook URL — copy it as the Webhook URL field.
See Zapier's guide to triggering Zaps from webhooks for the full setup.

Webhook (generic) — Target URL

This connector has no provider of its own — the Target URL is any HTTPS endpoint you control or that accepts POST/PUT requests (your own backend, a tool like Zapier's Catch Hook above, or any other webhook receiver). Header Name / Token are optional, for a receiver that expects a specific auth header.

S3 — Access Key ID, Secret Access Key, Region, Bucket

Create (or choose) an S3 bucket in your own AWS account — see Creating a bucket. Note its Region and Bucket name.
Create an IAM user or role with read/write access scoped to that bucket, then generate an access key pair — see Managing access keys for Access Key ID and Secret Access Key.
This is your own AWS account and bucket — nostackai only ever writes to it using the credentials you provide here.

Email

Platform-managed — there's no external provider to set up. Nothing to configure beyond adopting the connector.

GitHub — Access Token, Committer Name/Email, Webhook Secret

The access token is personal by default — or shared, per instance

Every other connector on this page is configured once per tenant. GitHub has a choice, set per connector instance by its Method field. Personal access token (the default): a token authenticates as one specific GitHub account, so Access Token, Committer Name and Committer Email are set individually, per person, from within your own application — not on this tenant's Connectors screen. Shared token: one token, entered here for the whole instance, used by anyone who calls it and by automations that have no signed-in user. Fine-grained and classic tokens both work in either method — GitHub enforces the token's own scopes.

Use GitHub from automations: a shared-token instance

Event automations, scheduled Logic Blocks and agents started by a webhook run with no signed-in user, so a personal-token instance can't authenticate for them — the call fails with a clear message rather than borrowing someone else's token. Create a second instance of the connector (for example github:automation) and set its Method to Shared token, then point your automation destinations and agent tools at that instance. Keep the plain github instance on Personal access token for your interactive users.

Use a dedicated service account for the token — every commit, issue, PR and merge made through the shared instance is attributed to the token's owner.
Set Allowed Repository so a broadly-scoped (for example classic) token can only be used against the repo this instance is for.
Enter the token as Shared Access Token on the instance's Connectors screen; optionally set Committer Name/Email for the commits it makes.
There is no automatic fallback between the two methods: an instance uses exactly the method it is set to.

In GitHub, go to Settings → Developer settings → Personal access tokens → Fine-grained tokens (direct link) and generate a new token.
Set Resource owner to the same org or user entered in nostackai's Owner field, and under Repository access, select the specific repository (or repositories) the connection should reach — avoid "All repositories" unless that's genuinely intended.
Under Permissions → Repository permissions, grant: Contents (Read and write), Pull requests (Read and write), Issues (Read and write), Actions (Read and write), Metadata (Read-only, added automatically).
Click Generate token and copy the value (starts github_pat_) — this is the Access Token each individual user connects from within your own application. It's never entered anywhere in nostackai's own console.
Committer Name/Committer Email are optional — leave them unset and they default to that person's own account name/email; set them only to override what shows up as the commit author.
See GitHub's fine-grained personal access tokens guide for the current, authoritative walkthrough.

Fine-grained PATs can't call the Checks API — this is GitHub's limitation, not nostackai's

You won't find a Checks permission in GitHub's fine-grained token screen — GitHub removed the ability to grant it to fine-grained PATs after finding edge cases, and as of this writing only a GitHub App installation token can call the Checks API. If your integration calls this connector's list_check_runs or list_check_annotations actions (checking CI status on a PR), a fine-grained PAT will fail on those calls no matter what permissions you grant it. Workaround: generate a classic personal access token with the `repo` scope instead (classic tokens' repo scope does cover the Checks API) and use that as the Access Token. A classic token's repo scope is much broader than a fine-grained one — it can reach every private repo its owner can see, not just the one repo you intend — so also set the Allowed Repository field described below to have nostackai itself refuse any call against a different repo, regardless of what the token's own scope would otherwise allow.

Owner, API Base URL, and Allowed Repository are tenant-level, entered once on the Connectors screen like any other connector: Owner is the org or user whose repositories this connection may touch (e.g. northwind-io); API Base URL is left blank for github.com, or set to https://your-host/api/v3 for GitHub Enterprise Server; Allowed Repository (optional) locks this connector instance to one repo name under Owner, enforced by nostackai regardless of the connected token's own scope — recommended whenever the Access Token is a classic PAT (see the callout above), since a fine-grained PAT's own repo selection already provides this restriction. Method selects Fine-grained personal access token (GitHub App installation isn't supported yet).

Personal token: how each person connects their own account

On an instance whose Method is Personal access token, nobody enters the token on the Connectors screen. Each person saves their own, once, while signed in to your application, by updating their profile. The token is stored encrypted on that person's own user record and is never returned by any call; from then on, anything they start (a Logic Block call, an /ipaas call, an agent run they invoke) acts as their GitHub account.

In Tenant Settings → Connectors, open the GitHub instance and set Method to Personal access token, Owner to the organization or user, and optionally Allowed Repository. Only the webhook secret (if you use webhooks) is entered here.
Each person creates their own token on GitHub (the steps above) and sends the request below, signed in as themselves. In the Playground, use Account → Update profile with the same body.
To check it, call My profile: connector_credentials lists the instance with exists: true, the profile name and the date it was saved. The token itself is never shown.

http

PUT /app/{orgCode}/user/updateprofile
Authorization: <the person's sign-in token>
x-api-key: <your org's API key>
client_id: <your org's client id>

{
  "connector_credentials": {
    "github:claims": {
      "token": "github_pat_...",
      "committer.name": "Ada Lovelace",
      "committer.email": "ada@example.com"
    }
  }
}

→ { "connector_credentials": { "github:claims": { "exists": true, "profile_name": "Ada Lovelace", "updated_at": "…" } } }

The key is the connector instance's key exactly as the console shows it, for example github:claims.
committer.name and committer.email are optional. Leave them out and commits carry the person's own GitHub account name and email.
Saving replaces everything saved for that instance, it does not merge: send the token and any committer fields together every time.
Send { "connector_credentials": { "github:claims": null } } to disconnect.
nostackai does not check the token when it is saved, so a mistyped one is only found by the first call that uses it. A call by a person who has not connected fails with "Connect your own account for 'github:claims' — missing required field 'Access Token'."
A person saves a token per tenant: the same person in two tenants connects twice.

A run belongs to the person who started it — a background run has nobody

Personal tokens apply to work a signed-in person starts. An automation, schedule or webhook has no signed-in person, so it cannot use a personal token. For that work, add a second instance of the connector (for example github:service) with Method set to Shared token and a service-account token, and point the automation or agent at it.

GitHub — inbound webhook

In the repository or organization on GitHub, go to Settings → Webhooks → Add webhook.
Set Payload URL to this connector's webhook URL (shown once the connector is adopted), Content type to application/json, and choose a Secret — any string you generate yourself.
Paste that same secret into nostackai's Webhook Secret field on the Connectors screen — it has to match exactly on both sides, since GitHub signs each delivery with it and nostackai verifies that signature.
Under Which events would you like to trigger this webhook?, choose individual events and select: Pull requests, Pull request reviews, Pull request review comments, Issue comments, Check suites, Workflow runs, and Pushes — these are the seven event types this connector understands; anything else GitHub sends is ignored.
See GitHub's webhooks documentation for the full setup and signature-verification details.

Tavily — API Key

Sign up or sign in at app.tavily.com.
Your API Key is shown on the dashboard's Overview/API Keys page immediately after sign-up — copy it into the API Key field.
See Tavily's API documentation for rate limits and plan details.

Serper — API Key

Sign up or sign in at serper.dev.
Your API Key is generated automatically and shown on the dashboard right after sign-up — copy it into the API Key field.
Leave Header Name as X-API-KEY — that's the exact header Serper expects the key under, not a value you choose.

Screenshot Service (ScreenshotOne) — Access Key

Sign up or sign in at screenshotone.com.
Your Access Key is shown on the dashboard's API Access page — copy it into the Access Key field.
Enter access_key as the Param Name. Send Via is already set to Query parameter — ScreenshotOne expects the key as a query parameter under that exact name, not a header.
See ScreenshotOne's API reference for the full set of capture options.