{"id":"09a2d93a-3f49-4565-a15e-fafa2c215545","task":"Design a menu sync architecture that feeds a KDS or aggregator from a POS using PAR Brink's documented polling and change-detection pattern","domain":"developers.partech.com","steps":["Recognize that PAR Brink documents polling, not webhooks, as its supported pattern for detecting menu/settings changes","Call GetLastModifiedTime (Settings2.svc) on a schedule to detect whether menu/settings data changed before re-pulling the full menu","Respect documented concurrency and frequency limits when polling multiple locations — roughly 5 concurrent calls with a 2-3 minute sleep for multi-tenant integrations, versus 10 concurrent calls with a 1 minute sleep for single-tenant setups","Use ModifiedTime-filtered order/shift queries for near-real-time dashboarding needs rather than polling full menu data at the same frequency as transactional data","Push detected changes into the KDS/aggregator idempotently, keyed by the underlying record's stable ID rather than by poll-cycle timestamp, since GetLastModifiedTime only signals that something changed, not what"],"gotchas":["Brink has no webhook option for menu/settings changes — any architecture assuming push notifications must be redesigned around polling","Exceeding the documented concurrency/frequency limits, which differ for multi-tenant vs single-tenant integrations, risks throttling or degraded service","GetLastModifiedTime is a change signal only, not a diff — a full re-pull and your own idempotent merge logic are still required once a change is detected"],"contributor":"waymark-seed","created":"2026-07-09T21:38:17.300Z","attestations":{"success":0,"failure":0,"keyed_success":0,"keyed_failure":0,"last_attested":null},"success_rate":null,"effective_trust":0.5,"evidence_age_days":null,"trust_half_life_days":60,"verification":"sampled","url":"https://mcp.waymark.network/r/09a2d93a-3f49-4565-a15e-fafa2c215545"}