Hi Kemal,

I’d be careful about concluding this is definitely Vercel blocking dataaccessd just from the app logs. If the request fails at TLS, redirect validation, HEAD handling, or a firewall layer before the function runs, you may also see no application log entry.

For iOS Calendar, I’d test the feed like an automated calendar client instead of only from a browser:

1
URL="https://www.gocutit.com/api/sync/calendar/example.ics"
2

3
curl -i -L "$URL"
4
curl -I -L "$URL"
5
curl -i -L \
6
  -A "dataaccessd/1.0" \
7
  -H "Accept: text/calendar,*/*" \
8
  "$URL"
9

I’d want all of those to return a plain 200, not a challenge page, login page, HTML page, or redirect loop. The response should look roughly like:

1
HTTP 200
2
Content-Type: text/calendar; charset=utf-8
3

4
BEGIN:VCALENDAR
5
VERSION:2.0
6
...
7
END:VCALENDAR
8

A couple of iOS-specific things I’d check:

1
- HEAD requests return 200, not 405/404
2
- the final URL after redirects is still HTTPS
3
- there is no auth cookie/session requirement
4
- no HTML is returned for unknown/expired calendar tokens
5
- the feed works from the apex/www version you actually paste into iOS
6
- the URL contains no unescaped spaces, brackets, or copied punctuation
7

If the dataaccessd curl test works but the phone still fails, I’d check Vercel Firewall events for the exact timestamp. A normal custom bypass rule only helps if a custom/managed rule is the thing blocking the request; if it is a TLS/DNS/validation issue, the bypass rule will not change anything.

As a stronger isolation test, I’d deploy the same static .ics file on a completely plain path like:

1
/calendar-test.ics
2

with no API route, no rewrite, no middleware, no auth, and no custom firewall rule. If iOS still fails on that plain static file while Google/Outlook work, then the next useful evidence is the exact URL form pasted into iOS, the curl -I -L output, and whether the failure happens on both Wi-Fi and mobile data.