Skip to main content
The Daysync Integration API lets approved partner applications read and write tour data on behalf of a Daysync user — tours, schedules, venues, accommodation, guest lists, bulletins, and organization membership. It is a REST/JSON API. Every call runs against Daysync’s production business logic, so the same permissions, validation, and entity rules that apply inside the Daysync app apply to the API.

​
Base URL

All endpoints are versioned under the /v1 path prefix, e.g.

​
Two hostnames

/ The API uses two hostnames, each with a distinct purpose:
These two hostnames differ by a single letter: the portal is integrations (plural), the API is integration (singular). Send OAuth requests to the plural host and data requests to the singular one.
You authenticate against integrations.daysync.com, then call integration.daysync.com with the resulting token. See Authentication.

​
Data model at a glance

Everything hangs off an organization. A tour belongs to one organization; days belong to one tour; day-scoped resources (schedule items, guest list entries) belong to one day. Practical consequences:
  • Every integration starts with GET /v1/organizations to obtain an org_id, then GET /v1/tours?org_id=… for tours and their tourDays (the day IDs).
  • Schedule and guest list routes are day-scoped (/tours/{tourId}/days/{dayId}/…); venues, accommodation, and bulletins are tour-scoped (/tours/{tourId}/…).
  • Deleting a tour (or a day via day_list) takes its children with it.

​
How a request is processed

Every request passes through the same pipeline:
  1. Partner authentication — your x-api-key / x-api-secret pair identifies and authenticates your application.
  2. User authentication — the Authorization: Bearer <token> identifies the Daysync user the call acts on behalf of.
  3. Scope check — the endpoint’s required scope must be among the scopes granted to your partner application.
  4. Business rules — subscription status, soft-delete state, and input validation are enforced before the request reaches Daysync’s services.
  5. Execution — the request runs as the authenticated user, honouring that user’s roles and access.
See Authentication and Scopes & Permissions.

​
Conventions

​
Content type

Requests with a body must send Content-Type: application/json and a valid JSON body. Malformed JSON returns 400 INVALID_JSON. Request bodies are limited to 512 KB (413 PAYLOAD_TOO_LARGE if exceeded).

​
Success envelope

Every successful (2xx) response uses the same envelope:
  • status — always true on success.
  • message — a human-readable result message.
  • data — the resource payload. Shape depends on the endpoint (object, array, or null).

​
Error envelope

Errors return a machine-readable error code plus a message and numeric status:
See Errors for the full list of codes.

​
Identifiers

Tours and organizations are referenced by UUID strings; most child resources use integer IDs. Passing the wrong type generally results in a 400 or 404.

​
Field naming

ID field names are not consistent across resources. Most resources use snake_case (tour_id, day_id, org_id), but Accommodation and Bulletins use camelCase (tourId, dayId):
Always check the endpoint reference for the exact field name. Using the wrong case (tourId where tour_id is expected, or vice-versa) results in a validation error or the field being silently ignored.

​
Pagination

List endpoints accept limit and offset query parameters, and they are capped server-side whether or not you send them.
A list response is not necessarily the whole list. Every day-scoped list read is bounded at 1,000 rows, and a response that would still be too large to serialize is shortened again to fit the response ceiling — so a dense day can come back with fewer rows than that. Omitting limit means “as much as fits”, not “everything”.You do not have to guess whether that happened: every capped list read reports it in a pagination object, described below. Page with its nextOffset until hasMore is false — a short page is not a reliable end-of-list signal, because a page can be short from the response ceiling alone.
This applies to the day- and tour-scoped list reads:

​
The pagination object

Each of those six reads answers with a pagination object alongside data — a sibling of it, not a field inside it — so you can tell a complete page from a shortened one without inferring anything from the row count:
Page with nextOffset, never with returnedCount. nextOffset counts the rows the server consumed, which can be more than offset + returnedCount when rows were dropped from the page after being counted. Advancing by returnedCount would re-read those rows on every iteration and the loop would never finish.A page the server consumed no rows from always reports hasMore: false and nextOffset: null, so while (hasMore) terminates.The converse is legitimate and worth expecting: returnedCount: 0 together with hasMore: true means every row on that page was filtered out after being counted. It is not the end of the list and it is not an error — keep paging from nextOffset.
The object is additive, and it only appears where it can be trusted: an unpaged read does not grow the key, and a response that cannot report both counts omits it entirely rather than returning a half-filled envelope that would read as a complete page. Over MCP, the six equivalent tools (get_schedule, list_venues, list_accommodation, get_guest_list, list_bulletins, list_pass_types) append a one-line [pagination] note to the result whenever a page is incomplete, naming the offset to call back with. A complete, untruncated page carries no note. GET /v1/tours/{tourId}/files reports totalCount, returnedCount and hasMore on the same principle. Chat reads take a limit and a message-id cursor. GET /v1/reference/types is uncapped and returns every lookup table. The whole-tour read takes its own per-resource limits (scheduleLimit, staysLimit, guestLimit, bulletinLimit) and reports truncated per day, so a day whose collections were shortened is distinguishable from a day that is genuinely short. Also worth planning for:
  • Cache responses where possible; reference data changes very rarely.
  • Avoid polling list endpoints on short intervals.

​
Dates & times

Date-time fields (tour start_date/end_date, tour day date, schedule start_time/end_time) use ISO 8601 / AWSDateTime format, e.g. 2026-06-01T00:00:00Z. Time zones are IANA names, e.g. Australia/Sydney. Accommodation check-in/check-out fields use numeric date/time values — see the Accommodation page.

​
Rate limits

Rate limiting is not currently enforced, but limits may be introduced in a future version. Design your integration to handle 429 Too Many Requests responses gracefully — implement exponential backoff and avoid tight polling loops.

​
Retries & idempotency

Send an X-Idempotency-Key header on a write and the API will run it at most once — a retry carrying the same key returns the original result instead of creating a second record. Without a key, retry safety still depends on the method:
Network timeouts on POST are the dangerous case. If your request times out, you cannot tell whether the record was created.Generate the key before the first attempt and reuse it for every retry of that same logical action — a key minted per attempt protects nothing. If you cannot send one, re-read the relevant list endpoint and check whether the record already exists (match on your own fields, e.g. name + day) before retrying.
Which responses are worth retrying:

​
Versioning

All endpoints are prefixed with /v1. When breaking changes are introduced, they will be released under a new prefix (/v2), and the previous version will continue to be served for a transition period so existing integrations keep working.

​
Webhooks & real-time updates

The API does not currently support webhooks or event subscriptions. To detect changes, poll the relevant list endpoints. Webhook support is planned for a future release.

​
OpenAPI specification

A machine-readable OpenAPI specification is not yet published. The API follows standard REST conventions and can be used with any HTTP client. Once a spec is available it will be linked here for use with Postman, Swagger UI, and client-code generators.

​
Next steps