How to implement ResumeGuard in an ATS

1. POST /api/analyses

One file per request. Create an API key in the dashboard after a payment method is on file. Read the human docs and OpenAPI spec first.

curl -X POST https://www.resumeguard.io/api/analyses \
  -H "Authorization: Bearer rg_live_YOUR_KEY" \
  -F "file=@candidate-resume.pdf"

Typical 202 body: { id, status: "processing", filename }. 422 not_a_resume is not charged and does not create a row.

2. Poll or ?wait=1

• Default: poll GET /api/analyses/{id} until status is complete or failed. The public docs recommend every 1–2 seconds.
• Synchronous: POST /api/analyses?wait=1 holds the connection and returns 201 with the full JSON.
• Authenticated accounts can GET /api/analyses to list in-flight and completed rows (paginated).
• Analysis webhooks are not implemented. Do not register a callback URL expecting a resume-screening event.

3. JSON you persist

Store scores and flags on the candidate or application record in your ATS. The live example response on /docs includes:

• scores.composite_risk, fabrication_risk, polish_risk (0–100)
• dimensions[] — ten ids with score and flags
• recommended_action — proceed, review_recommended, escalate, or inconclusive
• interview_questions and entity checks for employers and schools

4. HTML report for an iframe or modal

JSON is what you persist and automate on. When a recruiter should see the same report, GET /api/analyses/{id}/html returns a self-contained HTML/CSS document that matches the dashboard (Overall / Findings / Dimension scores tabs, CSS-only, no JS) — same API key, same ownership rules. Pass ?theme=dark (default, dashboard) or ?theme=light so the report matches your ATS chrome. Missing or invalid theme values fall back to dark (no 400). While the analysis is still running, this endpoint returns 202 with a tiny “still running” page; keep polling the JSON GET.

# Dark (default)
curl "https://www.resumeguard.io/api/analyses/ANALYSIS_ID/html?theme=dark" \
  -H "Authorization: Bearer rg_live_YOUR_KEY"

# Light
curl "https://www.resumeguard.io/api/analyses/ANALYSIS_ID/html?theme=light" \
  -H "Authorization: Bearer rg_live_YOUR_KEY"

# PDF — print of the HTML report (unbranded; default theme=light)
curl "https://www.resumeguard.io/api/analyses/ANALYSIS_ID/pdf" \
  -H "Authorization: Bearer rg_live_YOUR_KEY" \
  -o report.pdf

curl "https://www.resumeguard.io/api/analyses/ANALYSIS_ID/pdf?theme=dark" \
  -H "Authorization: Bearer rg_live_YOUR_KEY" \
  -o report-dark.pdf

<iframe src="https://www.resumeguard.io/api/analyses/{id}/html?theme=light" sandbox="allow-same-origin" style="width:100%;min-height:640px;border:0"></iframe>

Fetch with Authorization and set iframe.srcdoc (or inject into a modal). A bare iframe src will not send your API key. The HTML report’s Download PDF button links to GET /api/analyses/{id}/pdf with the same auth — session-cookie iframes can click it; API-key-only embeds should fetch the PDF the same way they fetch HTML. The PDF matches the HTML report (stacked sections, no tab chrome). Neither the HTML nor the PDF includes a logo. Pass ?theme=light (default) or ?theme=dark; invalid values fall back to light.

5. From a staffing ATS

If the desk runs Bullhorn, Greenhouse, Lever, Workday, or iCIMS, the integration is still your code: when a resume lands on the candidate, your backend (or middleware) POSTs that file to ResumeGuard and writes the JSON back onto the record. Those product names are systems teams already use — not certified ResumeGuard marketplace apps.

1. Resume uploaded in the ATS
2. Your service POSTs the file to /api/analyses
3. You poll or wait, then save scores and flags
4. Recruiters review high fabrication risk before client submittal