---
summary: Find the issuer, client ID, tenant UUID, callback URLs, audience, and scopes for a SigID integration, and map sandbox setup output to framework configuration.
tags:
  - developers
  - configuration
  - quickstart
categories:
  - For Developers
---

# Integration Settings

Use this page before configuring an SDK. Keep the application registration,
browser settings, and backend validation settings in the same environment.

<!-- agent:page
Use this page to resolve integration inputs before following a runtime quickstart.
Read existing project configuration first. New evaluations can use the agent
quickstart; existing managed workspaces use their authorized admin handoff.
Map setup's generic SIGID_ISSUER and SIGID_CLIENT_ID to the framework variables.
Use tenant_id (UUID), not tenant_slug or organization_id, for validator tenantId.
Obtain the registered application audience and allowed API scopes separately;
setup's env_block does not configure these. Never invent working credentials
from example values. Keep client secrets and bootstrap management tokens out
of browser configuration. A resource server verifies tokens with public JWKS
and does not need an OAuth client secret for signature verification.
-->

## Get An Application

| Your situation | Next step |
|---|---|
| Evaluating SigID in a new app | Follow [Agent Self-Serve Quickstart](agent-quickstart.md#cli-track-recommended) to provision a sandbox application and fixture human. |
| Joining an existing workspace | Use the [admin handoff packet](../business/workspace-admin-quickstart.md#5-hand-off-to-developers). |
| Running the repository's local example | Follow [Run The Example App](run-example-app.md), including its local provisioning step. |

Choose the redirect URI before provisioning. A drop-in page at
`http://localhost:5173/` completes login on that page; the React quickstart uses
`http://localhost:5173/auth/callback`. Register the path your chosen guide uses.

## Settings And Their Sources

| Setting | Where to get it | How to use it |
|---|---|---|
| Issuer URL | Setup's `tenant_issuer`, or the application handoff | SDK `baseURL` / backend `issuer`. Preserve the advertised issuer and use its OIDC discovery. The Dashboard and Identity portal URLs are human UI surfaces. |
| Client ID | Setup's `client_id`, or Dashboard → Applications | Public OAuth identifier; safe in browser configuration. It is distinct from `application_id`. |
| Tenant ID | Setup's `tenant_id`, or the tenant details | Tenant UUID for server `tenantId` validation. A tenant slug, organization ID, or workspace display name is not a substitute. |
| App URL | Your application's origin | For example, `http://localhost:5173`; include the actual port. |
| Callback URL | Your SDK callback page, registered on the application | Exact scheme, host, port, path, and trailing slash. The page must load the SDK and complete the callback. |
| Logout URL | Your signed-out landing page, registered on the application | Must be a permitted post-logout destination. |
| Web / CORS origins | Your frontend origin, registered on the application | Origins contain scheme, host, and port; no callback path. If calling a separate API, configure that API's CORS too. |
| API audience | The registered application's audience, agreed with the API owner | Server `audience` must match the issued access token's `aud`. Changing a local environment variable does not change what SigID issues. |
| API scopes | Scopes allowed for the application and required by your API | Request them during login and enforce them on the route. `projects:read` is an example, not a built-in permission that setup grants automatically. |
| Client secret | Confidential application credentials | Server only; used for confidential OAuth exchanges. Browser clients use public PKCE. Token signature verification uses public keys. |

`openid profile email` requests sign-in and profile information. It does not
by itself grant access to a custom projects API. Establish the API audience and
scope before testing a protected resource, then sign in again to obtain a token
with the updated grants.

## Map Sandbox Output To Your Framework

The CLI's `env_block` currently contains generic `SIGID_ISSUER` and
`SIGID_CLIENT_ID` settings, plus `SIGID_CLIENT_SECRET` if one was issued.
The `--framework` selector does not produce a complete Next.js or Vite
environment file. Map the public values explicitly:

| Setup output | Next.js browser | React / Vite browser |
|---|---|---|
| `tenant_issuer` / `SIGID_ISSUER` | `NEXT_PUBLIC_SIGID_ISSUER_URL` | `VITE_SIGID_ISSUER_URL` |
| `client_id` / `SIGID_CLIENT_ID` | `NEXT_PUBLIC_SIGID_CLIENT_ID` | `VITE_SIGID_CLIENT_ID` |
| Your registered scopes | `NEXT_PUBLIC_SIGID_SCOPES` | `VITE_SIGID_SCOPES` |
| Your app origin | `NEXT_PUBLIC_APP_URL` | The quickstart uses `window.location.origin` |

Configure `SIGID_TENANT_ID`, `SIGID_API_AUDIENCE`, and `SIGID_API_SCOPE` separately
on the backend. The standalone backend quickstart also uses `SIGID_ISSUER_URL`;
the confidential backend SDK guide uses `SIGID_ISSUER`. Environment names are
application conventions: the SDK receives the values passed in its options.

Never copy the whole bootstrap result into a browser environment file. Keep
the management credentials and `.dev/sandbox-fixture.env` private and out of
version control. Use the fixture human only for sandbox login verification.

Restart your development server after changing environment files. Next.js
public variables and Vite variables are bundled into client code; rebuild the
frontend when those values change in a deployed environment.

## Check Before The First Login

1. Open your app at the registered origin, including the correct port.
2. Confirm the configured issuer's `/.well-known/openid-configuration` returns
   metadata with the expected `issuer`. Let the SDK discover the endpoints.
3. Confirm the callback URL is registered and loads your callback page directly.
4. Check that the server starts only with non-empty issuer, audience, tenant ID,
   and required scope settings. TypeScript's `!` assertion performs no runtime
   validation; an omitted SDK `tenantId` disables the expected-tenant comparison.
5. Complete hosted login, call the protected API through the SDK transport, and
   sign out. Metadata discovery alone does not verify this flow.

The `auth.sigid.localhost` issuer shown in local examples requires the SigID
development stack. A locally running customer app can use the hosted sandbox
issuer returned by setup; it does not need a local SigID deployment.

If a step fails, use [Troubleshooting](../reference/troubleshooting.md). For
copyable implementation steps, return to the [runtime chooser](index.md#start-with-a-quickstart).