Prebit Developer Docs

Background & Scheduled Jobs

Manifest declarations exist; the dispatcher that calls you doesn't yet.

Declared in the schema, not yet dispatched

Your manifest can declare background_jobs and scheduled_jobs today, and they validate correctly — but nothing on Prebit's side actually calls your endpoint on a schedule or in response to a "sync now" click yet. This page describes the manifest shape so you can declare it now and not need a manifest migration once the dispatcher ships; don't build against it as a live integration point today.

Manifest shape

background_jobs = [{ id = "sync-reviews", capability = "can_register_background_job" }]
scheduled_jobs  = [{ id = "nightly-import", cron = "0 2 * * *" }]
  • Background job — app-triggered (e.g. a "sync now" button in a future app_admin UI). Requires the can_register_background_job capability.
  • Scheduled job — cron-triggered. Requires the can_schedule_job capability. cron is validated as a 5-field cron expression shape only (not validated against a real schedule parser).

What "dispatch" will mean once it ships

Per the platform's design: Prebit calls out to your declared HTTPS endpoint on the schedule/trigger — it never runs your code. Same shape as Webhooks delivery (HMAC-signed, retried with backoff), just triggered by a clock or a button instead of a domain event.

What to do today

If you need scheduled or on-demand sync behavior right now, run it on your own infrastructure (your own cron, your own "sync now" button in your own admin UI) calling the Partner API directly — exactly like prebit-examples/product-sync and inventory-sync do. Declaring background_jobs/ scheduled_jobs in your manifest now costs nothing and means no manifest migration later, but isn't required for a working integration today.

On this page