SyncApp Creation Under the Hood — Support, Settings & OAuth
Why This Matters
This high-level walkthrough ties together three services — SyncApp Support, SyncApp Settings, and SyncApp OAuth — showing how a new integration connects them all. It's the architectural overview before the deep dives that follow.
What You'll Learn
- The sync-app-support repo and how it drives the 'Create Cloud Sync App' dropdown in WAM
- How each PMS defines its own required credential fields (Cloud9 = Client ID, Avamark = Installation ID, Curve = Office URL)
- How submitted credentials become WAM location settings that the SyncApp reads at startup
- The sync-app-oauth repo and its role: handle the initial OAuth authentication flow for OAuth-based PMS integrations
- How the SyncApp Go OAuth2 library handles automatic token refresh (no manual work needed)
- Development strategy: hardcode a token initially, implement OAuth at the end of a project
Watch Video
Lesson Summary
When an office clicks 'Create Cloud Sync App' in WAM, the integration dropdown is entirely driven by the sync-app-support repo — new PMSs are added by implementing a provisioner there, with no frontend changes needed. Each provisioner defines which credential fields are required. After submission, those credentials are stored as WAM location settings that the SyncApp reads at startup. For OAuth-based PMSs, the sync-app-oauth repo handles the initial auth flow (showing an authorization page, handling the callback, storing the token). After initial auth, the Go OAuth2 library automatically refreshes tokens — developers don't need to write refresh logic.