table-schedules

Change a table's refresh cadence

Editing the cadence re-anchors it: 'every 3 days' set today means three days from today. Resuming a paused schedule on its own does NOT: it keeps firing at the same time of day (or the same interval) the schedule was already on, just moved to the next upcoming occurrence, so a schedule left paused for a month neither fires the moment it comes back nor drifts to a new time.

patch/tables/{table_id}/schedule/

Request

  • Base URL: https://api.getoneprofile.ai (the document declares no server; this is the origin it was published from)
  • URL: https://api.getoneprofile.ai/tables/{table_id}/schedule/
  • Auth: one of:
    • API key in header X-API-Key
    • HTTP bearer

Path parameters

table_idstring uuid required

Request body

delete_missing_rowsboolean nullable
frequency'hourly' | 'daily' | 'weekly' | 'monthly' | 'quarterly' | 'custom'

How often a table re-imports, in the vocabulary the settings panel offers.

The presets are stored as cron because "the 8th of every month at 09:00" is a calendar statement that an interval cannot make: an interval of 30 days drifts off the date within a year. CUSTOM is the escape hatch for "every N days/weeks/months", which is an interval and drifts on purpose, anchored to when the user set it up.

HOURLY is cron too, and it is the one preset that ignores the hour the user picked: "every hour at 09:00" is not a thing anyone means. The minute is kept, so an hourly refresh set at 09:20 runs at twenty past every hour, and a source that rate-limits is not hit by every table on the hour.

hourinteger nullable
interval_unit'hours' | 'days' | 'weeks' | 'months'

The unit a CUSTOM cadence counts in.

HOURS is the only one with no time of day to honour: "every 6 hours at 09:00" is two statements that cannot both be true. It anchors to the next occurrence of the chosen MINUTE instead, the same way the HOURLY preset keeps the minute and drops the hour.

interval_valueinteger nullable
minuteinteger nullable
pausedboolean nullable
time_zonestring nullable

Response

Successful Response

created_atstring date-time required
delete_missing_rowsboolean required

Whether a scheduled run deletes rows whose records are gone from the source. Forces every scheduled run to re-list everything, since a changes-only fetch cannot tell a deleted record from an unchanged one.

frequency'hourly' | 'daily' | 'weekly' | 'monthly' | 'quarterly' | 'custom' required

How often a table re-imports, in the vocabulary the settings panel offers.

The presets are stored as cron because "the 8th of every month at 09:00" is a calendar statement that an interval cannot make: an interval of 30 days drifts off the date within a year. CUSTOM is the escape hatch for "every N days/weeks/months", which is an interval and drifts on purpose, anchored to when the user set it up.

HOURLY is cron too, and it is the one preset that ignores the hour the user picked: "every hour at 09:00" is not a thing anyone means. The minute is kept, so an hourly refresh set at 09:20 runs at twenty past every hour, and a source that rate-limits is not hit by every table on the hour.

hourinteger required

Local hour the cadence runs at.

idstring uuid required
interval_unit'hours' | 'days' | 'weeks' | 'months' required

The unit a CUSTOM cadence counts in.

HOURS is the only one with no time of day to honour: "every 6 hours at 09:00" is two statements that cannot both be true. It anchors to the next occurrence of the chosen MINUTE instead, the same way the HOURLY preset keeps the minute and drops the hour.

interval_valueinteger nullable required

How many units apart, for a custom cadence.

last_skip_reason'source_detached' | 'run_in_progress' required

Why a firing skipped starting an import instead of recording a run.

Both cases advance next_run_at the same as a real run does, so without this the schedule just quietly keeps ticking, and a user watching for their nightly refresh has nothing to look at but silence.

last_skipped_atstring date-time nullable required

When a firing last skipped without starting a run; null if it never has.

minuteinteger required

Local minute the cadence runs at.

next_run_atstring date-time required
next_runsstring[] required

The next few fire times, so a cadence can be checked before it is trusted.

pausedboolean required
table_idstring uuid required
time_zonestring required

IANA zone the run time is expressed in.

updated_atstring date-time required

Changes

No recorded changes to this operation across all 1 revision of this API.