CADI Integration Planning

CADI (Cadime) Mock-Interview Integration - v1 Plan

Context

Enrich is partnering with CADI (cadime.ai / app.cadime.ai), a third-party AI training platform that builds interview avatars from job descriptions so students can run repeated mock interviews and get feedback. Per the client (Alfonso), the required student flow is: a student is matched to a job → needs to prepare for the interview → gets a login to CADI and clicks one button to go directly to the CADI site to run reps. Each student follows the same flow. Pulling mock-interview results back into Enrich is a “nice-to-have”, explicitly out of scope for v1.

v1 goal (confirmed): provision a CADI account for a student on demand and give them a one-click launch into CADI — from both a matched job and a general practice entry point. No results sync, no webhooks, no coach-facing UI in v1.

Decisions locked in with the user:

Scope: account provisioning + one-click launch only. Results/coach view = future v2.
Launch UX: use CADI’s one-time invitationLink for first entry; returning students log in normally at app.cadime.ai. No SSO dependency.
Provisioning timing: lazy — create the CADI account the first time a student clicks “Practice interview” (avoids consuming paid CADI seats for students who never practice).
Launch points: both per-matched-job (scoped to that job’s CADI curriculum) and a general practice hub.

Architecture decision

enrich-cms (Strapi 4 + Postgres) is the single backend and owns all identity/domain data. The student portal is a client-only React SPA whose env vars are baked into the browser bundle — so the CADI API key must never live in the portal. All CADI calls run server-side in enrich-cms; the portal calls a new authenticated CMS endpoint that returns a launch URL.

Student Portal (React SPA)                enrich-cms (Strapi)                 CADI API
  "Practice interview" button  ──POST──▶  /api/cadime/launch  ──X-Api-Key──▶  POST /api/invitations
        openInNewTab(url)  ◀── { url } ── (lazy provision + store link)  ◀──  { invitationLink, expiresAt }

CADI API surface used in v1

Base URL https://api.cadime.ai/api, auth header X-Api-Key: <key> (secret, server-side only).

Provision: POST /api/invitations body: { userType: "education", name, email, role, sendEmail?, curriculumId?, curriculumDeadline?, curriculumReps?, curriculumLevel? } → { invitationLink: "https://app.cadime.ai/invite/…", name, email, role, expiresAt, message } (Note: response does not include a CADI user id.)
(v2 only, not built now) GET /api/users, GET /api/users/{userId}/performance, GET /api/users/{userId}/trainings.
CADI has no webhooks (confirmed — the docs webhook path 404s), which is fine since v1 pulls nothing back.

Backend changes — `enrich-cms` (the bulk of the work)

1. Config — `config/cadime.js` (new)

Follow the config/merge.js / config/thrive.js pattern:

module.exports = ({ env }) => ({
    hostname: 'https://api.cadime.ai/api',
    apiKey: env('CADIME_API_KEY', ''),
    userType: 'education',
    defaultRole: env('CADIME_DEFAULT_ROLE', 'student'),   // confirm valid role w/ CADI
    defaultCurriculumId: env('CADIME_DEFAULT_CURRICULUM_ID', ''), // for general hub
    featureActive: env('CADIME_FEATURE_ACTIVE', false),
});

Add CADIME_API_KEY (and the two optional vars) to the deployment env. Key already exists per user.

2. Data model

contact schema (src/api/contact/content-types/contact/schema.json) — add provisioning-state fields, mirroring the existing klaviyoId / thriveId external-id convention:
- cadimeInvitedAt (datetime), cadimeInvitationLink (string), cadimeInvitationExpiresAt (datetime)
- cadimeUserId (string, unique, nullable) — left null in v1; reserved for v2 results sync.
job schema (src/api/job/content-types/job/schema.json) — add cadimeCurriculumId (string, optional). Admins paste the CADI curriculum id per job (Alfonso loads JDs into CADI manually). Editable via the Strapi admin panel in v1 (the field appears automatically); a coaching-platform UI field is optional/v2.

3. Service + controller + route — new `src/api/cadime/`

Reuse the “axios + strapi.config.get('cadime.*') host + X-Api-Key from config” pattern from src/plugins/thrive-trm/server/services/*.

service cadime.js
- getLaunchUrl({ contact, job }) — orchestration with guard clauses (CLAUDE.md style, no nested ifs):
  - if !config.featureActive → throw/return disabled.
  - if contact already has a live (non-expired) cadimeInvitationLink and this is a first-time launch → return it.
  - if contact was already provisioned before (invite consumed) → return the plain CADI login URL (https://app.cadime.ai).
  - otherwise call inviteStudent(), persist link + timestamps on the contact, return the invitationLink.
- inviteStudent({ contact, job }) — axios.post(${hostname}/invitations, body, { headers: { 'X-Api-Key': apiKey }}) where body = { userType, name: ${firstName} ${lastName}, email, role: defaultRole, curriculumId: job?.cadimeCurriculumId || defaultCurriculumId, sendEmail: false }. Log failures with console.error + full error object + contact email/id.
controller cadime.js — launch(ctx):
- resolve the student contact from ctx.state.user (the authenticated Strapi user → its contact).
- validate optional jobId with yup (abortEarly + stripUnknown), load the job if present.
- delegate to the service, return { url }.
route src/api/cadime/routes/cadime.js — POST /cadime/launch, protected by global::is-contact (students only). Actual path: POST /api/cadime/launch.

Follow TDD (red→green→refactor) per repo CLAUDE.md; add controller/service tests under test/.

Frontend changes — `enrich-student-portal`

API service — add client/src/api/cadime-service.js (or extend client/src/api/index.js) with launchCadime(jobId?) → POST cadime/launch via the existing authenticated axios instance, then openInNewTab(res.url) using the existing helper in client/src/components/App/HelperFunctions.js (openInNewTab).
Per-matched-job launch — add a “Practice interview” button on client/src/components/Pages/JobMatches/JobPage.js (route /job-matches/:id), passing that job’s id. Show it for jobs that have a cadimeCurriculumId (fall back to the general hub otherwise).
General practice hub — repurpose the existing mock-interview entry point: client/src/components/Pages/Dashboard/MockInterviewReminder.js currently routes its CTA to /todos; point it at launchCadime() (no jobId → uses defaultCurriculumId). Optionally add a dashboard card / nav item for a persistent entry.
Student identity for the invite (email, firstName, lastName) is already on the user.contact object from ProvideAuth.js — the CMS reads it server-side from the JWT, so the portal only sends jobId.

The current mock-interview mechanism is a Calendly link: createMockInterviewTask() in src/plugins/enrich-scholars/server/services/company.js using CALENDLY_MOCK_INTERVIEW_URL. v1 adds the CADI launch alongside it; deciding whether CADI fully replaces that Calendly task is a separate product call (leave as-is for v1).

Open dependencies to confirm with CADI (not blockers for scaffolding)

Valid role value(s) for userType: "education" (needed for the invite body).
invitationLink behavior — does opening it require the same email / auto-create the session, and what is expiresAt (re-invite policy for expired, unaccepted invites)?
Seat management — how invited-but-inactive students affect paid seats (relevant to lazy provisioning; cancel-seat handling is a v2/ops concern).

Out of scope (v2, noted for later)

Pulling results back: nightly cron polling GET /api/users/{userId}/performance + /trainings (resolve cadimeUserId via GET /api/users by email), a new mock-interview/interview-result content type modeled on welcome-call-feedback, a mock_interview_completed event type, and a ContactMockInterviews section in coaching-platform’s ContactProfile.

Verification (end-to-end)

Set CADIME_API_KEY + CADIME_FEATURE_ACTIVE=true locally; run enrich-cms (npm run develop).
In Strapi admin, set cadimeCurriculumId on a test job.
npm test -- --testPathPattern="cadime" — service/controller unit tests green.
Manual: as a test student in the portal, click “Practice interview” on a matched job → confirm POST /api/cadime/launch returns a CADI invitationLink, a new tab opens to app.cadime.ai/invite/…, and the contact row now has cadimeInvitedAt / cadimeInvitationLink set.
Click again → confirm it does not re-invite (returns login URL / existing link).
Repeat from the general hub (no jobId) → confirm it uses the default curriculum.

Workflow notes

enrich-cms and enrich-student-portal both use the OpenSpec change workflow (openspec-propose skill) — start the CMS work there. Use a shared branch e.g. feat/cadime-mock-interview across both repos (via the new-branch skill). Commits follow Conventional Commits; pre-commit runs format + lint.