Skip to main content

​
Load a whole tour in one call

The fastest way to hydrate a tour. Instead of paging schedule, venues, accommodation, guest lists, and bulletins day by day, ask for all of it at once:
Returns every day with its scheduleItems, venueItems, accommodations, guestLists, bulletins, and passTypes, plus per-day counts. Narrow it on large tours with dayIds (comma-separated) and the per-resource limits scheduleLimit, bulletinLimit, staysLimit, guestLimit — each capped at 500:
This endpoint requires the read scope for all six resources it returns. See Scopes.

​
Resolve the IDs a write needs

Almost every create fails without the right numeric IDs. One call gets nearly all of them:
Pick what you need out of data.types[] by name — statusTypes, scheduleItemTypes, avatarColors, venueCategories, hotelRoomTypes, and so on. Cache it; these change very rarely. See Reference Data.

​
Tag a schedule item

Tags are per-tour, so read or create the tag first, then attach it.
1

Get a colour

GET /v1/reference/types → data.types[] where name is avatarColors. Take an id.
2

Find or create the tag

GET /v1/tours/{tourId}/tags to see what exists. If it does not, create it:
3

Read the item's current tags

Tags come back on each item from GET /v1/tours/{tourId}/days/{dayId}/schedule, under schedule_item_tags[].tag.id. You need these because the next step replaces the whole set.
4

Set the full tag set

Include every tag the item should end up with — sending only the new one removes the others.
When creating an item you can skip all of this and pass tagIds directly in the create body. See Tags. These recipes show how the endpoints fit together. All calls assume the standard authentication headers; the examples use these shell variables:

​
1. Full tour setup

Stand up a complete tour from scratch.
  1. Find the organization — GET /v1/organizations to get the org_id the tour will belong to.
  2. Create the tour with its days — POST /v1/tours with name, org_id, start_date, end_date, timeZone, and a non-empty days[] array. The response returns the new tour id.
  3. Get the day IDs — GET /v1/tours?org_id=... and read tour.tourDays[].id; these are the dayId values used by schedule, venue, and guest-list routes.
  4. Add schedule items — POST /v1/schedule/items with tour_id + day_id.
  5. Add a venue — POST /v1/venues with tour_id + day_id.
  6. Add accommodation — POST /v1/accommodation with tourId + dayId (note the camelCase).

​
2. Sync a tour

Keep a local copy in step with Daysync.
  1. Read the tour list — GET /v1/tours?org_id=... and read each tour’s updated_at/is_deleted.
  2. Read each resource — for each day, GET schedule, venues, accommodation, guest list, and bulletins. Page each one with the offset from its pagination.nextOffset until pagination.hasMore is false.
  3. Diff against local state — compare IDs and updated_at timestamps; treat is_deleted: true as a removal.
  4. Apply changes — PUT changed items, POST new ones, DELETE removed ones.
Step 2 is where a mirror silently goes wrong. These list reads are capped server-side even when you send no limit, so a single call on a busy day can return fewer rows than exist. A sync that treats one response as the complete set will delete rows from your copy that are still live in Daysync.Page every list read, and decide when to stop from pagination.hasMore — never from the row count. A short page is not the end of the collection: it can just as easily be the response ceiling, which pagination.truncated tells you about and a row count does not.
There are no webhooks yet — syncing is poll-based. See pagination and rate limits before choosing a polling interval.

​
3. Guest list management

  1. Read or create pass types — GET /v1/tours/{tourId}/passTypes lists them, and POST /v1/tours/{tourId}/passTypes creates one. They no longer have to be set up in the Daysync app first. See Pass object.
  2. Add guests with passes — POST /v1/guestlist with tour_id, day_id, guest details, and a passes array.
  3. Update status — prefer PUT /v1/tours/{tourId}/guestlist/status for approvals: it is all-or-nothing across the batch, and unlike PUT /v1/guestlist/{guestListId} it does not require you to resend each guest’s whole record (a partial passes array on that endpoint wipes the rest).