API for CBT app

A CBT app is usually not difficult because of the timer.

It is not even the Previous and Next buttons.

One of the harder parts is maintaining the question data behind the application: questions, options, correct answers, explanations, years, subjects, images and other examination information.

That is where an API for CBT app development becomes useful.

Instead of placing thousands of questions directly inside your application, your CBT software can request the questions it needs from an exam-data API.

For African exam-preparation products, SdashAPI provides REST/JSON access to UTME, WASSCE, NECO and Post-UTME question data. Its documentation also includes a full CBT-development tutorial rather than only endpoint references. SdashAPI

What does an API do inside a CBT app?

It helps to separate two things.

Your CBT application is responsible for the experience:

Login
Subject selection
Exam instructions
Timer
Question navigation
Selected answers
Submission
Results
Progress tracking

The question API handles the examination content:

Questions
Options
Answers
Solutions
Exam years
Subjects
Images
Question IDs

So the architecture can be as simple as:

Student
   ↓
Your CBT App
   ↓
Your Backend
   ↓
SdashAPI
   ↓
Question Data

This means you can spend more time building a good CBT experience instead of manually typing and maintaining thousands of questions.

A real SdashAPI request

SdashAPI's current V1 question endpoint is:

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

For example, the documentation gives this request for a UTME Mathematics question:

curl -X GET \
  "https://sdashapi.com/api/v1/q?type=utme&subject=mathematics" \
  -H "AccessToken: YOUR_API_KEY"

The API returns JSON containing the question data your application can process. SdashAPI

That's an important point.

Your CBT interface doesn't have to be built specifically for SdashAPI. It only needs to understand the JSON your backend gives it.

Don't fetch one question every time the student clicks Next

This is one of the easiest ways to make a CBT application unnecessarily slow.

Avoid this:

Question 1
   ↓
API request
   ↓
Question 2
   ↓
API request
   ↓
Question 3
   ↓
API request

Instead, request a batch before the exam begins.

SdashAPI currently supports up to 50 questions in one request using limit. SdashAPI

For example, its documentation uses:

GET https://sdashapi.com/api/v1/q?subject=physics&type=utme&year=2019&limit=40

That is enough to prepare a 40-question CBT session with one request. SdashAPI

A better exam flow therefore becomes:

Student selects exam
        ↓
Student selects subject
        ↓
Fetch question batch
        ↓
Validate questions
        ↓
Prepare CBT session
        ↓
Start timer

The student's examination time should not be disappearing while your app is still waiting for questions to download.

One CBT engine can support different examinations

You don't necessarily need separate software for JAMB, WAEC and NECO.

Your question component might simply understand:

{
  question,
  options,
  selectedAnswer
}

Then your backend decides which examination data to request.

For UTME:

type=utme

For WASSCE:

type=wassce

For NECO:

type=neco

SdashAPI's current documentation lists UTME, WASSCE, NECO and Post-UTME among the examination data supported by the platform. SdashAPI

So your interface can offer:

Choose Examination

UTME
WASSCE
NECO
Post-UTME

and reuse much of the same CBT engine.

The API should not control your CBT design

Using an API does not mean every application built with it should look the same.

One developer might build:

Past Questions → Answer → Explanation

Another could build:

Timed Mock → Submit → Score → Review

Another:

Topic Practice → Weak Areas → More Practice

And another could build a school CBT system with student accounts, scheduled examinations and an administrator dashboard.

SdashAPI supplies the examination-data layer. It does not manage your app's students or authentication; its CBT documentation specifically notes that developers should use their own authentication/backend system for that part. SdashAPI

That separation is useful.

Your product remains your product.

Keep the correct answers away from the active exam screen

An API response may contain the correct answer because practice applications need it.

That doesn't mean your frontend has to expose it during a timed examination.

For exam mode, consider:

SdashAPI
   ↓
Your Backend
   ↓
Prepare questions
   ↓
Remove answer/solution from student payload
   ↓
Student takes CBT
   ↓
Submit selected answers
   ↓
Grade attempt
   ↓
Return score + review

For practice mode, you might intentionally return the answer immediately after each attempt.

The same API data can support both experiences.

Protect your API key

This part is easy to ignore while prototyping.

SdashAPI authenticates requests using:

AccessToken: YOUR_API_KEY

The current authentication documentation specifically warns against committing keys to public repositories or embedding production credentials directly inside frontend applications. It recommends environment variables and server-side requests. SdashAPI

So avoid:

const API_KEY = "my-real-production-key";

inside code shipped to every user.

Prefer:

React / Flutter / React Native
            ↓
        Your Backend
            ↓
         SdashAPI

with something like:

SDASHAPI_KEY=...

stored securely in your backend environment.

SdashAPI also supports multiple API keys, which its documentation suggests using to separate development and production traffic. SdashAPI

You can test the API before writing the full app

You don't even need a CBT interface initially.

The SdashAPI documentation recommends testing requests with tools such as Postman. A documented example is:

GET https://sdashapi.com/api/v1/q?type=utme&subject=english

with:

AccessToken: YOUR_API_KEY

in the Headers section. SdashAPI

If the response looks correct, then integrate it into your backend.

Then build the interface.

This sequence is usually easier to debug than building five screens first and only afterwards discovering that your API request is wrong.

What should a good CBT API let you do?

For a normal exam-preparation product, you will eventually want to retrieve questions according to things such as:

Examination

UTME / WASSCE / NECO / Post-UTME

Subject

Mathematics / Biology / Physics / Economics...

Year

2024 / 2023 / 2022...

Number of questions

10 / 20 / 40 / 50

SdashAPI documents subject, exam, year and limit filtering, along with tutorials for combining these filters. SdashAPI

That means your user interface can translate a student's choices directly into a question request.

For example:

Student chooses:

UTME
Physics
2019
40 Questions

        ↓

Backend requests:

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

Simple, predictable, and much easier to maintain than separate static files for every combination.

What if you are building with React Native, Flutter or Python?

The API isn't tied to one programming language.

SdashAPI returns standard JSON, and its current documentation/tutorial library includes integration material for JavaScript, Python, PHP, Node.js, React, React Native, Flutter and Next.js. SdashAPI

So the basic idea remains the same:

Make HTTP request
      ↓
Receive JSON
      ↓
Parse questions
      ↓
Render your own UI

For example, modern Node.js can use the native fetch() API while keeping the SdashAPI key inside an environment variable on the server. SdashAPI's Node.js guide demonstrates exactly that architecture. SdashAPI

Start with the smallest useful CBT

A common mistake is trying to build everything immediately:

AI tutor
Leaderboards
Multiplayer
Adaptive learning
Offline mode
Achievements
Social features
Analytics
School dashboard

before one student can successfully finish ten questions.

Start here:

1. Select exam
2. Select subject
3. Fetch questions
4. Display question
5. Select answer
6. Previous/Next navigation
7. Timer
8. Submit
9. Calculate score
10. Review answers

Interestingly, SdashAPI's current tutorial library follows almost this exact progression. Its CBT series covers fetching subjects and questions, question interfaces, previous/next navigation, number navigation, countdown timers, answer systems, scoring, results, review, random questions, exam/practice modes, offline caching, authentication, leaderboards and deployment. SdashAPI

So developers who need more than an API reference can follow the SdashAPI CBT tutorials while building.

Where SdashAPI fits

SdashAPI should not be confused with JAMB, WAEC or NECO themselves. It is an independent exam-data infrastructure product for developers.

Its job is not to decide what your CBT application should look like.

Its job is to make this part easier:

"I need structured examination questions."

so you can spend your time solving this:

"How do I build a CBT product students actually enjoy using?"

You can start with the SdashAPI documentation, make a real API request, and use the available free developer access to test your integration before moving the application into production. SdashAPI