Set up your SyAuth application
Follow these steps in the SyAuth dashboard, using an email address you can access. By the end, you will have a workspace, an application registration, and a verification email template ready for a login test. No terminal commands are required on this page.
Just trying SyAuth without an app? Complete the dashboard steps below, then follow Manual test without an application. That walkthrough provides a small program to receive the login result on your computer and explains what you should see before and after clicking Approve.
1. Create your developer account
Sign up from the dashboard and complete the email-code verification. Sign in and complete MFA if your account requires it. This account manages workspaces and applications; it is separate from the users who will sign in to your app.
Check before continuing: you can open the dashboard after signing in. If you are still being asked for an email or authenticator code, complete that prompt first. If sign-in fails, use account-access troubleshooting.
2. Select a plan
Open Plans or Billing. Choose an available plan, complete its activation, and verify that it appears as your current plan. The dashboard shows current pricing, quotas and included features.
Check before continuing: the intended plan appears as active/current. Opening checkout or approving a payment alone does not confirm activation.
If activation fails with an access/subscription error, or the dashboard shows “Developer access required”, contact support using the account shown in the dashboard. Include the error and when it occurred. An API token cannot activate a blocked account. See account access.
3. Create a workspace
Open Workspaces, create a workspace with a descriptive name of at least three characters, and select it. Workspaces contain your application's clients, users, groups, templates and provider configurations.
For a first test, a name such as Login test is enough. If you already created a workspace, select it instead of creating another. Check that its name is selected before opening Applications, Users or Email templates. If you cannot find an existing resource, first check which workspace is selected.
Use separate workspaces for development and production when you need independent users and configuration. Save the workspace ID for API requests. You can retrieve it with your first API call.
4. Register an application
Open Applications / OAuth clients in the selected workspace and create a client:
An application registration, also called an OAuth client, stores the settings SyAuth will use for login. Saving it does not create a website or a callback page. For the no-app manual test, use Public as the client type and http://127.0.0.1:8080/callback as the redirect URI.
| Setting | Value for the hosted-login walkthrough |
|---|---|
| Name | A recognizable application name |
| Client type | Public for an app that cannot keep a secret; confidential for a server-side app |
| Redirect URIs | The exact callback URL your app handles, for example http://127.0.0.1:8080/callback during development |
| Grant types | authorization_code,refresh_token for sign-in with refresh; use authorization_code alone if refresh is unnecessary |
| Response types | code |
| Scopes | openid profile email |
Enter one redirect URI per line, grant types separated by commas, and scopes separated by spaces. These are values on the OAuth client; requesting a scope or grant later does not enable it automatically.
Save the client, then reopen its details. Check before continuing: the client appears in this workspace, its type and callback match the values you entered, and you can copy its client ID. If saving returns a validation error, correct that field before starting login. If it returns a plan/permission error, resolve that error before creating another client.
Save the public client ID. A confidential client also receives a secret: store it only on your application server. The API's resource id and OAuth client_id are different identifiers; use client_id for sign-in. A callback example is not a running app: your application must listen at that address.
For a local test, code must handle a route such as /callback at the registered host and port. If you have no app yet, use the standalone callback receiver to test with http://127.0.0.1:8080/callback. SyAuth redirects the browser there with an authorization code; your callback validates the saved sign-in attempt before you exchange that code for tokens. Registering a callback URL does not create or host the callback for you.
5. Prepare verification email
Before registering your first application user, open Email templates in the same workspace. If an Email Verification (email_verification) template already exists, review it. Otherwise, create one, choose that template type, set the subject to Verify your email, and paste this into the body:
Your verification code is {{ verification_code }}.
It expires in {{ timeout }} minutes.
Template variables use double braces. For password recovery also configure reset_password. See email templates.
Save the template and check that it appears in the selected workspace. Keep {{ verification_code }} and {{ timeout }} unchanged; SyAuth fills them when sending mail. Saving the template does not send a message yet. You test delivery when you register or verify a test user in the login walkthrough.
Values to keep before integrating
| Value | Where it comes from | Used for |
|---|---|---|
| Workspace ID | The workspace's details or the id in the workspace list response | Management requests that ask for workspace or workspace_id |
| OAuth client ID | The application's client_id | client_id in OAuth; oauth_client in JSON authentication |
| Redirect URI | The callback route you implement and register above | The exact same URI during authorization and token exchange |
| Client secret, for a confidential client | Client creation or secret reset | OAuth client authentication from your server |
state, nonce and the PKCE verifier are generated by your application for each sign-in attempt; they are not dashboard settings. Use the generator in the OAuth guide.
6. Choose your integration
- Try it without an app: start the manual login test. It provides the callback receiver and explains each browser screen.
- Hosted sign-in: follow OAuth and OpenID Connect. SyAuth presents the login/registration forms and redirects back to your app.
- Your own login form: follow email/password authentication. Read the separate registration-key prerequisite before enabling signup.
- Management automation: create a developer access token and make your first API call.
Your own application may run locally while using hosted SyAuth. Use the same registered callback URI throughout authorization and token exchange.
For a manual test, you are ready when you have an active plan, the intended workspace selected, a public client ID, the test callback registered, and the email-verification template saved. The next guide explains how to start the test; merely opening the callback address is not a login attempt.