Pipeline Overview
The talentino-sst state machines that Partner API calls trigger.
The talentino-sst backend is a serverless (SST/AWS) platform that processes Resumes and Job Matches through Step Functions state machines, coordinated over EventBridge events. Your Partner API calls don't talk to these machines directly — they seed the necessary data and publish an event that starts the right machine. This page maps the flow so the IDs you get back make sense.
The three endpoints below are internal pipeline triggers, not partner-callable.
They are documented for Talentino engineers. They are not secured with the
tlt_ partner key — see their auth note.
The three state machines
| State machine | Started by | What it does |
|---|---|---|
| ResumeStateMachine | POST /process-resume { resume_id } | Verify document → extract content → extract details (parallel) → finish Resume Processing. |
| ImportActivityStateMachine | POST /process-import-activity { import_activity_id } | Process the Resumes grouped under an Import Activity (shallow vs deep depending on activity status). |
| JobMatchStateMachine | POST /start-processing { job_match_id } | Get related Resumes → process fresh ones → score the pool → update the Job Match. |
Naming note: the project's CONTEXT-MAP.md lists ResumeStateMachine,
JobMatchStateMachine, and GraphFilling, but the code also wires an
ImportActivityStateMachine for /process-import-activity. The reference
follows the code.
How a Resume import flows
POST /api/v1/resumesingests the document and creates (or links) an Import Activity, then publishes an Import Activity processing event.- The ImportActivityStateMachine picks it up; per-Resume work runs through the ResumeStateMachine (verify → extract → finish).
- When unknown skills/roles/degrees are encountered, Resume Processing emits events the Knowledge Graph and Education contexts consume to grow their catalogs.
candidate_idis resolved during this flow — which is why it'snullin the import response.
How a Job Match flows
POST /api/v1/job-matchesvalidates candidates, ingests any fresh Resume documents, extracts requirements from the job document via the LLM flow, commits all candidates straight toresume_scores, seeds the match data in Redis, and publishes a Job Match processing event.- The match is created in
draftstatus on purpose: the internalstart-processingstep only runs requirements extraction and Job Position creation while the match isdraft, then flips it toongoingitself. (job_position_idis thereforenullin the API response — the machine creates it asynchronously.) - The JobMatchStateMachine processes any fresh Resumes, then fans out one Scoring task per Resume. Scoring reads the Knowledge Graph (transferability/adjacency) and Education catalogs to compute per-facet Scores and the aggregate Resume Score.
- Conformity checks (Rate Cards & Conformity) classify each candidate; the
conformity_decision(defaultscore_all) drives routing.
Internal trigger endpoints
Auth on these endpoints is not the Partner API key and there is no API Gateway authorizer. Instead they expect an Authorization header equal to a per-resource token stored in Redis (job_match_cookie:{id}, resume_cookie:{id}, import_activity_cookie:{id}); a mismatch returns 401. Several inputs arrive via Redis side-channels rather than the request body (for example start-processing reads jobMatchData:{id} when the match is draft).
See the Pipeline API reference for the exact request/response of each trigger.