For online proctoring and assessment platforms
A connection test for your exam system check
Camera, microphone, browser: your system check covers them. The connection is the one that fails mid-exam. Add a real test to the check, get the numbers back to your platform, and decide before the session starts.
30-day free trial · 100 API calls · No credit card · Plans from $49/month
This is the test a candidate would run inside your system check. Your platform receives the numbers instead of the screen.
Add it to the system check
One script tag on the page candidates already visit before the exam. Run it on load or on a button; no download, no extension.
Compare with your thresholds
Your callback receives download, upload, latency and jitter. Webcam and screen-share streams need upload above all.
Gate, retest, record
Let the candidate start, ask them to fix the connection and retest, or route them to support. Keep the result with the attempt.
Why the system check needs a real test
A proctored session is an upload workload. The candidate's webcam, microphone and often a screen share stream to the proctor for the whole exam, and a connection that browses perfectly well can still drop that stream every few minutes. A check that only confirms the device is online passes those candidates, and the failure arrives as an integrity flag, a resumed attempt, or an appeal.
A measured test moves that failure to before the exam, where it is a retest instead of an incident. The candidate runs it in the same browser, usually in under a minute, and your platform gets a number to compare with the bar you set.
What to test, and the bar
| Metric | What depends on it | Typical requirement |
|---|---|---|
| Upload | Webcam, microphone and screen-share streams to the proctor | 1.5 to 3 Mbps sustained; more with screen share |
| Download | Exam content, proctor audio, remote instructions | 1.5 to 3 Mbps |
| Latency | Proctor interventions, live chat, timed interactions | Under 150 ms |
| Jitter | Stream stability over a long session | Under 30 ms |
Sustained matters more than peak for a two-hour session. The test measures with progressively larger real files until the speed holds, so the upload number reflects what the line can keep doing, not a burst.
What your platform receives
| Property | Type | What it means |
|---|---|---|
| download | number | Average download speed in Mbps |
| upload | number | Average upload speed in Mbps |
| maxDownload, maxUpload | number | Peak speeds in Mbps |
| latency | number | Minimum round trip in milliseconds |
| jitter | number | Latency variance in milliseconds |
| testServer | string | Which test server the browser reached |
| ip_address, hostname, userAgent | string | Who ran it, for your records |
The result arrives in your page's callback, so it can be written to the attempt record and used to gate the start. It is measured between the candidate's browser and our servers, and every test is also logged in your analytics dashboard with date, location and device, which is the record you want when an attempt is disputed.
Fits the check you already have
The API is headless, so the test sits inside your existing system-check page in your own design: a row next to camera and microphone, with your pass, warn and fail states. It runs in any modern browser and inside a locked-down browser's WebView, with nothing for the candidate to install. Retesting is one more call to startTest().
Hiring platforms, contact centres and ISPs have run their connection checks on this API since 2013.
What it costs
Every completed test is one API call. The 30-day trial includes 100 calls and needs no card. Paid plans start at $49 a month for 1,000 calls (Startup), then $149 for 10,000 (Business) and $599 for 100,000 (Pro); enterprise volume is priced on request. The full table is on the API page.
Questions people ask
Can a candidate manipulate the result?
The test transfers real files between the candidate's browser and our servers; the result is reported by the API to your callback and your dashboard, not entered by the candidate.
Does the test interfere with the proctoring session?
No. It runs before the session, on your system-check page, and usually finishes in under a minute. Nothing from it stays running once the exam starts.
Will it work in a locked-down browser?
It runs anywhere a modern browser engine runs, including WebViews inside secure or kiosk browsers, and needs no extension or plugin.
Can we require a retest after a change?
Yes. Each call to startTest() runs a fresh test; your page decides when to allow one and what to do with the new numbers.
Does the check have to run on the exam device?
Yes, that is the point of it. The test measures the connection it runs on, so it belongs on the device and network the candidate will sit the exam with, ideally at the same time of day. A pass on a phone in another room says nothing about the laptop in the exam room.
30-day free trial · 100 API calls · No credit card · Plans from $49/month