Connect your existing user database

Custom databases let SyAuth use users stored in your PostgreSQL, MySQL or MongoDB database. Your plan must include the feature, and the database must be reachable by the hosted service with credentials authorized for the intended operations.

This is optional. For a first login test, use SyAuth's built-in user store and skip this page. Connecting an existing database needs help from the person who manages that database and a developer who understands its user records and password handling.

Before opening the form, ask that person for the database type, a connection string, a test user, and the mapping between its fields and SyAuth's user fields. A connection string contains the database's address and credentials; it is not a SyAuth client ID or token. A database available only on your computer as localhost is not automatically reachable by hosted SyAuth.

Open Custom databases in your workspace:

1. Create a connection with name, database type and connection string. Supply configuration and schema mapping where your schema differs.
2. Test connectivity. Resolve network, TLS, authentication or schema errors before activation.
3. Review the provided action-script templates for your database type and adapt them to your schema.
4. Test login/user lookup and the write actions you plan to enable using disposable records.
5. Activate the connection after a successful test. Only one connection can be active in a workspace.

Check two results separately: the connection test must succeed, and the login/lookup script must find the intended disposable test user. After activation, perform a real login test with that user. A successful network connection alone does not verify the user mapping or login logic.

Activation and script tests can create or change data in your database. Start with a test copy and appropriate database permissions. Connection strings are write-only; API responses do not return the plaintext credential.

Scripts cover actions such as login, create, get_user, get_user_by_id, change_password, delete, verify, and change_email. Use per-connection templates; query placeholders and supported script behavior depend on the database type. get_user_by_id tests need a user ID.

When active, supported authentication/user/group operations use the external store. An unhealthy active connection may return 503 instead of silently switching stores. Deactivating a connection does not import its users into SyAuth. Log/stat/mapping endpoints describe operations; they do not imply automatic bidirectional replication.

See connection, script and log APIs. For connectivity failures, report the sanitized error and database type; do not send your connection string or password.

If connectivity fails, ask the database administrator to check network access, TLS and database credentials. If connectivity succeeds but lookup/login fails, check the action script and field mapping with the developer. If login starts returning 503 after activation, inspect the active connection's health and logs before trying another signup.