Code Flow Part 5 — HTTP Client, APIs, Push Types & Full/Partial Sync
Why This Matters
This final part ties together everything: how to create the HTTP client that talks to the PMS, how pagination works over API calls, how transformation feeds data to Data Service, and what push types are — a special mechanism for entities that can't be queried by time.
What You'll Learn
- How to create a new integration: create folder → create HTTP client → create API methods → create entity transformers
- How paginated API calls work: SyncApp loops over pages until all data is fetched
- The transformation chain: raw PMS data → entity transformer → Data Service format
- Push types: some entities (appointment types, recall types) can't be filtered by last-modified time — they use a push model instead
- How full sync uses a 'never synced before' timestamp and partial sync uses the last-sync timestamp
- What to implement for a new integration vs what the framework provides automatically
Watch Video
Lesson Summary
Creating a new integration requires: (1) new folder in the integrations directory, (2) HTTP client that authenticates with the PMS, (3) API methods per entity that handle pagination, (4) entity transformers that convert PMS data to Weave schema. The framework handles the sync loop — you implement fetch + transform. For most entities, partial sync uses last-modified time filtering. But some entities (appointment types, recall types) change infrequently and can't be queried by time — these use push types: they're fetched in full on every cycle and pushed to Data Service unconditionally. After full sync on first run, all subsequent syncs are partial for time-filterable entities.