> ## Documentation Index > Fetch the complete documentation index at: https://docs.knoxcall.com/llms.txt > Use this file to discover all available pages before exploring further. # Integration Setup Guides > Step-by-step guides for every card on the Settings → Integrations page — which scope each credential is read from, what to create at the provider, exactly what to paste into KnoxCall, and how to prove it works. # Integration Setup Guides **Settings → Integrations** is where KnoxCall is given the credentials it needs to talk to other services: the email provider that sends invitations, the Twilio account behind SMS alerts, the OAuth apps behind "Continue with Google", the collector your telemetry ships to. Every card opens a detail view, and the book icon next to its title brings you to the guide for that card on this site. Each guide follows the same shape: what the integration powers, what to create on the provider's side (with least-privilege permissions), the exact fields to fill in on the KnoxCall form, how to verify it worked, and the things that bite. ## Two scopes The page has a scope switch, visible to workspace admins: | Scope | What it is | Who uses it | | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | | **This tenant** | Credentials that belong to your workspace. They override the platform default for anything KnoxCall does *for your workspace*. | Every workspace admin. | | **Global defaults** | The platform-wide credentials, used when no workspace override applies. On KnoxCall Cloud these are KnoxCall's own. On a self-hosted deployment they are **yours** — the operator is the admin, and this is where platform-level cards live. | Admins; self-hosted operators. | Some cards only appear under **Global defaults** because they have no per-workspace meaning (the CAPTCHA on the login page, the gateway-wide OpenTelemetry export). Others are read at platform scope even though the card is offered under both; each guide says which. If you self-host and a card "does nothing", the first thing to check is the scope you saved it under. **How credentials are stored.** Secret fields are envelope-encrypted with a key that is itself encrypted at rest, and are never sent back to the browser — once saved, the form shows masked dots and *leave blank to keep current*. Non-secret fields (a region, a from-address, an endpoint) are stored as plain metadata and shown on the list. The form refuses to store anything credential-shaped in a non-secret field. **Environment variables.** A self-hosted deployment can also supply most of these credentials as environment variables. For most integrations a **stored row wins** over the variable and the variable is only a fallback when no row exists — so deleting a row does not switch a feature off on a host that still carries the variable. Two integrations invert this: for the OpenTelemetry export and the Sentry DSNs, **the environment wins**. Each guide states the rule for its card. ## The guides ### Sign-in How the three providers share one redirect URI, what scopes are requested, and when you need your own apps. Consent screen, OAuth client ID, redirect URI. App registration, client secret, and the allowed-directory list that keeps other tenants out. An organization-owned OAuth App with one callback URL. ### Email, SMS and push Resend, SendGrid, Postmark, Mailgun, Amazon SES or any SMTP host — the transport behind every platform email. SMS alerts and the Verify service that proves a phone number before it can receive them. ntfy, Telegram or Pushover, for the assistant's hand-offs to a human. ### AI Your workspace's own key for anomaly analysis, spec analysis and the workflow copilot. The fallback provider for anomaly and spec analysis. Point the AI Gateway at your own named-entity analyzer. ### Observability Ship the whole gateway's traces, logs and metrics to Grafana Cloud, Datadog, Honeycomb, New Relic, SigNoz, Elastic, or your own collector. Only your workspace's request logs and metrics, to your own collector or SIEM. Browser, backend and console DSNs, plus the org token for the issues feed. ### Storage and cloud Request and response body archival on S3, R2 or MinIO. The API token behind static-IP egress servers. The IAM identity that assumes customer KMS roles. ### Security and anti-abuse The CAPTCHA on the login page. ### Platform operator These back services the KnoxCall operator runs around the product. On a self-hosted deployment you can leave them unconfigured unless you run the same service yourself. The support widget and assistant messages. Address autocomplete on signup and address forms. Service-account read access for the console's web-analytics page. The data-export token for the console's insights card. The admin token for the status-page Worker. The RSA key behind cross-cloud Workload Identity Federation. ## Related * [Self-hosted proxy — local integrations](/infrastructure/self-hosted-proxy#local-integrations) — the minimum a self-hosted deployment needs * [Automation platforms](/integrations/overview) — Zapier, Make and n8n connectors (a different kind of integration: they call KnoxCall, rather than KnoxCall calling them)