Google Calendar

The Google Calendar integration connects mTime with your employees’ Google calendars, so meetings they have already had can be turned into timesheet entries, and approved time off shows up in their calendar automatically.

Unlike the HR integrations, this one syncs no employee data. It works on each person’s own calendar.

What it does

Pre-fills timesheets from finished meetings. mTime reads the events in an employee’s calendar and offers the ones that have already ended as time they can put on their timesheet. Nothing is written to the timesheet without the employee doing it. Meetings marked “free”, all-day markers, meetings the employee declined and out-of-office blocks are not offered as worked time.

Blocks the calendar when time off is approved. When a time-off request is approved, mTime writes an out-of-office entry into the employee’s calendar covering the approved period. It is a timed entry (not an all-day one) and it is marked “busy”, so colleagues looking for a free slot see that the time is taken. When the time off is cancelled, mTime removes the entry again.

mTime never cancels or deletes a meeting. The only entries it creates or removes are its own out-of-office blocks. Declining an invitation is possible, but only when the employee has asked for it — see What each employee sees.

mTime reads only what it needs from each event: the title, the times, the location, whether it is marked free or busy, and whether the employee themselves declined it. It never reads who else was invited.

Two ways to connect

Turning the integration on is a workspace decision. How mTime is allowed to reach the calendars is a separate choice, made in the Calendar access field on the integration page. The two options cover different situations — neither is a better version of the other.

	Each employee connects their own Google account	Workspace-wide, through a service account
Who authorizes	Each employee, for their own calendar	One Google Workspace super administrator, for the whole domain
What employees have to do	Grant access once, from their own Security page	Nothing
Can an employee say no?	Yes — not connecting is how they decline	No
What mTime stores for the workspace	Nothing	One service account key
Setup effort	Turn the integration on	A Google Cloud project, a service account, and a grant in the Google Admin console
Works for employees outside your Google Workspace account	Yes	No

Each employee connects their own Google account is the default, and the one Google itself recommends. Employees who never connect simply have no calendar in mTime, and nothing else about their use of mTime changes.

Workspace-wide exists for organizations that do not want to ask their workforce to connect anything — or cannot rely on them doing it. It gives mTime access to every employee’s calendar in one step. Read Before you choose workspace-wide access before picking it.

You can switch between the two later. Switching to per-employee access stops mTime reaching any calendar until each employee connects their own account; switching to workspace-wide makes every employee’s calendar reachable at once.

Who workspace-wide access cannot reach

Workspace-wide access is granted inside one Google Workspace account, and it only covers people who are users in that account. It can never reach:

Consumer Google accounts (@gmail.com and similar). There is no Google Admin console behind a personal account and no domain to authorize, so there is nothing to grant.
Employees whose Google account belongs to a different Google Workspace account — contractors signed in on their own company’s domain, or an organization still split across two Workspace accounts after a merger. Google refuses to let mTime act for them.

Secondary domains inside the same Google Workspace account are fine. It is a different Workspace account that is the problem, not a different domain name.

These people need per-employee access instead. If most of your organization is in one Workspace account and only a handful of people are not, be aware that a workspace can use only one of the two modes at a time: choosing workspace-wide leaves those people without a calendar in mTime.

Before you choose workspace-wide access

Workspace-wide access is a decision about your employees’ personal data, so it is worth stating plainly what it means.

With workspace-wide access, for every employee it covers, mTime:

reads their calendar events, including the event titles. Meeting titles are personal data — they carry names, medical appointments, job interviews, customer and deal names.
writes out-of-office blocks into their calendar when their time off is approved, and removes them when it is cancelled.

It does this for employees who were never asked and who have no way to opt out. With per-employee access, not connecting is how someone declines; with workspace-wide access that choice does not exist.

Because of that, mTime requires a documented privacy sign-off before workspace-wide access is turned on for a customer: a named decision, on your side, that your workforce does not need to consent individually. Talk to mTime support before setting this up. It is not a switch to flip for convenience.

The one personal choice that still applies in workspace-wide mode is what happens to meetings that clash with approved time off. Employees who never open their Preferences page get the default, which is Keep my meetings — mTime blocks the time in their calendar and leaves their existing meetings exactly as they are.

Setting up workspace-wide access

This is the long path. Plan on it taking a Google Workspace super administrator half an hour, plus a wait for Google to apply the change.

Before you start

You need:

A Google Cloud project your organization controls. A new, empty project used only for this is the cleanest option.
A Google Workspace super administrator for your domain. Nothing less can authorize the access. If your organization has multi-party approval turned on, a second super administrator has to approve the change before it takes effect.
Permission to change workspace settings in mTime.

Step 1 — Create the project and turn on the Calendar API

In the Google Cloud console, create a project or open the one you want to use.
Go to APIs & Services > Enabled APIs & services > Enable APIs and services.
Search for Google Calendar API and turn it on.

Do not skip this. If the Calendar API is off, everything else below will look correct — mTime will accept the key, the Admin console will show the grant — and every calendar will still be empty, with no error that points at the cause.

Step 2 — Create the service account and its key

Still in the Google Cloud console, in the same project:

Go to IAM & Admin > Service accounts > Create service account.
Give it a name that says what it is, such as mtime-calendar.
Do not grant it any project roles. It needs none. Its access comes from the grant you make in step 3, not from anything inside the Cloud project.
Open the finished service account and go to Keys > Add key > Create new key > JSON, then download the file. This is the only copy — Google will not show it again. Treat it like a password.
From the service account’s details page, note two values. You need both, for two different places:
- its email address, which looks like mtime-calendar@your-project.iam.gserviceaccount.com
- its Client ID, a number of about 21 digits. Google also labels this the Unique ID, and it appears under Advanced settings as well.

Step 3 — Authorize the service account for your domain

Signed in as a super administrator at admin.google.com:

Go to Menu > Security > Access and data control > API controls.
Under Domain-wide delegation, click Manage Domain Wide Delegation.
Click Add new.
In Client ID, paste the numeric Client ID from step 2.5.
In OAuth scopes, paste exactly this one scope:
```
https://www.googleapis.com/auth/calendar.events
```
This is the only access mTime asks for. Do not add calendar or calendar.readonly as well — a wider grant gives away more than mTime will ever use.
Click Authorize.

Paste the numeric Client ID, not the service account’s email address. This is the mistake nearly everyone makes. Google’s form accepts the email address without complaint, the grant appears in the list as if it worked, and then mTime cannot reach a single calendar — and the failure looks exactly like “the administrator never granted access”. If the row you added shows an email address rather than a number, delete it and add it again with the number.

If your organization uses multi-party approval, the grant sits pending until a second super administrator approves it, and nothing works until they do.

Google applies the change within a few minutes in most cases, but its own guidance is that it can take up to 24 hours. If step 5 fails right after you authorize, wait before assuming you got something wrong.

Step 4 — Enter the credentials in mTime

Go to Integrations and select Google Calendar.
Set Calendar access to Workspace-wide, through a service account.
In Service account email , enter the service account’s own email address from step 2.5 — the client_email from the key file. This is not a person’s address. mTime shows it back to you later so you can see which service account is in use.
In Service account key , paste the entire contents of the JSON file you downloaded, including the outer { and }.
Click Save , then turn the integration on.

mTime stores the key encrypted and never shows it back to you — the field is always empty when you return to the page. That also means every save of this integration has to include the key again, even when you only came to change something else. Keep the JSON file somewhere safe until you are finished configuring.

If mTime refuses the key, the message names the field that is wrong. Two happen in practice:

"type" is missing — you pasted an OAuth client-secret file. That is the other JSON file the Cloud console offers; it is not a service account key. Go back to step 2.4.
"private_key" holds no PEM block — the paste was cut short. The text must contain a line reading -----BEGIN PRIVATE KEY-----.

Step 5 — Check that it worked

Open the service account’s details page in the Google Cloud console and the Manage Domain Wide Delegation list in the Admin console side by side, and compare the Unique ID with the Client ID on mTime’s row, digit for digit. Getting this wrong is the single most common cause of “nothing works”.
Pick an employee who has not connected their own Google account and whose mTime email address is their Google Workspace address. Open something calendar-backed for them — their timesheet’s calendar events, or the count of overlapping meetings on a time-off request. Events showing up there means the whole chain works.
If you have anyone you expect not to be covered (a contractor on another domain), check them too, and confirm that only they are affected. One unreachable person must not stop everybody else’s calendar from working.

Setting up per-employee access

Much shorter:

Go to Integrations and select Google Calendar.
Leave Calendar access on Each employee connects their own Google account.
Turn the integration on.

There are no workspace credentials to enter. From that point on, each employee grants access to their own calendar themselves, and until they do, mTime does nothing with their calendar.

What each employee sees

Connecting (per-employee access only)

Each employee goes to Security and finds Google Calendar under Connected accounts, with a Grant access button. Google asks them to confirm, and they come back connected.

A few things worth knowing when helping someone through it:

They can connect a different Google account than the one they sign in with. If they do, mTime says so on the page: it uses the calendar of the connected account, not the one they log in with. That is allowed on purpose — some people sign in to mTime with one address and keep their calendar somewhere else.
If they ever revoke access from their Google account settings, the row changes to say that access was revoked, and they need to reconnect. Until they do, mTime silently stops using their calendar.
Disconnecting is always available to them, from the same page. Out-of-office blocks mTime already wrote stay in their calendar.

With workspace-wide access there is no Connected accounts row for the calendar at all, and no connect button — there is nothing for an employee to connect, and their calendar already works.

Choosing what happens to conflicting meetings

Every employee whose calendar mTime can reach — in either mode — gets a Conflicting meetings choice under Preferences, in the Calendar section. It applies to meetings that overlap their approved time off:

Option	What it does
Keep my meetings (default)	Blocks the time in the calendar and changes nothing about existing meetings
Decline new invitations	Invitations that arrive after the block is written are declined automatically; meetings already in the calendar are left alone
Decline all conflicting invitations	Every meeting overlapping the block is declined

mTime declines nothing unless the employee chooses one of the declining options. Meetings they organize themselves are never cancelled.

Declining is not fully reversible. If the time off is later cancelled, mTime removes the out-of-office block, and the declined meetings come back — but they come back needing a reply, not with the answer the employee originally gave. Their original responses are not restored.

Troubleshooting

Symptom	Cause	What to do
No calendar works for anyone — every employee’s events are empty and no out-of-office blocks are written	The domain-wide delegation grant is missing, does not include the `calendar.events` scope, or was added with the service account’s email address instead of its numeric Client ID. This is also what you see in the first minutes after authorizing, before Google has applied the change.	Redo step 3, checking the number in the Admin console against the service account’s Unique ID in the Google Cloud console. Then wait — up to 24 hours. Also check that a second super administrator has not been left with a pending approval.
Everything works except one employee, whose calendar is empty	That person’s mTime email address is not a user in the Google Workspace account that granted the access — a typo, a suspended or deleted Google account, a consumer `@gmail.com` address, or someone on a different Workspace account entirely.	Correct the address in mTime or in Google. If they genuinely are not in your Workspace account, they cannot be covered by workspace-wide access at all — see Who workspace-wide access cannot reach. Do not change the delegation grant; it is working.
No calendar works for anyone, and mTime reports that the credential was refused	The key itself was rejected: a wrong or truncated paste, or a key that has since been deleted or replaced in Google Cloud.	Paste a current key (step 4). The Admin console grant is fine — leave it alone.
Everything above checks out — the grant shows the right number and the right scope, mTime accepted the key — and calendars are still empty	The Google Calendar API is not turned on in the Google Cloud project. Nothing in the delegation setup reveals this.	Turn it on (step 1).
Saving the key fails, with a message about a missing `"type"`	You pasted an OAuth client-secret file instead of a service account key.	Create a service account key (step 2).
Saving the key fails, with a message about the private key	The paste was cut short.	Paste the whole file, including the `-----BEGIN PRIVATE KEY-----` line and the outer braces.
None of the above fits	mTime asked Google for something Google did not recognise. No configuration change on your side causes this, and none fixes it.	Contact mTime support. This one is a bug on our side.
An employee (per-employee access) sees “Access was revoked — reconnect to continue”	They revoked mTime’s access from their Google account, or changed something Google treats the same way.	They reconnect from Security.

Rotating the service account key

Google’s authorization is tied to the service account’s Client ID, which does not change when its key does. So rotating the key is an mTime-side change only — do not touch the Google Admin console and do not re-authorize anything.

Do it in this order:

In the Google Cloud console, on the service account: Keys > Add key > Create new key > JSON. Both the old and new key are valid now.
Paste the new key into mTime and save (step 4).
Confirm calendars still work (step 5).
Only then delete the old key in the Cloud console.

Deleting the old key first would break every employee’s calendar until the new one is saved.

Rotating a key is not a way to cut access off quickly. Access Google already granted stays usable until it expires, which takes up to about an hour. If you need access stopped, see below.

Turning workspace-wide access off

To stop mTime reading or writing calendars in your domain:

In the Google Admin console, go to Security > Access and data control > API controls > Manage Domain Wide Delegation, find the row with mTime’s Client ID, and delete it. This is the step that matters: without it, no key anyone holds can reach a calendar.
Delete the service account in the Google Cloud console. This deletes its keys and makes the credential useless even if the key file leaked. An abandoned service account whose grant was merely removed can be re-authorized by any future administrator.
In mTime, switch Calendar access back to per-employee, or turn the Google Calendar integration off, so mTime stops trying.

Between the first step and the last, mTime keeps trying and keeps failing — that is expected, not a second problem to fix.

Two things to plan for:

It is not instant. Access Google already issued stays valid until it expires, up to about an hour after you delete the grant.
Out-of-office blocks mTime already wrote stay in employees’ calendars. Nothing removes them afterwards. They would normally be removed when the time off behind them is cancelled, and once access is gone that is no longer possible. If you want them cleaned up, do it before revoking.

Next steps

See Integrations for how to turn an integration off and what happens to its data.

Microsoft Entra ID API access