You click Import and see an error. You try again and see it once more. The dates you need still are not there.
The cause is most often in the file. It can also be in how you import. This guide sorts those two apart fast. It then gives a fix order that works.
Import and subscribe are not the same thing
Import and subscribe sound like one act. They are two quite distinct acts. Mix them up and you fix the wrong thing. Mix them up and dates go stale fast.
An import makes a one-time copy. You pick a file on your device. The app reads it once and stops. New stays in the source do not flow in.
A subscribe links to a live feed. You paste a feed link in the app. The app checks that link from time to time. New stays flow in on their own.
| Point | Import | Subscribe |
|---|---|---|
| What it does | One-time copy of a file | Live link to a feed |
| Updates | None unless you redo it | App refreshes on its own |
| You give it | A file on your device | A feed web link |
| Best for | A fixed set of dates | Stays that change often |
If you import a rental feed, dates freeze. A new booking will not show up there. A cancelled stay will not drop out there. Staff may trust dates that are weeks old.
For rental homes, subscribe is the right choice. Each home should have one live feed link. Each app should subscribe to that link. That keeps all apps close to the truth.
If you subscribe and see no dates, think link. The link may be dead or may need a login. If you import and see no dates, think file. The file may be empty or flawed in form.
That split saves you a lot of time. It points you to the right fix at once. It stops you from redoing the wrong step. Write down which path you used each time.
Some apps use the word Add for both acts. Read the small text on that screen with care. Look for the words File or URL there. That tells you which act you are in.
Do not paste a feed link in a file box. Do not upload a file where a link must go. The app will fail and may not say why. That fail looks like a file flaw but is not.
Feed links can hold private tokens in them. Keep each link private and safe at all times. Only use feeds you own or may use. If a link leaks, reset it in your tool.
- Import is a copy made one time
- Subscribe is a live link to a feed
- Rental dates need the live link
- Check if the box wants file or link
Once you know your path, check the file. The next part lists the flaws that block it. Most failed imports trace to just six flaws.
The six errors that stop an import
Most blocks come from a short list. You will see the same six again and again. Learn their signs and you fix them fast. Learn their cause and you stop them for good.
One, the file is not an ICS file at all. The link may give a web page instead. The file may be a login page in HTML. The app reads that code and gives up.
Open the file in a text app to check. A real file starts with BEGIN:VCALENDAR. A web page starts with HTML code tags. If you see a page, the link is wrong.
That is the case with an empty file or a 404. The server found no feed at that link. Or it sent an error page in its place.
Two, a date or time is in bad form. The file may use slashes in a date. It may use words for the month name. Strict apps skip or reject such events.
Three, an event has no end at all. It has a start but no DTEND line. Some apps treat it as a one-day stay. Some apps reject the whole file for it.
Four, two events share the same UID. The UID must be unique for each event. A dup UID can make one stay hide the next. It can also make the app drop both stays.
Five, an event block is not closed well. It may miss its END:VEVENT line in the file. Or the whole file may miss its last line. One open block can break all the rest.
Six, the text has flaws in lines or marks. A line may run past 75 octets in length. A comma may lack its escape slash mark. A file may use wrong line ends too.
These six flaws share one key trait. One bad event can block the whole file. The app may not tell you which event it is. It may just say the import has failed.
That is why one bad stay hurts so much. It is not just that one stay that is lost. All the good stays in the file are lost too. You must find and fix that one event.
Start with a check of the whole file. Do not read hundreds of lines by eye first. A check sorts errors from warnings for you. It points to the line and the event at fault.
Errors mean the app cannot read that part. Warnings mean the app may read it with risk. Fix errors first in all cases you face. Then look at warnings with fresh care.
You can review what a valid ICS file needs to compare. Keep that list open as you fix each flaw. Tick off each part as you confirm it.
- File is a web page, not ICS text
- Date or time in the wrong form
- Event with a start but no end
- Two events that share one UID
- Block or wrap that is not closed
- Long lines or bad escape marks
Note which of the six you found this time. Hosts tend to hit the same flaw twice. A note helps you spot it next time fast. It also helps support staff help you well.
When the file is fine but the app says no
Sometimes the file is sound and still fails. The block then sits in the app or link. Do not keep editing a sound file in vain. Test the app side with a small file first.
Make a test file with just one event. Give it a fresh UID and clear dates. Try to import that small file in the app. If it works, the app is fine in general.
If the small file fails too, the app has limits. It may cap the file size it will take. It may cap the count of events as well. It may block old dates from years past.
Split a large file into small parts then. Import one part at a time in that app. Note which part fails as you go through. The flaw most often sits in that one part.
Some apps reject events with no title text. Add a short SUMMARY to each event you send. Use safe words like Guest stay or Blocked. Do not add guest names or door codes there.
Time zones can make a sound file fail too. An app may not know a zone name in the file. The TZID tag may name a zone it lacks. The event may then shift or get dropped.
Daylight saving can add to that risk too. Clocks shift in spring and in fall each year. An event near the shift is prone to error. Check its zone name and its offset with care.
Access rules can block a live feed link. The server may need a login you lack. It may block apps that fetch too often. It may serve a page to apps but not to you.
A check tool cannot prove a refresh took place. CalendarCheck does not contact Airbnb or Vrbo. It checks content you paste or upload here. It flags errors and shows a timeline view.
That limit is key to grasp in full. A good check means the file is sound. It does not mean the platform read it yet. Only that platform can confirm its own refresh.
Cache can also make a fix look failed. The app may show old dates for a while. Wait and then refresh the view in the app. Check the time of the last refresh it shows.
If sync stays wrong, read about calendars that fall out of sync. That guide covers refresh gaps and stale views. It helps you tell a file flaw from a lag.
| Test | If it passes | If it fails |
|---|---|---|
| One-event file | App works in general | App or format clash |
| Split large file | Size was the block | Flaw is in one part |
| New feed link | Old link was dead | Server blocks access |
| Fresh app or device | Cache was the cause | Issue is in the feed |
Keep each test small and change one thing. If you change three things at once, you learn nil. You will not know which change did the work. Small tests give clear proof you can trust.
A fix order that works
Random fixes waste time and add new flaws. Use a set order each time you hit a fail. The order goes from broad to fine detail. It finds the true cause with less work.
Step one, confirm what you hold in hand. Open the file and check the first line. Open the file and check the last line. Make sure it is ICS text, not a web page.
Step two, run a full check on the file. Save the list of errors it gives you. Save the list of warnings it gives you too. Do not fix from memory or from a guess.
Step three, fix errors at the source tool. Change the stay in the tool that made the file. Then export or fetch a fresh file from it. Do not hand-edit the copy you will import.
Hand edits break line ends and folds fast. They also get lost on the next export run. A source fix stays in place for good. It fixes all apps that use that feed.
Step four, check the fresh file once more. Confirm the errors you fixed are now gone. Confirm no new errors came in with the fix. Only then try the import in your app again.
Step five, import or subscribe the right way. Use a file box for a file import task. Use a link box for a live subscribe task. Wait for the app to confirm it is done.
Step six, verify dates in the target app. Check the first stay and the last stay there. Check one stay in the middle as well. Compare each date to your source list with care.
Look for the classic signs of a bad fix. A stay that lasts one day too long is a sign. A stay that starts one day late is a sign too. A dup stay with the same dates is a sign.
Those signs point back to dates and UIDs. Re-check DTEND and the day of exit rule. Re-check that each UID is still unique there. Do not just import the same file once more.
- Confirm the file is real ICS text
- Run a check and save the results
- Fix each error at the source
- Export fresh and check once more
- Import or subscribe the right way
- Verify first, last, and middle stays
The free preview covers one feed monitor here. Paid Multi-feed covers up to ten monitors in full. It adds daily checks and email alerts for you. That helps when imports fail while you sleep.
Keep a log for each home you run. Note the feed link and the last good check. Note the flaw you fixed and the date you did. That log turns the next fail into a short task.
Most imports fail for a plain cause. Find it, fix it at the source, prove it. That loop works for one home or for ten. It keeps sold nights blocked and free nights open.
Questions about failed imports
Why does the same import fail each time?
The same flaw is still in the file. The app reads the same bad event each time. Fix that event at the source tool.
Should I import or subscribe to a rental feed?
Subscribe for rental dates that change. Import is a one-time copy of a file. Its dates will go stale quite fast.
Can one bad event block all the rest?
Yes, one bad event can block it all. Many apps reject the whole file for one flaw. Find that event and fix it first.
How do I know the fix really worked?
Check the fresh file for errors first. Then verify dates in the target app. Check first, last, and middle stays there.
Sources and further reading
- Northern Illinois University: import an iCalendar file — steps to import an iCalendar file
- Indiana University: iCal feeds and linked calendars — how feeds and linked calendars work
- IETF RFC 5545: iCalendar — the core rules for ICS files
- NIST: local time FAQs — plain facts on local time zones
- IETF RFC 6868 — parameter value encoding rules that strict importers enforce
- NIST: time and frequency FAQs — official answers on time zones, daylight saving time, and how clocks keep time