Sync one section between business level and stores
Same request body and the same two gotchas as
syncMenuToStores — this is the
targeted, single-section variant:
-
Overlap check. A non-empty
sections[<id>].availableTimestriggers an overlap check against schedules already attached to the store. Collisions return400 request_invalid. -
Persisted fields. By default the sync keeps the store’s existing override for
availableTimes,isEnabled,visibilities,blackoutDates— even after you’ve PATCHed the section’s business-level schedule. If the call comes back200but the store-level value hasn’t moved, this is almost always why. Add the field name tofieldIncludeOnSyncto force-overwrite it, e.g.{ "fieldIncludeOnSync": ["availableTimes"] }. SeeSyncMenuRequestfor the full shape. -
Synchronous, unlike
syncMenuToStores: the write happens inline and200means it’s already applied — no job to poll, no separate sync trace.
Authorizations
Authorization: Basic base64(partner_key:secret_key).
Credentials are issued by a klikit operator. The plaintext
secret_key is shown once at issuance and cannot be retrieved
later — store it securely. If lost, ask your operator to rotate
the secret to receive a new one. The old secret stops working
immediately on rotation; there is no overlap window.
Body
Push the named sections to each (brand, branch) store.
Two read-this-first behaviours:
-
Overlap check. A non-empty
sections[<id>].availableTimestriggers an overlap check against schedules already attached to the store; a collision returns400 request_invalid. The simplest opt-out is to sendavailableTimes: {}— the menu service then falls back to the section's business-level schedule. -
Persisted fields. Sync deliberately keeps the store's existing overrides for a few fields (defaults listed under
PersistFieldOnSync) — so a stock store-only schedule edit isn't blown away when you ship an unrelated business-level change. To overwrite one of those fields from the business-level value, include its name infieldIncludeOnSync. Example:subtracts
availableTimesfrom the persist list so the store-section schedule is overwritten with the section's current business-levelavailableTimes.
After sync, the partner-facing getMenu response reads from a
cached blob — call publishMenu
afterwards to rebuild it (and to ship the change to provider
marketplaces).
Section-id keyed object. Each value carries display order + per-store schedule overrides.
Field names to exclude from the persist list — i.e. force-overwrite
the store's existing override with the business-level value. Common
picks: availableTimes, isEnabled, visibilities, blackoutDates
for sections.
Explicit per-level persist allowlist. If you set this, the menu
service replaces the default list wholesale — usually you want to
leave this unset and use fieldIncludeOnSync instead.
Response
Success — payload wrapped in the canonical Envelope.
Canonical response wrapper. Every response — success or error —
carries the request_id so you can quote one id to klikit
support to correlate a request end-to-end.
"req_4d1b7e3f-..."
Endpoint-specific payload on success.
Machine-readable error code + human message. The code is stable
across releases — switch on code in your client code rather
than parsing the message text.
Common codes you will encounter as a partner: