Skip to main content

Developer integration checklist

Use this checklist when a developer is connecting a product backend, frontend, CLI, or automation system to Switera.

1. Choose the app boundary​

Confirm the app before copying keys, configuring callbacks, or testing hosted flows. Each app has its own credentials and service settings.

Use separate apps when:

  • products have different user populations
  • environments should not share keys
  • Auth provider settings are different
  • webhook receivers are different
  • audit and support ownership should be separated

2. Use the correct credential type​

Open Admin > API Keys and use the key type that matches the integration.

Switera API key page with masked publishable and secret keys
Publishable keys can be used in client-facing integration points. Secret keys belong only in trusted backend environments.

Rules:

  • never put secret keys in browser code
  • store secret keys in your secret manager
  • keep test and live keys separate
  • rotate keys after accidental exposure
  • review audit logs after key changes

3. Rotate keys carefully​

Switera API key rotation confirmation dialog
Rotation invalidates the current key. Update dependent services before removing the old value from your rollout plan.

Safe rotation pattern:

  1. Identify every service using the current key.
  2. Schedule a maintenance window if the key is production-facing.
  3. Rotate the key.
  4. Update secret storage.
  5. Restart or reload dependent services.
  6. Run a smoke test.
  7. Review logs and audit events.

4. Configure redirects and hosted flows​

For OAuth, Connect, and hosted Auth flows, register only the callback URLs your product owns. Avoid broad wildcard callbacks unless your security review explicitly allows them.

Switera Auth branding preview with hosted login layout
Hosted flows should look and redirect like part of the product your users recognize.

Test:

  • login redirect
  • registration redirect
  • recovery redirect
  • invitation continuation
  • failed provider callback
  • mobile browser behavior

5. Support device or CLI authorization​

Device authorization lets a tool ask the user to approve access in the browser.

Switera device authorization screen with code entry
The browser approval step should show the signed-in user and a code that matches the tool request.

Checklist:

  • the CLI displays a clear authorization URL
  • the browser flow requires sign-in
  • the code expires
  • the CLI reports success or failure clearly
  • revoked or expired codes cannot be reused

6. Connect webhooks after the receiver is ready​

Do not subscribe to production events before the receiver can validate signatures, handle duplicates, and return quickly.

Use Test sends and delivery debugging before relying on webhook events.

7. Add operational checks​

Before launch:

  • run a login smoke test
  • create and invite a test organization member
  • import a small test user list if imports are used
  • send one email test
  • send one webhook test event
  • call a backend API with the secret key
  • review audit logs for the setup activity

8. Keep public docs and support threads clean​

Never paste:

  • secret keys
  • raw access tokens
  • private callback secrets
  • real user exports
  • full webhook payloads containing personal data
  • internal deployment hostnames

Use masked values and sample IDs when sharing examples.

Related pages: