Integration Service
Retired under the Canvas-first architecture.
Why it's retired
canvas-pioneer-integration-service was a coordinating monolith that accumulated
responsibilities during the Bask → Canvas migration era: Canvas OAuth, FHIR HTTP helpers,
patient records storage, Canvas webhook handlers, Stripe customer tracking, HubSpot sync,
admin API endpoints, RxQueue proxying, and welcome email sending. Under Canvas-first, each
of those belongs to a single-purpose service. Distributing them removes a large single
point of failure and aligns with the Canvas-first doctrine.
See canvas-first-principles §6.2 for the full retirement map.
Where each responsibility went
| Old responsibility | New home |
|---|---|
| Canvas OAuth + FHIR HTTP helpers | @yourera/canvas-client (shared TypeScript library imported by every service that touches Canvas) |
| Canvas webhook endpoints + signature verification | webhook-receiver (new service — single public endpoint that fans out to internal event bus) |
patientRecords table |
Canvas Patient resource (authoritative) + patient-service.patient_directory (identifier map only) |
intakeData JSONB |
patient-service.intake_snapshots (INSERT-only compliance record) |
refillSchedules table + refill cron |
refill-scheduler-service (event-driven materialized view + cadence worker) |
telehealthAppointments |
Canvas Appointment resource |
syncLogs |
Each service's own audit_events table |
| Stripe customer tracking (create customers, charge, refund) | payment-service (new service; Stripe bridge with idempotency everywhere) |
| Welcome email + portal invite flow | notification-service (expanded: delivery + contacts + campaigns + preferences; replaces HubSpot) |
| Canvas → pharmacy translation | pharmacy-router (sole owner of pharmacy HTTP integration; GMP + Strive) |
| Admin API endpoints (RxQueue proxy, patient lookup) | admin-portal calls each service directly with scoped admin tokens |
| HubSpot sync | HubSpot retired from the architecture entirely. Contacts and campaigns live in notification-service. |
Patient portal routes (hosted under hisera) |
patient-portal (white-label Next.js app; hostname → org resolution, Clerk auth, direct canvas-client reads) |
If you were going to look something up here
Find the current doc by responsibility:
- Canvas integration pattern — Architecture Overview + Canvas Plugins
- Patient records / identifiers — the Patient Service section in Architecture Overview
- Canvas webhooks — Webhook Receiver section in Architecture Overview
- Stripe / payments — Payment Service section in Architecture Overview
- Notifications, email, SMS, campaigns — Notification Service
- Refills — Refill Scheduler section in Architecture Overview
- Admin endpoints — Admin Portal
Deletion status
Until the refactor sequence reaches Phase 14, the service is still running in production to handle long-tail requests and any flows not yet migrated. Don't add features. Don't migrate data into its schema. Don't wire new consumers of its endpoints. Flag any ongoing dependency so we can redistribute it explicitly before deletion.
See Refactor Sequence for the ordered cut-over plan.