A REST API for selection workflows.
What the API covers
The dashboard and the API are the same thing. The dashboard is a client of the API. Anything you can do in one, you can do in the other.
That includes: creating programmes, defining evaluation criteria, accepting application submissions, triggering AI evaluation, fetching scores with citations, recording reviewer overrides with reasons, finalising decisions, generating fairness reports, and pulling outcome data 6/12/24 months after award.
There is no separate “internal API” we keep for ourselves. The reason: we use the same endpoints in our own consoles, so the contract gets pressure-tested every day.
Three surfaces
Submit & evaluate
POST an application packet (resume, transcripts, essays, video). Get back an evaluation with per-criterion scores, each anchored to a passage in the source documents. Synchronous for small payloads, webhook for the heavy ones.
Reviewer streams
Server-Sent Events stream reviewer comments, score changes, and overrides in real time. Useful if you're piping decisions into a downstream system (an LMS, a CRM, a board-pack generator) and want the audit trail without polling.
Outcomes & reports
After award, your beneficiaries get a magic-link portal to log outcomes (publications, employment, milestones). The API exposes the same data so you can publish your own donor reports or wire engagement metrics into your existing impact-reporting stack.
Auth
Two key types. Server-side keys (sk_live_*, sk_test_*) for backend calls, scoped per organisation and never exposed to a browser. Public keys (pk_live_*) for the embedded reviewer widget, scoped to a single programme and read-only.
Both pass as Bearer tokens. Rate limits are per key, not per organisation, so a runaway script can't take down your reviewer dashboard.
What we don't have yet
No GraphQL. REST only. We'd rather ship one well-documented surface than two half-documented ones.
No webhooks for every event. We emit webhooks for the big lifecycle transitions (application.submitted, evaluation.completed, decision.finalised, outcome.recorded). Everything else, you poll or open an SSE stream.
No published SDK packages yet. The OpenAPI schema generates clients cleanly in TypeScript, Python, and Go via openapi-generator, and we'll publish official packages when our pilot customers tell us which language they need first.
No marketplace of pre-built integrations. When we get there, the first three will be Salesforce (because foundations live there), HubSpot (because programme managers live there), and Google Workspace (because everyone lives there). Until then, tell us what you're wiring FairLens into and we'll help.
Want to see the OpenAPI schema before you commit?