Skip to main content
Schedule items are the timed events on a tour day — soundchecks, travel, set times, and so on. They belong to a tour and a specific day. Schedule item IDs are integers. All endpoints require the standard authentication headers.

List schedule items

Returns the schedule items for one day of a tour. Scope: schedule.read Example
Path parameters Response data — array of schedule items. Each item includes timing, location, routing, and metadata:
schedule_item_tags is where an item’s tags come back — read the current set from here before calling PUT /v1/schedule/items/{itemId}/tags, which replaces the whole set rather than appending to it.

Create a schedule item

Scope: schedule.write Body — common fields (the underlying model supports more; see notes below):
Time format: startTime and endTime are 24-hour HH:mm time-of-day strings (e.g. 14:00), not ISO 8601 datetimes. The calendar date is taken from day_id.Travel items require an origin: when type is a travel item type (item types 2–6, e.g. drive, flight, walk), origin is required (and destination is normally included). Each is a { formatted_address, viewport, timeZone } object. Omitting origin on a travel item returns 400 VALIDATION_ERROR — “Travel items (type 2-6) require an origin”.
Response data: { "id": 9021 } — plus the item’s reminders with their server ids when the request sent a reminder list. See Reminder ids on a write.

Visibility

Four fields control who on the tour can see an item:
If you send no visibility fields at all, the item is NOT visible to everyone — isEveryone defaults to false, so regular tour members won’t see it (admins and the creator still do). Most integrations should send isEveryone: true explicitly unless they’re targeting specific members.Also: isEveryone: true and isAdminsOnly: true together return 400 (conflicting flags) — send at most one of the two.
Restricting an audience adds every tour admin unless you send explicitVisibility: true.When you name a restricted audience — visibilityList and/or invitesVisibilityList — Daysync assumes an older client that treats admin access as implicit, and merges the tour’s current admin list into the audience you sent. So visibilityList: ["alice-uuid"] on a tour with four admins results in five people seeing the item, not one.Send explicitVisibility: true with the same request to mean the list literally:
This applies to create and update alike — including an update that only narrows an existing item’s audience. Note that admins and org owners retain access to tour content through their role regardless; explicitVisibility controls the stored audience list, not their privileges.Do not send it with isAdminsOnly: true. “Admins only” is implemented by that same merge — the admin list is the audience it resolves to — so opting out would store an empty audience and hide the item from everyone. Send isAdminsOnly: true on its own.

Attachments

Attachments are Daysync-hosted. Upload a file with POST /v1/attachments (which fetches a URL and stores the file), then pass the returned link here. link is a Daysync storage key, not an external URL:
Only link is required (get it from POST /v1/attachments). fileSize is in bytes.
Don’t pass an external URL (e.g. your own CDN link) as link — Daysync treats link as one of its own storage keys and builds the public URL from it, so a foreign URL renders broken. Always upload via POST /v1/attachments first.

Update a schedule item

Scope: schedule.write Path parameters Body — the update input is a different, narrower set than create. Fields not listed below cannot be changed via update.
Not available on update: tour_id, type. These are set at creation time only. The itemId is taken from the URL path — do not send it in the request body.
Attachment upserts on update — each entry in attachments is processed by shape:
  • No id → creates a new attachment and links it to the item.
  • With id → updates that existing attachment’s fields.
  • With id and "deleted": true → permanently removes that attachment from the item.
Attachment id values come from the item’s attachments in the list response.
Response data: { "id": 9021 } — plus the item’s reminders with their server ids when the request sent a reminder list. See Reminder ids on a write.

Reminder ids on a write

POST /v1/schedule/items and PUT /v1/schedule/items/{itemId} return the item’s reminders with their server-generated ids whenever the request carried a reminder list:
The array is the item’s reminders after the write — not only the ones this request added — sorted by id ascending, and read inside the same transaction, so the ids are authoritative rather than optimistic.
Keep these ids and send them back. A reminder entry submitted on update without an id is created as a new row, so a client that discards the ids duplicates every reminder on every save. That is the whole reason this echo exists.
reminders is present only when the request sent a reminder list. A write that did not touch reminders answers { "id": 9021 } exactly as before, so nothing an existing integration reads has changed shape.POST /v1/schedule/items/batch does not echo reminders — it answers { "ids": [...] }. Use the single-item create when you need the ids back.Over MCP, the same rows come back from create_schedule_item and update_schedule_item.

Create many schedule items

Creates several items in one request. Use this instead of looping POST /v1/schedule/items when adding a set of items — it is one round trip and one transaction. Scope: schedule.write Body Example
Response data: { "ids": [9021, 9022] } — the new item IDs, in request order.
An empty, missing, or non-array items returns 400 VALIDATION_ERROR — “items must be a non-empty array of schedule items”. It is not treated as a successful no-op, so a caller whose item-building step produced [] finds out rather than seeing a 200 with nothing created.
Every item still needs its own tour_id and day_id — items in one batch may span different days of the same tour. The visibility rules in Visibility apply per item, explicitVisibility included.

Restore a deleted schedule item

Reverses a DELETE — deletes are soft, so a removed item can be brought back with its content intact. Scope: schedule.write Path parameters Response data: none (status + message only).

Confirm every item on a day

Marks every schedule item on the day as confirmed, in one call. Scope: schedule.write Path parameters Response data — the items the call actually changed, so it can be undone:
Keep both arrays if you may need to reverse the operation — together they are exactly the set of items whose status this call changed. Items already confirmed are absent from both.

Delete a schedule item

Soft-deletes the item; restore brings it back. Scope: schedule.write Path parameters Response data: none.
See also: Tours, Schedule Templates, Venues, Tags, Custom Fields.