How were the commands extracted from Google/Yahoo/Outlook?

[RoninSapinoso]

I'm currently in need of creating a Yahoo link that would be set up to repeat after a certain amount of days. I checked the documentation and saw that a lot of fields were familiar, though I noticed that the RPAT command was labelled as deprecated.

I was wondering how those commands were deemed and confirmed as deprecated. Moreover, how they were accessed/found in the first place, especially since there is no official documentation during the time of this post.

Either way, thank you for taking the time to compile all of these! They have proven to be extremely beneficial.

[alies-dev]

Good question, and the answer also fixes the specific problem you hit: RPAT is not deprecated. It works today, and the documentation was wrong. Re-tested on 2026-08-19.

For "repeat every N days" the value is the interval followed by the unit:

https://calendar.yahoo.com/?v=60&TITLE=Test&ST=20261231T193000&ET=20261231T223000&RPAT=03Dy

03Dy is every three days, 01Wk weekly, 01Mh monthly, 01Yr yearly. Weekly patterns can carry weekdays, for example 01WkMoWeFr. If you want an end date, REND must carry a leading plus (REND=%2B20270331), a unix timestamp, or -Nt for a number of occurrences. A bare REND=20270331, which is what the old document showed, is silently dropped.

How this is found

There is no single technique, it depends on where each service does the parsing.

Yahoo is the easiest, because it parses the query string in the browser. The whole mapping is one table in bundle_epoch_calendar.js:

{ST:"startTime", ET:"endTime", uid:"uid", recurId:"recurId", TITLE:"summary",
 in_loc:"location", DESC:"description", inv_list:"attendees", DUR:"allDay",
 REM1:"reminders", REM2:"reminders", TYPE:"type", RPAT:"recurrence",
 VIEW:"view", REND:"recurrence_end"}

The function right next to it (qm) shows the exact handling of each one: how RPAT is tokenised, which reminder offsets are accepted, why DUR is ignored when ET is present. Because the table is exhaustive, it also proves the negative: anything not in it (in_st, in_csz, in_ph, URL, remadr, msngr) is dropped.

Google works the same way. The deep link parser lives in the calendar-web modules, and reading it turned up parameters nobody had documented, such as stz/etz for separate start and end timezones, targ as a higher priority version of src, and the _o suffix on add for optional guests. It also proved that trp no longer exists anywhere in the client, which is why setting it does nothing.

Outlook cannot be read this way at all. None of the parameter names appear in the 68 JavaScript chunks the compose page loads, and the query string vanishes from the address bar once the form renders, so the mapping happens on the server. There the only method is replaying parameters against the live form and observing what changes, which is why that document now labels each parameter as verified, no effect, or not observable.

The general recipe: open the composer with parameters set, find the application bundle in the network panel, search it for one parameter name you already know works, and the surrounding code usually contains the full table. Then replay everything against the live UI, because a parameter can be parsed and still be ignored downstream (Google's erem is exactly that case).

Deprecation claims are the part most worth re-checking. "Deprecated" in these documents usually meant "did not work when someone tried it", and both RPAT and DUR turned out to work fine.