Microsoft Azure App Setup
Register an Azure app for Tymeslot. Enables Outlook Calendar sync and Teams meetings. Covers API permissions and admin consent requirements.
Create one Google OAuth app for Google Login, Google Calendar sync and Google Meet room creation.
Updated 17 June 2026
By the end of this guide, one Google Cloud project serves Google Login, Google Calendar sync and Google Meet room creation.
One Google Cloud project covers all three Google integrations in Tymeslot, so you only go through this setup once.
You create and manage this OAuth app in Google Cloud Console (formerly Google Developers Console). All three integrations use the same credentials.
Go to [APIs & Services] → [Library] in the left sidebar and enable the APIs listed below. After you click [Enable], the API's management page opens, and a [Manage] button confirms it is active.
Required for Calendar sync.
Tymeslot does not call it: Google Login reads the user's name and email from Google's standard userinfo endpoint, which needs no extra API. You can skip it.
Required for Google Meet: Tymeslot creates Meet links through this API. Skip it only if you are not using Google Meet.
Enable the APIs one at a time: search by name, click the result card, then click [Enable], and return to the Library for the next one.
Navigate to [APIs & Services] → [OAuth consent screen]. This configures the screen your users see when they authorise access to their Google account. Newer versions of the console call this section Google Auth Platform and split the same settings across Branding (app name, authorised domains), Audience (user type, test users, publishing) and Clients (the credentials in Step 4).
yourdomain.com).
Go to [APIs & Services] → [Credentials] → [Create Credentials] → [OAuth 2.0 Client IDs].
https://yourdomain.com/auth/google/callback
https://yourdomain.com/auth/google/calendar/callback
https://yourdomain.com/auth/google/video/callback
redirect_uri_mismatch
error, the callback URL registered in Google does not exactly match the one Tymeslot sent. Google's error page shows the URI it received under the error details; add that exact URL to the
[Authorized redirect URIs]
list. The match is case-sensitive and includes the scheme (https://), port if any, and path with no trailing slash.
Add the following to your Tymeslot environment and restart it.
# Enable Google Login
ENABLE_GOOGLE_AUTH=true
# OAuth credentials (from the dialog in Step 4)
GOOGLE_CLIENT_ID=123456789-abcdefg.apps.googleusercontent.com
GOOGLE_CLIENT_SECRET=GOCSPX-xxxxxxxxxxxxxxxx
# Random secret used to sign the OAuth state parameter
GOOGLE_STATE_SECRET=your-random-32-char-secret
Generate a secure state secret with:
openssl rand -hex 32
ENABLE_GOOGLE_AUTH=true
adds the Google button to your sign-in page. Leave it out if you only want Google Calendar or Meet without offering Google sign-in; all three use the same credentials.
GOOGLE_STATE_SECRET
is the other way round: Calendar and Meet connections need it, while Google Login does not use it.
"Access blocked: [app] has not completed the Google verification process"
Your OAuth consent screen is in testing mode and the account trying to sign in is not in the [Test users] list. Add the user's Google account email under [APIs & Services] → [OAuth consent screen] → [Test users], or publish the app to remove the restriction.
"Access blocked: Authorization Error"
Click the error details link: Google names the cause there, such as a wrong client ID (invalid_client), an unregistered redirect URI, or an unsaved consent screen. For the last, return to Step 2, confirm each API shows a
[Manage]
button, and repeat Step 3.
Calendar sync fails after login succeeds
Google Login and the Calendar connection are separate OAuth flows: Tymeslot asks for Calendar access only when a user connects Google Calendar from the dashboard. If that step fails, confirm the
Google Calendar API
is enabled (Step 2), that
/auth/google/calendar/callback
is among your redirect URIs (Step 4), and that
GOOGLE_STATE_SECRET
is set.
Yes, for a self-hosted instance that has not been through Google's verification. Users can click [Advanced] and then [Go to (your app name) (unsafe)] to continue, which is acceptable for a private or internal deployment. For a public instance, submit the app for verification from the OAuth consent screen. Google reviews Calendar access more closely, so describe clearly how the data is used.
The URI must match exactly: same scheme (https://), same domain, same path, and no trailing slash. Each feature also has its own URI, so a Calendar or Meet connection needs the matching URI from Step 4. Changes can take a few minutes to apply after saving, so wait and try again, or open the Credentials page to confirm the URI was saved.
Only if your app is in Testing publishing status. In Testing mode, only accounts explicitly listed under [Test users] can authorise the app, and everyone else sees an "Access blocked" error. To open sign-in to any Google account, click [Publish App] on the OAuth consent screen to switch to In production status.
Internal limits sign-in to accounts in your Google Workspace organisation; nobody outside it can authorise the app. External allows any Google account to sign in, subject to your publishing status (Testing or In production). Choose Internal if Tymeslot is only for your team and everyone has a Google Workspace account in your organisation.
Start with the [Credentials] page in Google Cloud Console and confirm the OAuth 2.0 client still exists and its secret has not been deleted or replaced. Next, check the [OAuth consent screen] to confirm the app is not restricted. Google may also suspend a project over a billing issue or policy violation; check the [IAM & Admin] → [Settings] page for any project-level warnings.
Register an Azure app for Tymeslot. Enables Outlook Calendar sync and Teams meetings. Covers API permissions and admin consent requirements.
Let your team and customers sign in to Tymeslot with their GitHub account. Create an OAuth app, set two environment variables, and you're done.
Connect any OAuth 2.0 / OpenID Connect identity provider for single sign-on. Supports Keycloak, Authentik, Lemonldap::NG, Okta, Azure AD, and more.