Sell it, integrate it, or deliver it.
Xamina is designed to be run by one institution and reached by many. The reseller API below is not a roadmap item or a spreadsheet handover. It is four signed endpoints that issue and reverse real seats today.
Pick the one that describes what you already do
They are not tiers and you can hold more than one. They differ in which part of the examination you take responsibility for.
Reseller
Sell seats on someone else’s exams from your own storefront.
Your checkout calls one endpoint on a completed payment and receives one voucher code. The candidate redeems it on the platform; you never handle enrolment, scheduling or results.
- Live catalogue of the exams you are cleared to sell
- One order, one seat, one exam, enforced at the schema
- Voucher valid twelve months from purchase
- Refunds you can issue yourself, within the rules below
Technology
Put Xamina inside the system your users already open.
Register as an LTI 1.3 platform and the exam becomes a launchable activity with grades posted back. Subscribe webhooks and your own system learns about attempts, results and integrity decisions as they happen.
- LTI 1.3 launch, deep linking and AGS grade sync
- Webhooks from a transactional outbox, with delivery history
- Bulk import and export as tracked jobs
- A documented OpenAPI surface for everything else
Delivery
Invigilate sittings as an accredited centre.
Run supervised sittings under your own brand with the integrity policy set centrally by the awarding institution. You get the room and the candidates, they keep the standard.
- Per-centre departments and staff roles
- Identity check-in on arrival, before the paper opens
- Integrity review queue scoped to your own sittings
- Every action attributed in the audit log
Four calls, from catalogue to refund
Server to server, HMAC-signed, no session and no cookie. An integration is an afternoon, not a project.
/api/v1/partner/catalogueRead what you may sell
The exams this institution has cleared for your account, with the SKU your storefront lists against. Nothing outside the catalogue can be ordered, so a stale product page fails at the order rather than issuing a seat nobody agreed to sell.
/api/v1/partner/ordersTurn a payment into a voucher
Send your own order id and the SKU. You get back one code. Idempotent by contract: a gateway that retries because it was unsure gets the same voucher, never a second one. The pre-check catches the ordinary retry and a unique index catches two retries racing.
/api/v1/partner/orders/:idAnswer your own support desk
Where the order stands (issued, redeemed, sat or refunded) without an email to anybody. Your agent can see that a candidate has already started before they promise a refund.
/api/v1/partner/orders/:id/refundReverse a sale
One call, three possible answers, all of them derived from what the candidate has actually done with the code rather than from a policy document.
You bring the customer
Your relationship, your invoice
We open their account
Registered and configured by us
They run their exams
Separate from every other customer
You see the usage
Seats drawn down, renewals due
Three outcomes, decided by the candidate rather than by us
You call the same endpoint every time. What it does depends on how far the voucher actually got, which means your support desk never has to interpret a policy.
REVOKEDThe code was never redeemed
It is killed where it sits. No enrolment was ever created, so there is nothing else to unwind.
WITHDRAWNRedeemed, but never sat
The enrolment is withdrawn and the seat returns. The candidate saw the exam on their list and never opened it, so nothing about the paper has been exposed.
RefusedAn attempt exists
Once the paper has been opened, the thing that was sold has been delivered. The call is refused rather than silently succeeding and leaving a sat exam attached to a refunded order.
What protects a partner account
You are being handed the ability to mint seats on somebody’s certification. These are the six properties that make that safe to hand over.
The key is stored hashed
Only ever compared, never read back. A copy of the database is not a set of working partner credentials.
The signing secret is sealed
Encrypted rather than hashed, because an HMAC has to be computed and cannot be computed from a digest, so it is protected by the key that never sits in the same place as the data.
Signatures expire in five minutes
Long enough to survive clock drift between two servers, short enough that a captured request is worthless by the time anyone could reuse it.
Method and path are signed
Without them, a captured signature over an empty body (every catalogue read has one) would also be valid for a refund, which is likewise empty-bodied. Binding the signature to the route is what stops a harmless read being replayed as a reversal.
Unknown key and bad signature fail alike
The same response, in the same time. An attacker cannot use the error to discover which partner keys exist.
The tenant is bound by the guard
A partner’s institution is set from the credential, not from anything in the request. There is no field a caller can send that reaches another institution’s data.
Becoming a partner
One
The institution creates the account
An administrator at the awarding institution registers your organisation and chooses which exams your catalogue contains.
Two
Credentials are issued once
A partner key and a signing secret, shown a single time. Neither can be recovered afterwards, only rotated.
Three
You integrate against the docs
Four endpoints, one signing function. The catalogue call is the natural first test: it is read-only and it proves the signature.
Already selling exams somewhere else?
The catalogue endpoint is read-only and costs nothing to try. If your signature verifies, the rest of the integration is three more calls.