API Conventions
Reference for recurring data formats used across every Slatis endpoint: IANA timezones, ISO 8601 timestamps, and pagination.
Timezones
The Slatis API accepts and returns timezone values using the IANA Time Zone Database format — a globally maintained registry of timezone identifiers maintained by the Internet Assigned Numbers Authority.
Format
IANA timezone strings follow a Region/City pattern:
| String | Location |
|---|---|
America/New_York | US Eastern Time (auto-adjusts for DST) |
America/Los_Angeles | US Pacific Time |
America/Chicago | US Central Time |
Europe/Madrid | Spain |
Europe/London | United Kingdom |
Asia/Tokyo | Japan |
Asia/Kolkata | India (IST, no DST) |
Australia/Sydney | Australia Eastern |
Pacific/Auckland | New Zealand |
UTC | Coordinated Universal Time |
IANA identifiers account for Daylight Saving Time automatically. Prefer them over fixed offsets like UTC+2 — fixed offsets do not shift when DST changes.
How to find a timezone string
In the browser:
In Node.js:
In Python:
Full list: The complete database is at data.iana.org/time-zones — most frameworks also ship it as a local package (@vvo/tzdb, tzdata, etc.).
Timezones in the API
- Availability and free/busy — pass a
timezoneto filter slots to a member's working hours. Returned slot times are always UTC regardless. - Bookings — the attendee's
timezonefield is stored for display and confirmation email formatting. It does not affect the stored UTC time. - Event types — an optional
timezoneoverride forces slot generation to use a specific locale rather than each member's calendar timezone.
Date and time format
All date-time values in the Slatis API use ISO 8601 format with UTC offset:
Producing ISO 8601 strings
JavaScript / TypeScript:
Python:
Go:
Always send times in UTC (Z suffix). Sending a local time without an offset (e.g. 2026-05-01T14:00:00) may be interpreted incorrectly.
Date-only parameters
Some parameters accept a date without a time component, using YYYY-MM-DD format:
These appear on endpoints where only the calendar date matters, such as GET /v1/team/members/available?date=2026-05-01.
Pagination
The Slatis API uses two pagination styles depending on the endpoint.
Cursor-based pagination
Used by GET /v1/bookings. Each page returns a next_cursor — pass it as the cursor query parameter on the next request.
| Prop | Type | Default |
|---|---|---|
next_cursor | string | null | - |
has_more | boolean | - |
Iterate all pages using the SDK:
Offset-based pagination
Used by team members, webhooks, and delivery history endpoints. Each page returns total, limit, offset, and has_more.
| Prop | Type | Default |
|---|---|---|
total | integer | - |
limit | integer | - |
offset | integer | - |
has_more | boolean | - |
Iterate all pages using offset:
The SDK's team.getMembers() and team.getAvailableMembers() return the full { members, pagination } envelope directly, so you can use pagination.has_more without unwrapping.