Calendar links

Kipdown exchanges iCal calendars with other booking sites. These are availability links, not a live connection for prices, payments or guest details. For the owner’s setup steps, see Connect Airbnb, Hipcamp, Pitchup and Booking.com.

Get the correct link

1. Open Settings → Other booking sites.
2. Copy the calendar link for the stay, or the individual named place, that the other listing sells.
3. Give that link to the other booking site’s calendar import. To bring its bookings into Kipdown, add its export link in Kipdown too. These are two separate directions.

Copy the complete link from the screen. Its form is:

https://app.kipdown.com/api/book/your-business/calendar/stay-slug.ics?key=TOKEN

A named place adds &place=PLACE_ID. The slug identifies the stay; the place id identifies one named tent, room or cottage. The token allows the calendar to be read without signing in. Keep the link private. An invalid key, unknown stay, archived stay or invalid place returns 404.

What Kipdown publishes

The response is text/calendar; charset=utf-8 with Cache-Control: no-store. It is generated when requested, covering 30 days before today through the number of months ahead selected in the settings; the default is 12 months. The setting accepts 1–36 months.

It contains unavailable stretches, labelled Booked or Closed, rather than individual guests’ bookings. Consecutive nights with the same label become one event. No guest names, contact details, prices or payments are published.

A stay is full when another booking would not fit using the largest quantity and people count configured for its linked calendars (at least one of each). This includes quantity, named places, people limits and any places held back for direct bookings. A named place’s link marks that place’s occupied nights, and also respects the stay’s people limit. Closed nights are included from today onwards.

The exported iCal format

Kipdown writes iCalendar 2.0 with CALSCALE:GREGORIAN, METHOD:PUBLISH and an X-WR-CALNAME. Each event has a UID, a UTC DTSTAMP, all-day DTSTART and DTEND, SUMMARY, and TRANSP:OPAQUE.

BEGIN:VEVENT
UID:2027-08-13-2027-08-15-your-business-bell-tent@kipdown.com
DTSTAMP:20261109T120000Z
DTSTART;VALUE=DATE:20270813
DTEND;VALUE=DATE:20270816
SUMMARY:Booked
TRANSP:OPAQUE
END:VEVENT

DTEND is exclusive: this example blocks the nights of 13, 14 and 15 August, leaving 16 August free. UIDs describe the unavailable stretch, so can change when stretches join or split. Lines use CRLF, text is escaped, and long lines are folded at 75 UTF-8 bytes without splitting a character.

What Kipdown reads

An incoming link must be an HTTP or HTTPS calendar URL, not a listing or sign-in page. webcal:// links are converted to HTTPS. Each link is assigned to one stay or one named place, with how many places and people each event takes. Calendars do not supply reliable party sizes, so Kipdown uses those configured counts.

Kipdown reads VEVENT entries with DTSTART, an optional UID and SUMMARY, and either DTEND or a positive whole-day/week DURATION. An all-day event with neither end nor duration takes one night. A timed event without either is skipped.

All-day dates use YYYYMMDD. UTC date-times ending in Z are converted to the business’s local date. Other date-times, including those marked with TZID, use the date as written; Kipdown does not convert that zone. DTEND is the leaving date.

Cancelled events are omitted. Repeating events with RRULE, RDATE or RECURRENCE-ID and unreadable dates are skipped and reported. Identical UID-and-date duplicates count once. Missing UIDs are derived from dates and listing order; stable UIDs are preferable. SUMMARY supplies the booking’s name, not an email address or a price.

Timing and safeguards

Kipdown checks other sites’ calendars every 15 minutes, and checks immediately when a link is added or changed. Check now requests a check. Links checked least recently go first; large updates can continue on later runs. The other site decides how often it reads Kipdown’s link, so changes are not instant in either direction and overlapping bookings remain possible.

Incoming bookings are recorded as confirmed, without prices or extras. Clashes are recorded as double bookings rather than silently discarded. To avoid echoing bookings back, events matching Kipdown’s own unavailable stretches are skipped.

A calendar over 5 MB, an incomplete file, or more than 5,000 future events changes nothing. Fetches time out after 15 seconds. An empty calendar with existing linked bookings, or removals affecting more than 30% and more than two existing future bookings, are treated as failures. Otherwise, cancellation needs two checks at least ten minutes apart that both miss the event. Stays already under way keep their booking, but can follow a changed leaving date; ended stays are left alone.

These links cannot transfer payments or keep prices, extras and guest details in step between systems.