Sign-in and signup

Multica signs users in with 6-digit verification codes by default; Google OAuth can be added on top. Existing users can always sign in again — signup restrictions only decide whether new accounts can be created.

Verification code delivery

After the user enters an email address, Multica sends a 6-digit verification code. The code is valid for 10 minutes; once it verifies, the browser receives a sign-in cookie.

Verification codes can be delivered through a signed Feishu custom bot, Resend, or SMTP. Once either Feishu setting is present, Multica uses only Feishu and fails closed on incomplete configuration or delivery errors. When both Feishu settings are empty, verification uses SMTP and then Resend.

Using Feishu

Set the bot webhook and signing secret:

MULTICA_VERIFICATION_FEISHU_WEBHOOK_URL=https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
MULTICA_VERIFICATION_FEISHU_SIGN_SECRET=your-signing-secret

Both values are required and must be stored as server-side secrets. Every message contains the requested email address, the 6-digit code, and its 10-minute expiry. Anyone who can read the group can use a visible code to sign in as the named email address, so strictly limit group membership. Workspace invitation emails still use Resend or SMTP.

Using Resend

Verify a sending domain and create an API key at Resend.

Set:

RESEND_API_KEY=re_xxxxxxxxxxxxxxxx
RESEND_FROM_EMAIL=[email protected]

Restart the API service.

RESEND_FROM_EMAIL must belong to a domain already verified in Resend.

Using SMTP

At minimum, set the host and sender address:

SMTP_HOST=smtp.example.com
SMTP_PORT=587
SMTP_USERNAME=multica
SMTP_PASSWORD=<password>
SMTP_FROM_EMAIL=[email protected]

Common connection modes:

Scenario	Configuration
Internal anonymous relay	`SMTP_PORT=25`, leave username and password empty
STARTTLS	`SMTP_PORT=587`; upgrades to TLS by default when the server supports it
Implicit TLS	`SMTP_PORT=465`, or set `SMTP_TLS=implicit` explicitly

If SMTP_FROM_EMAIL is unset, it falls back to RESEND_FROM_EMAIL. Private CAs or self-signed certificates require adding the CA to the container trust store; SMTP_TLS_INSECURE=true skips certificate verification and should only be used temporarily on a trusted internal network.

Some strict relays also require a valid EHLO name:

SMTP_EHLO_NAME=mail.example.com

Behavior without a verification backend

The server still starts, but verification codes and invitation links are only written to the log; no delivery is attempted. This suits local development, not production.

The startup log states whether the current mode is Feishu webhook, SMTP relay, Resend API, or DEV mode.

Fixed local verification code

Local automated tests can set a fixed verification code:

APP_ENV=development
MULTICA_DEV_VERIFICATION_CODE=888888

The code must be 6 digits. The fixed code is ignored when APP_ENV=production.

Do not enable a fixed code on a publicly reachable instance. The production combination is APP_ENV=production with an empty MULTICA_DEV_VERIFICATION_CODE.

Create an OAuth 2.0 client in the Google Cloud Console.
Add the Multica frontend's callback URL to Authorized redirect URIs:
```
https://multica.example.com/auth/callback
```

Set:

GOOGLE_CLIENT_ID=xxxxx.apps.googleusercontent.com
GOOGLE_CLIENT_SECRET=GOCSPX-xxxxxxxxxxxxxxx
GOOGLE_REDIRECT_URI=https://multica.example.com/auth/callback

Restart the API service.

The URLs in the Google Console and in GOOGLE_REDIRECT_URI must match exactly, including protocol, port, and trailing slash. Once configured, the sign-in page shows a Google sign-in button; the frontend image needs no rebuild.

Three variables together decide whether a new account can be created:

Variable	Effect
`ALLOWED_EMAILS`	Full email addresses allowed to sign up, comma-separated
`ALLOWED_EMAIL_DOMAINS`	Email domains allowed to sign up, comma-separated
`ALLOW_SIGNUP`	Whether signup is allowed when no allowlist is configured; defaults to `true`

The evaluation order is:

The email matches ALLOWED_EMAILS — allow.
Or its domain matches ALLOWED_EMAIL_DOMAINS — allow.
With no match, if ALLOW_SIGNUP=false — reject.
With ALLOW_SIGNUP=true but any allowlist configured and no match — still reject.
With no allowlist configured and ALLOW_SIGNUP=true — allow.

Common configurations:

# Company domain only
ALLOW_SIGNUP=false
ALLOWED_EMAIL_DOMAINS=company.com

# Also admit one external collaborator
ALLOWED_EMAILS=[email protected]

Both allowlists also work as an explicit exception list when ALLOW_SIGNUP=false.

Invitations do not automatically bypass signup restrictions:

If the invitee already has a Multica account, they can sign in and accept the invitation.
If they do not, their email must satisfy the signup rules above.

To invite a new member on an instance with open signup disabled, add their email to ALLOWED_EMAILS first. Once the account is created and the invitation accepted, you can remove the entry again.

Session lifetime

Browser sign-ins last 30 days by default. Adjust with AUTH_TOKEN_TTL, which accepts a Go duration or a positive integer of seconds:

AUTH_TOKEN_TTL=720h

Restart the API service after changing it. The value only affects sign-in cookies and JWTs issued afterwards; it does not extend tokens that were already issued.

Next steps

Environment variables — the full variable reference.
Authentication and tokens — sign-in sessions and token types.
Members and roles — invitations and roles.

On this page