🔌 Integrations

📋 Summary

Midshift talks to very few outside systems, which keeps its operational surface small. Almost everything runs on two vendors: Supabase (database, logins and file storage) and Vercel (hosting and the two nightly scheduled jobs). The only other runtime service is Resend, used to send four kinds of e-mail (campaign invitations, password resets, notes to suppliers and feedback to the owner). There are no payment, analytics, CRM, AI or digital-asset-management integrations; links to file stores and Figma are stored as plain text by design. The main concerns are that Supabase is woven through more than a third of the source files with no abstraction layer, that e-mail sending is "best effort" with no retries, no delivery tracking and in one case a log entry claiming success that may not have happened, and that nothing monitors whether the integrations (including the nightly jobs) are actually working.

🎯 Rating

🟡 ●●●○○ 3 / 5 — Amber. A small, sensible set of integrations with credentials held correctly in environment variables and good fail-closed behaviour on scheduled jobs, but with deep single-vendor coupling, no retry or monitoring for any integration, and e-mail failures that are largely invisible.

🔍 Findings

1. Integration inventory

Not present [Observed]: payments, analytics or session replay (Clarity removed, CLAUDE.md "Interaction recording"), error tracking (app_errors table has no writer, ARCHITECTURE.md §9), LLM/AI providers (/api/ask imports only Supabase and src/lib/ask-intent.ts), DAM/file-store APIs (file_store_url is plain text by decision), Figma API (plugin cut, migration 092), inbound third-party webhooks (grep -ril webhook src outside the harness → none).

google-auth-library is declared but never imported anywhere in src, scripts or e2e. [Observed] grep -rln "google-auth\|googleapis\|GoogleAuth" matches only package.json, package-lock.json, ARCHITECTURE.md and docs/DESIGN_CHECKS.md. There is no Google API integration; the dependency is dead weight and unexplained attack surface. ARCHITECTURE.md §11 records the same.

2. Detail by integration

I1–I3. Supabase (database, auth, storage) — deep coupling

Client construction is centralised in src/lib/supabase/ (client.ts browser, server.ts RSC/route, service.ts service-role, middleware.ts proxy, env.ts normalises URLs/keys) [Observed]. Usage is not:

There is no repository or adapter layer: PostgREST query-builder chains (.from().select().eq()) appear directly in pages, route handlers, library modules and 16 client components. Migrating off Supabase, or absorbing a breaking SDK change, would touch roughly 170 files. The project also leans on Supabase-specific features (RLS policies — 95 in baseline.sql; Auth admin generateLink; Storage signed upload URLs), so the coupling is semantic as well as syntactic. [Observed] Supabase is a mainstream, well-supported choice, so this is a strategic lock-in point rather than an immediate defect. [Inferred]

Auth flows [Observed]:

• Sign-in: supabase.auth.signInWithPassword (src/app/login/login-form.tsx:27, src/components/auth/portal-login-form.tsx:51).
• Session refresh on every request: updateSession → auth.getUser() (src/lib/supabase/middleware.ts:32).
• Invites, password recovery and admin reset links are minted with auth.admin.generateLink (src/app/api/admin/invite/route.ts:33, src/app/api/auth/forgot-password/route.ts:25, src/app/api/admin/users/[id]/reset-link/route.ts:26) and delivered by Resend or shown to the admin — deliberately avoiding Supabase's rate-limited mailer.
• E-mail change still uses the built-in mailer (auth.updateUser({ email }) at src/app/(app)/workspace/settings/settings-view.tsx:56 and src/app/(app)/user-settings/user-settings-form.tsx:40), acknowledged in ARCHITECTURE.md §10. This depends on Supabase SMTP being configured per deployment (docs/NEW_DEPLOYMENT.md "What the migrations do NOT cover").
• Dev-only auto sign-in mints real sessions with the service-role key, gated on NODE_ENV === 'development' (middleware.ts:41-60; src/app/api/auth/dev-login/route.ts:15).

Storage [Observed]:

• Uploads go browser → Storage via one-time signed upload URLs from four routes (upload/[token]/url, campaigns/[id]/upload-asset, review/upload-url, files/upload-url), so file bytes do not pass through functions. Exception: POST /api/campaigns/[id]/upload-previews uploads server-side (route.ts:134-136).
• One-year signed read URLs are persisted in database columns (e.g. ad_unit_frames.image_url, reference_image_url): src/lib/upload-asset.ts:49, upload-previews/route.ts:145, render-push/route.ts:222, review/files/[fileId]/route.ts:180-184, and branding images (src/lib/branding.ts:124). A leaked URL cannot be revoked short of deleting the object, and the URLs expire after a year, at which point stored images break unless re-signed. [Observed]/[Inferred]
• Final-grid and concept pages sign each file individually (3 calls per final file, src/lib/final-load.ts:54-57) rather than using the batch API (see Module 3, P4).
• The nightly purge removes objects before rows and refuses to delete rows if any removal fails (src/app/api/cron/purge-review/route.ts:128-143) — good resilience design.

Resilience: if Supabase is down, the entire application is down (pages, APIs, sign-in and files). There are no retries, timeouts (AbortSignal), circuit breakers or cached fallbacks anywhere in src [Observed] grep -rniE "retry|backoff|AbortSignal.timeout" → only comments about idempotent re-submission. This is normal for this class of app; it means availability equals the lower of Vercel's and Supabase's.

Credentials: NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY (public by design), SUPABASE_SERVICE_ROLE_KEY (server only; src/lib/supabase/env.ts reads it only in server modules). Managed in Vercel env vars, optionally pushed from a local .env.ops by scripts/ops.sh env-sync. No rotation procedure is documented. [Observed] .env.example, .env.ops.example; gitleaks clean (BRIEF).

I5. Resend — transactional e-mail

Findings:

• No abstraction. new Resend(process.env.RESEND_API_KEY) and the from-address fallback are repeated in four places, with two hand-built HTML templates inline in route handlers. [Observed] Swapping provider, adding retries or adding logging means editing four files.
• The supplier e-mail can log success that did not happen. The Resend SDK returns API failures as { error } rather than throwing [Inferred from the SDK's documented contract; the invite route relies on exactly that at invite/route.ts:86,113]. emailSupplierNotes ignores the returned value (review-notify.ts:92) and then records supplier_notes_emailed, whose comment states "the row means it went" (review-notify.ts:104-107). A rejected send (bad domain, quota, invalid address) therefore leaves an audit entry saying notes were sent to an outside party. [Observed]/[Inferred]
• Unsafe fallback sender. If RESEND_FROM_DOMAIN is unset, all four sites send from onboarding@resend.dev (Resend's sandbox sender, which only delivers to the account owner) — mail silently fails to reach anyone else. [Observed] fallback string; [Inferred] sandbox behaviour.
• Unescaped values in the invite HTML. campaignName and inviterName are interpolated into the HTML body without escapeHtml (invite/route.ts:113, 131), although the organisation name is escaped (:85). A campaign or user name containing markup would be rendered in the recipient's mail client. Impact is limited (only editors/admins set those names) but it contradicts the stated rule in CLAUDE.md Branding. [Observed]
• Host-derived links. When NEXT_PUBLIC_APP_URL is unset, invite and reset links fall back to the request Origin header / request URL (invite/route.ts:67, forgot-password/route.ts:22, admin/invite/route.ts:31); NEXT_PUBLIC_APP_URL is mandatory per CLAUDE.md, so this is a misconfiguration risk rather than a default-on flaw. [Observed]
• No bounce/complaint webhook, no delivery status, no retry, no queue. If Resend is down, invites report emailSent: false (the inviter can copy the returned link), resets and supplier notes are silently lost. [Observed]
• Sender-domain DNS (SPF/DKIM) is a dashboard task listed in docs/NEW_DEPLOYMENT.md and not verifiable from the repository. [Unavailable] — requires access to the Resend account and DNS.

I6. Vercel Cron — scheduled jobs

Fail-closed is the right default, but it has a silent failure mode: a deployment without CRON_SECRET simply never purges files and never raises overdue alerts, and nothing tells anyone. CLAUDE.md acknowledges this; there is no health check or alert. [Observed] .env.example describes CRON_SECRET as gating only purge-review — it gates both. [Observed] docs drift. ARCHITECTURE.md §2 likewise lists one cron. Vercel cron execution history is visible only in the Vercel dashboard. [Unavailable] — requires Vercel access to confirm the jobs run.

The bearer comparison uses !== (not constant-time); with a long random secret this is a negligible risk. [Observed] route.ts:30.

I8. Build-time font fetch

src/app/layout.tsx:17 imports Inter and JetBrains_Mono from next/font/google; Next.js downloads and self-hosts them at build, so no runtime request leaves for Google [Observed] code comment layout.tsx:21. The build therefore depends on Google Fonts availability and outbound network; offline/air-gapped builds will fail or fall back. [Inferred]

I9. External parties via bearer-token links

Suppliers and client/DAM teams have no accounts; they reach the system through URL tokens (src/app/upload/[token], src/app/preview/[token], routes under src/app/api/upload/[token]/* and src/app/api/preview/[token]/custody). Upload tokens are checked for expiry (src/app/api/upload/[token]/url/route.ts:14-17); preview access is counted via log_share_link_access (src/app/preview/[token]/page.tsx:51); tokens are redacted when logged (src/lib/activity.ts redactPath) and Referrer-Policy: strict-origin-when-cross-origin is set (next.config.ts). [Observed] These are the system's only inbound integrations with third parties and are reasonably designed; token strength and rate-limiting are covered in the security module.

3. Flags

🧾 Evidence

Commands run (from /home/user/midshift-audit):

• grep -rn "google-auth-library\|GoogleAuth\|from 'resend'\|new Resend\|fetch(\?https?:" src scripts` → Resend in 4 files; no Google imports.
• grep -rln "google-auth\|googleapis\|GoogleAuth" --exclude-dir=node_modules . → package.json, package-lock.json, ARCHITECTURE.md, docs/DESIGN_CHECKS.md only.
• grep -rn "fetch(" src | grep -v "fetch('/\|fetch(\/|src/app/qa"→ only same-origin calls andsrc/lib/handover-zip.ts:40` (fetching Supabase signed URLs in the browser).
• grep -rn "https\?://…" src -o → no external API hosts in application code.
• Supabase coupling counts: see table in §2 (I1–I3).
• grep -rn "inviteUserByEmail\|generateLink\|updateUser({ *email\|resetPasswordForEmail\|signInWith" src → sites cited above.
• grep -rn "createSignedUploadUrl" src → 4 routes; grep -rn "60 \* 60 \* 24 \* 365" src → 1-year signing sites cited above.
• grep -rniE "retry|backoff" src, grep -rn "AbortSignal.timeout\|signal:" src → no retry/timeout logic.
• grep -rn "process.env\.[A-Z_]*" src -oh → env vars in use: Supabase ×3, RESEND_API_KEY, RESEND_FROM_DOMAIN, NEXT_PUBLIC_APP_URL, OWNER_EMAIL, GHOST_EMAIL, CRON_SECRET, DEV_USER_EMAIL, DEV_USER_PASSWORD, NEXT_PUBLIC_UNIT_COMMENTS, NEXT_PUBLIC_PRODUCT_NAME, NEXT_PUBLIC_QA, NEXT_PUBLIC_QA_TODAY, NODE_ENV.
• .env.example and .env.ops.example read with values masked.
• Files read: vercel.json, src/lib/supabase/*.ts, src/app/api/cron/purge-review/route.ts, src/app/api/cron/overdue/route.ts, src/app/api/auth/forgot-password/route.ts, src/app/api/feedback/route.ts, src/app/api/campaigns/[id]/invite/route.ts, src/lib/review-notify.ts, src/lib/notify.ts, src/lib/activity.ts, src/lib/track.ts, src/lib/handover-zip.ts, src/lib/branding.ts:60-68, src/app/api/auth/dev-login/route.ts, src/app/api/admin/invite/route.ts, src/app/api/upload/[token]/url/route.ts, src/app/api/ask/route.ts (imports), next.config.ts, ARCHITECTURE.md §§2, 9–11, docs/NEW_DEPLOYMENT.md §2.

⚠️ Risks

✅ Recommendations