Summary
The Airbyte public API is gaining timezone support on the connection schedule, and this SDK's generated models will need to pick it up so users can set a non-UTC cron schedule programmatically.
Today the public API's AirbyteApiConnectionSchedule request schema exposes only scheduleType and cronExpression. Reads return the cron expression with the timezone appended (e.g. 0 0 */3 * * ? US/Pacific), but writes could not accept that form, so a non-UTC schedule could not be created or round-tripped through this SDK — a read-modify-write of a connection with a non-UTC schedule returned HTTP 400.
What is changing in the API
Additive, backward compatible:
- New optional
cronTimeZone string on AirbyteApiConnectionSchedule. Accepts a supported timezone ID (e.g. US/Pacific) or a fixed offset (e.g. +05:30); IDs starting with Etc are rejected. Omitting it means UTC, matching current behavior.
cronExpression also accepts the timezone-suffixed form that reads already emit, so a value read back from the API can be sent straight to POST/PATCH. If both are supplied, the explicit cronTimeZone wins.- The read response shape is unchanged.
Ask
This SDK regenerates from the upstream OpenAPI spec (airbyte-api/server-api/src/main/openapi/api_sdk.yaml) on its scheduled Speakeasy runs, so no hand edits are expected here. This issue exists to track that the generated models actually expose cronTimeZone after the spec change lands upstream, and to give users a place to follow the work.
Workaround until then
Existing SDK versions can already pass the timezone inside cronExpression (e.g. "0 0 */3 * * ? US/Pacific") once the platform change is deployed, since the API accepts the suffixed form.
Related reports
Devin session
Summary
The Airbyte public API is gaining timezone support on the connection schedule, and this SDK's generated models will need to pick it up so users can set a non-UTC cron schedule programmatically.
Today the public API's
AirbyteApiConnectionSchedulerequest schema exposes onlyscheduleTypeandcronExpression. Reads return the cron expression with the timezone appended (e.g.0 0 */3 * * ? US/Pacific), but writes could not accept that form, so a non-UTC schedule could not be created or round-tripped through this SDK — a read-modify-write of a connection with a non-UTC schedule returned HTTP 400.What is changing in the API
Additive, backward compatible:
cronTimeZonestring onAirbyteApiConnectionSchedule. Accepts a supported timezone ID (e.g.US/Pacific) or a fixed offset (e.g.+05:30); IDs starting withEtcare rejected. Omitting it means UTC, matching current behavior.cronExpressionalso accepts the timezone-suffixed form that reads already emit, so a value read back from the API can be sent straight toPOST/PATCH. If both are supplied, the explicitcronTimeZonewins.Ask
This SDK regenerates from the upstream OpenAPI spec (
airbyte-api/server-api/src/main/openapi/api_sdk.yaml) on its scheduled Speakeasy runs, so no hand edits are expected here. This issue exists to track that the generated models actually exposecronTimeZoneafter the spec change lands upstream, and to give users a place to follow the work.airbyte-platformmirrorcronTimeZoneWorkaround until then
Existing SDK versions can already pass the timezone inside
cronExpression(e.g."0 0 */3 * * ? US/Pacific") once the platform change is deployed, since the API accepts the suffixed form.Related reports
Devin session