CBT simulator API

A CBT simulator API provides the question data needed to build software that behaves like a computer-based examination system.

The API itself is not the simulator. It supplies structured questions, answers, explanations and related examination data, while your application handles the actual CBT experience: timer, navigation, answer selection, submission, scoring and results.

For developers building UTME, WASSCE, NECO or Post-UTME simulators, SdashAPI can serve as the examination-data layer.

How a CBT simulator works

A simple architecture looks like this:

Student
   ↓
CBT Simulator
   ↓
Your Backend
   ↓
Question API
   ↓
Exam Questions

Your application is responsible for creating the examination session.

For example:

Exam: UTME
Subject: Physics
Year: 2019
Questions: 40
Duration: 30 Minutes

The API supplies the questions. Your software turns them into a timed CBT session.

Using the real SdashAPI endpoint

According to the current SdashAPI Documentation, the V1 question endpoint is:

GET https://sdashapi.com/api/v1/q

Authentication uses the AccessToken header.

A real request for 40 UTME Physics questions from 2019 follows this format:

curl -X GET "https://sdashapi.com/api/v1/q?subject=physics&type=utme&year=2019&limit=40" \
  -H "AccessToken: YOUR_ACCESS_TOKEN"

The filters here are:

subject = physics
type    = utme
year    = 2019
limit   = 40

SdashAPI currently documents a maximum of 50 questions per request.

JavaScript example

A backend request can look like:

const response = await fetch(
  "https://sdashapi.com/api/v1/q?subject=physics&type=utme&year=2019&limit=40",
  {
    headers: {
      AccessToken: process.env.SDASH_API_KEY
    }
  }
);

const result = await response.json();

if (result.status === 200) {
  const questions = result.data;

  // Create CBT session
}

This uses the documented SdashAPI endpoint and authentication method rather than an invented API format.

Creating the actual simulator

Once the questions have loaded, your application can create an interface such as:

PHYSICS CBT

Time Remaining: 24:38

Question 12 of 40

[Question text]

A. Option A
B. Option B
C. Option C
D. Option D

[ Previous ]       [ Next ]

1  2  3  4  5  6  7  8  9  10

Your application should keep track of:

Current question
Selected answers
Answered questions
Unanswered questions
Flagged questions
Remaining time

None of these requires another API request every time the student moves to a different question.

Fetch the session before starting the timer

A common mistake is:

Start Timer
    ↓
Request Question 1
    ↓
Request Question 2
    ↓
Request Question 3

That makes the examination dependent on the network throughout the session.

A better approach is:

Request 40 Questions
        ↓
Questions Loaded
        ↓
Create CBT Session
        ↓
Start Timer
        ↓
Navigate Locally

A temporary network interruption is then less likely to interrupt an active examination.

Don't expose answers during exam mode

Question data can contain the correct answer and solution.

That doesn't mean your simulator should immediately send those fields to the examination interface.

Your backend can transform:

{
  "id": 5102,
  "question": "Solve for x...",
  "option": {
    "a": "2",
    "b": "5",
    "c": "10",
    "d": "20"
  },
  "answer": "b",
  "solution": "..."
}

into an active-exam payload such as:

{
  "id": 5102,
  "question": "Solve for x...",
  "option": {
    "a": "2",
    "b": "5",
    "c": "10",
    "d": "20"
  }
}

Keep the answer on your backend.

After submission, grade the attempt and return the correct answers and explanations.

This is especially useful if you're trying to create a realistic mock examination rather than a simple practice quiz.

Store answers by question ID

As the student answers:

{
  "question_id": 5102,
  "selected_answer": "c"
}

Store this in the examination session.

If they return to Question 12 later, their previous selection should still be there.

At submission, your backend can grade the entire session.

Support multiple examinations

The same CBT engine doesn't need to be rewritten for every examination.

You could build:

Choose Examination

UTME
WASSCE
NECO
Post-UTME

Your interface remains largely the same.

The question request changes according to the selected examination.

That is one advantage of using a structured examination API rather than maintaining completely separate application logic for every exam.

Use different simulator modes

Your CBT application can provide several modes.

Practice Mode

No strict timer
Check answer immediately
Read explanation

Mock Mode

Timed
Answers hidden
Submit before seeing results

Past Questions Mode

Choose Exam
Choose Subject
Choose Year
Start

Topic Practice

Where topic metadata is available:

Biology
   ↓
Genetics
   ↓
20 Questions

One question-data infrastructure can therefore support several learning experiences.

Use richer API versions when needed

A basic CBT simulator may only require the question, options and answer.

A more advanced learning application may need:

Topic
Subtopic
Difficulty
Skill
Tags
Detailed explanations
Why the correct answer is correct
Why other options are wrong

SdashAPI provides different API versions for different levels of question detail.

Check the current SdashAPI Documentation before choosing which version your application should use.

Don't request significantly richer data than your application actually needs.

Handle API failures properly

Your simulator should never show students something like:

Unhandled Promise Rejection

If the API cannot return the selected questions, show a useful message.

For example:

We couldn't prepare this examination. Please try again or choose another year.

Your backend should also handle invalid credentials, unavailable question combinations and usage limits appropriately.

Start with 2,000 free credits

SdashAPI provides 2,000 free credits for development and testing.

This is enough to begin building and test important parts of your simulator, including:

Question fetching
Subject selection
Year selection
CBT navigation
Timer behaviour
Answer storage
Scoring
Explanations
Images
Error handling

You can start through SdashAPI and follow the real request formats in the SdashAPI Documentation.

Move to production separately

When your simulator is ready for real students:

Development API Key
        ↓
Testing Complete
        ↓
Production API Key
        ↓
Your Backend
        ↓
Live CBT Simulator

You can review production options through SdashAPI Pricing and confirm available examination data through SdashAPI Coverage.

SdashAPI is an independent examination-data platform and is not an official JAMB, WAEC or NECO service.

A CBT simulator API solves one major part of the development problem: getting structured examination data into your software. Your job is then to turn that data into a fast, reliable examination experience with proper timing, navigation, scoring and useful post-exam review.