How Events Get Into Your Calendar: ICS, CalDAV, Google and Microsoft
When an app adds an event to your calendar, it does not type into the calendar window. It talks to your calendar provider through a defined route, and which route it uses decides what the app can read, what it can change and how wrong a time zone can go. This guide explains the four routes you will meet in practice, with the specifications and documentation behind each, so you can judge what a tool really asks of you.
I wrote it because I build one of these tools and the permission screens confuse people, and rightly so. Every fact about a standard or an API below comes from its own specification or documentation, read on 2 November 2026. Facts about Yotei come from our own code and are marked.
Disclosure. I made Yotei, which turns a screenshot into a calendar event and uses three of the four routes below. I say what it asks for, including where that is broader than I would like.
The short answer
- An .ics file is a text file in a standard format that any calendar can import. It has no live connection and no permissions.
- CalDAV is a standard protocol for reading and writing calendars on a server. iCloud, among others, is reached this way.
- The Google Calendar API creates events in a Google calendar after you grant an OAuth permission, called a scope.
- Microsoft Graph does the same for Outlook.com and Microsoft 365 calendars.
Route 1: the .ics file
iCalendar is defined in RFC 5545 as a data format "for representing and exchanging calendaring and scheduling information". A file in that format usually ends in .ics. Because it is only a file, it can come from an email attachment, a website button or an app, and you choose whether to import it.
The format stores times in one of two ways. A time can be local with a named zone, for example DTSTART;TZID=America/New_York:19980119T020000, or it can be in UTC, which the specification says is identified by a Z suffix, "the UTC designator, appended to the time value". A time with neither is "floating" and means whatever local time the reader's calendar is in.
Google Calendar's own help page sets simple rules for importing. A file must start with BEGIN:VCALENDAR, each event sits between BEGIN:VEVENT and END:VEVENT, and the file ends with END:VCALENDAR. Import works only from a computer, and guests and conference data in the file are not imported. For .csv files, the headers must be in English, only Subject and Start Date are required, and repeating events arrive as separate one-time events.
What this means for you: a file import is the safest route, because nothing is connected. It is also the most manual, and it silently drops guests.
Route 2: CalDAV
RFC 4791 extends WebDAV so servers can store and share iCalendar data, which it describes as "a standard way of accessing, managing, and sharing calendaring and scheduling information". Many providers support it, and an app that speaks CalDAV can work with any of them using the same code.
For iCloud, third-party developer documentation and calendar app help pages agree on the practical details: the server is caldav.icloud.com over HTTPS on port 443, the username is your Apple Account email address, and the app must use an app-specific password instead of your normal password. Apple's own page on app-specific passwords is the place to confirm how to create one, and I did not retrieve it, so check it before you follow any guide, including this one. Sources also differ on whether one app-specific password can be reused across apps, which is another reason to read Apple's page.
What this means for you: CalDAV access through an app-specific password is not narrowly scoped. The credential works for the calendar account as a whole, so you should trust the app and know how to revoke the password.
Route 3: the Google Calendar API
To create an event, an app sends POST https://www.googleapis.com/calendar/v3/calendars/calendarId/events, using primary for your main calendar. Google's documentation lists four scopes that can authorise this: calendar, calendar.events, calendar.app.created and calendar.events.owned. The request must contain a start and an end, each with a dateTime in RFC 3339 format. Google adds that "a time zone offset is required unless a time zone is explicitly specified in timeZone", and the zone must be an IANA name such as Europe/Zurich.
The scopes are not equal. The widest, calendar, covers the whole calendar account. calendar.events.owned is narrower: it can create, change and delete events on calendars you own, and nothing on calendars shared with you.
What Yotei asks for (from our code, checked 2 October 2026): calendar.events.owned, the narrowest scope that can create events on your primary calendar, and the only call it makes is the one that inserts an event.
Route 4: Microsoft Graph
For Outlook.com and Microsoft 365, creating an event is POST /me/events in Microsoft Graph. Microsoft's documentation lists Calendars.ReadWrite as the permission for work or school accounts and for personal accounts, for delegated access. The request body carries a start and an end, each with a dateTime and a timeZone, and Microsoft's own example uses a Windows time zone name, "Pacific Standard Time", not an IANA one. The page also notes that setting a transactionId reduces unnecessary retries, which helps avoid duplicate events when a request is repeated.
There is no create-only permission here. Calendars.ReadWrite allows reading as well as writing, even if an app only ever writes.
What Yotei asks for (from our code, checked 3 October 2026): Calendars.ReadWrite, because Microsoft offers nothing narrower for creating events. Yotei only calls POST /me/events and never reads your calendar, but the token you grant technically permits reading, and Microsoft's consent screen says so. I would prefer a create-only scope, and I mention it here because a permission screen should not be a surprise.
Why time zones are the weak point
Look at what each route needs: an explicit zone, or an explicit offset, or UTC. A screenshot of a message usually says "Thursday at 14:00" and nothing more. Somewhere between the picture and the calendar, a person or a program has to decide which zone that is. An app that guesses silently will sometimes guess wrong, and the event will land an hour or several hours off with no sign that anything went wrong.
That is the reason to prefer tools with a review step, where you see the date, time and zone it chose and can edit them before anything is saved. Calendar time zones explained goes through the common cases, and why you should review events before they reach your calendar covers the review step itself.
What to check before you connect an app
- Which route and which scope? The consent screen names it. Prefer a narrower scope when the choice exists, such as
calendar.events.ownedovercalendaron Google. - Does it only write, or also read? An app that reads your whole calendar knows your schedule. Ask what it stores.
- Can you revoke it? You should be able to remove an app's access from your Google or Microsoft account settings, or delete an app-specific password for iCloud.
- Does it show you the event before saving? If not, check events after every use.
- Where does it run? Who processes the screenshot and where is not part of the calendar route, but it matters. See is a calendar app safe to read your screen.
How I made this guide
I read RFC 5545 and RFC 4791 at rfc-editor.org, Google's Calendar API reference for creating events, Google Calendar's import help page and Microsoft's Graph reference for creating events, all on 2 November 2026. The iCloud details come from third-party developer and calendar app documentation, because I could not retrieve Apple's page. The facts about what Yotei requests come from comments in its own source code, written when I checked each provider's documentation in early October. Providers change scopes and wording, so confirm against the current pages. I used no affiliate links. If you find an error, email support@yotei.win and I will fix it.
FAQ
What is an .ics file?
A text file in the iCalendar format, defined in RFC 5545, that calendar apps can import. It carries event details but gives no live connection to your calendar.
What is CalDAV?
A standard protocol, defined in RFC 4791, for accessing and sharing calendar data on a server. iCloud calendars can be reached with it using an app-specific password.
Which Google Calendar scope is the safest for an app that only adds events?
Of the four Google lists for creating events, calendar.events.owned is the narrowest: it covers events on calendars you own and nothing on calendars shared with you.
Why does Microsoft ask for read and write access?
Because the permission for creating events, Calendars.ReadWrite, also allows reading. Microsoft's documentation lists no create-only alternative.
Why do events sometimes land at the wrong hour?
The calendar needs an explicit time zone, and a screenshot usually does not contain one. Check the zone on the review screen before you save.
Yotei