Services overview

Services are the app-level capabilities that make a SaaS product operational. Each service has its own setup state, configuration tabs, and next actions.

What belongs in Services​

Use Services for product capabilities that affect end users, integrations, or runtime behavior:

Service	Use it for	Configure before launch when
Authentication	Sign-in methods, providers, security controls, branding, organization access, hooks, and directory sync.	Users will sign in through Switera-hosted or Switera-connected flows.
Email	Sender identity, templates, managed account emails, and workflow timing.	Users receive invitations, verification, recovery, or account notices.
Webhooks	External event delivery and endpoint subscriptions.	Your backend or automation system needs to react to Switera events.

Services are app-scoped. Settings in one app do not automatically change another app.

Choose the first service​

Start with Authentication when the product cannot be tested until users sign in. This is the usual first service for a new SaaS app.

Start with Email when invitations, verification, password recovery, or lifecycle emails are required before the first pilot.

Start with Webhooks when a backend receiver must be ready before customer activity starts producing events.

Use setup states​

Switera uses service states to show whether a capability is active, needs setup, or needs review. Treat the state as a guide, then open the service page for exact details.

Before changing a service, check:

• the selected app in the app switcher
• whether the app is a test, staging, or production-facing product
• whether the change affects end users immediately
• whether the team has a rollback path
• whether audit logs should be checked afterward

Safe service setup order​

For most teams:

1. Configure one sign-in method.
2. Confirm hosted Auth pages look correct.
3. Prepare sender identity and required emails.
4. Create the first organization.
5. Invite a small test audience.
6. Add webhook endpoints only after the receiver is ready.
7. Rotate or copy API keys from a trusted machine.
8. Review audit logs.

Avoid common setup mistakes​

• Do not enable every sign-in option at once.
• Do not invite users before email templates and sender identity are reviewed.
• Do not subscribe a webhook endpoint to event types the receiver does not handle.
• Do not copy secret keys into frontend code or public issue trackers.
• Do not change production-facing settings while testing a separate app.

Related pages:

• Auth overview
• Email overview
• Webhooks overview
• API keys