Enterprise Software
POS Webhooks: CRM Sale Notifications & Scheduling Collect-Payment
How POS notifies CRM on sale completed and accepts scheduling collect-payment events — without shared databases across suite products.
POS Webhooks: CRM Sale Notifications & Scheduling Collect-Payment
The register should not be an island. Outbound to CRM on sale completed. Inbound from scheduling on collect-payment. Same customer story, separate databases.
POS and CRM link through webhooks and Suite Platform service links — not joined schemas.
Guide: POS buyer's guide
Outbound: sale completed → CRM
When a cashier completes a sale:
- POS persists sale, tenders, and invoice in
pos_*tables - If configured, POS fires sale-completed webhook to CRM
- CRM creates or updates contact activity and revenue attribution
No shared session. CRM validates webhook signature and writes to crm_* tables.
Inbound: scheduling collect-payment → POS
When a client pays a deposit at booking or check-in:
- Scheduling product fires collect-payment webhook
- POS accepts payload and records payment against appointment context
- Front desk does not re-key card or amount at register
Honest scope: POS does not replace Receptionist billing or Stripe Connect — each product owns its payment rails where applicable.
Why webhooks instead of shared DB
| Approach | Problem |
|---|---|
| Shared tables | Couples deploy cadence; one migration breaks siblings |
| Nightly sync | Customer timeline is always stale |
| Manual re-key | Errors, delays, angry managers |
| Webhooks + contracts | Independent products, near-real-time events |
Configuration checklist
- CRM service link registered on Platform
- Sale-completed webhook URL and secret in POS
- Scheduling collect-payment endpoint exposed on POS
- Tenant IDs mapped across products
- Test sale in staging before go-live
Anti-patterns
- Expecting POS to host voice AI billing
- Assuming inventory reservation without Inventory SKU entitled
- Skipping idempotency on webhook handlers (retries will duplicate)