Changes to the API, SDKs, embeds, and question type platform, in chronological order.
Workspace integrations — the third-party services an organization connects to Examplary — now have their own endpoints. List them, read one, connect or update one with a POST, and disconnect with a DELETE.
Handy if you're provisioning workspaces programmatically and want the integrations set up as part of that, rather than by hand afterwards.
Updating a test or a folder with a POST is deprecated. Both routes still work today, but they'll be removed, so it's worth switching while there's no rush.
Use PATCH instead: PATCH /exams/{id} and PATCH /folders/{id}. The request body and the response are unchanged, so for most integrations it's a one-word fix.
GET /org/limits tells you what a workspace is allowed to do on its current plan, and how much of it has been used.
Worth calling before you kick off a big batch of work, so you can tell your users they're about to run out rather than letting a request fail halfway through.
Organizations on Examplary get a full audit trail of significant actions — sign-ins, grading decisions, permission changes, API key rotations. You can now read it programmatically and feed it into your own SIEM or compliance tooling.
GET /audit-logs pages through the entries, and GET /audit-logs/export gives you the lot in one go. Both need the audit-logs:read scope.
The prompt templates teachers pick from when writing AI instructions are now managed over the API: list, create, update and delete them under /prompts.
If your product has its own house style for how questions or feedback should be written, you can push those in as templates and have them show up in the editor.
Comments left on a student's answer while marking are now readable and writable over the API, under /exams/{id}/sessions/{sessionId}/comments — list, create, update and delete.
Each comment carries its visibility, so you can tell the notes teachers leave for each other apart from the feedback the student sees.
Embed Sessions started out as a way to give teachers Examplary's authoring tools inside your product. There are now two flows for the other side of the classroom:
take-exam — a student sits a test without leaving your platformpractice-space-student — a student works through a practice space at their own paceThey're created the same way as every other flow, with a POST /embed-sessions call and the student's user ID as the actor.
@examplary/sdk has been rebuilt around one method per API operation, with typed inputs and responses throughout:
import { Examplary } from "@examplary/sdk";
const client = new Examplary({ apiKey: process.env.EXAMPLARY_API_KEY });
const exam = await client.exams.create({
name: "End-of-term assessment",
language: "en",
});
Path, query and body parameters go into a single object, and every method takes an optional axios request config as a second argument if you need a timeout or an abort signal. It's generated from the same OpenAPI spec as the reference docs, so it keeps up with the API automatically.
The authorization code flow now supports PKCE, so you can add Sign in with Examplary to a mobile or single-page app without shipping a client secret.
Send a code_challenge and code_challenge_method when you redirect users to authorize, then the matching code_verifier when you exchange the code for tokens. Everything else works exactly as it does today — see the OAuth guide.
You can now build integrations that act on behalf of Examplary users, instead of asking them to paste an API key into your product.
Register an application under Account → Developer → Manage OAuth clients, send users through the authorization code flow, and you get back an access token you can use as a Bearer token on any API request — the same way an API key works today.
Tokens are scoped, so you only ask for the parts of a workspace you actually need, and users see exactly what you asked for on the authorization screen. When someone disconnects your integration, call POST /oauth/revoke to clean up their tokens.
Full walkthrough in the OAuth guide.