JAMB CBT API

A JAMB CBT API gives developers a structured way to add UTME questions, answers and related examination data to CBT applications without manually building and maintaining the entire question bank.

If you are developing a JAMB practice app, UTME mock examination website, school CBT platform or another EdTech product, the CBT interface itself is only one part of the work.

You can design a beautiful examination screen with a timer, question palette, Previous and Next buttons and automatic scoring, but the application still needs the actual examination data that powers those features.

That is where a JAMB CBT API can become useful.

SdashAPI provides examination data through an API that developers can integrate into their own software. Instead of making SdashAPI your entire application, you can use it as the data layer while keeping control of your own interface, users and product features.

What is a JAMB CBT API?

A JAMB CBT API is an application programming interface that allows a CBT application to communicate with a structured source of UTME examination data.

Imagine a student opens your application and selects:

UTME Practice

Subject: Physics
Year: 2024
Questions: 40

Your application needs to find 40 suitable questions.

Instead of storing those questions directly inside your frontend, your application can request them from an API.

The basic flow becomes:

Student
   ↓
CBT Application
   ↓
Your Backend
   ↓
JAMB CBT API
   ↓
UTME Questions
   ↓
Your Backend
   ↓
CBT Application

The student doesn't need to know where the data came from.

They simply see a normal CBT examination.

A JAMB CBT API is not the same thing as a CBT application

This distinction is important.

The API provides examination data.

Your application provides the CBT experience.

For example, an API might provide:

{
  "id": 82731,
  "question": "Which of the following...",
  "option": {
    "a": "Option A",
    "b": "Option B",
    "c": "Option C",
    "d": "Option D"
  },
  "answer": "c",
  "solution": "Explanation goes here.",
  "examtype": "UTME",
  "examyear": "2024"
}

Your application decides how that becomes:

PHYSICS

Question 12 of 40

Which of the following...

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

[ PREVIOUS ]                 [ NEXT ]

Time Remaining: 26:41

The API does not decide your colours, layout, timer, subscription model or navigation.

It supplies structured data that your application can work with.

Why developers search for a JAMB CBT API

Building the visual part of a CBT system is relatively straightforward compared with maintaining years of examination data.

You can create a basic CBT interface with React, React Native, Flutter, JavaScript or another framework.

Then comes the harder question:

Where will the questions come from?

You may need:

Questions
Options
Correct answers
Solutions
Examination years
Subjects
Passages
Images and diagrams
Topics
Difficulty information
Unique IDs

And those records need to remain consistently structured.

A developer who manually manages all of this is effectively maintaining two products:

Product 1:
The CBT application

Product 2:
The examination database

Using an API can separate those responsibilities.

How SdashAPI fits into a JAMB CBT application

SdashAPI can act as the examination-data layer.

Your architecture might look like:

React Native / Flutter / Web App
              ↓
         Your Backend
              ↓
           SdashAPI
              ↓
        UTME Question Data

Your backend can request the questions required for a particular examination session.

The frontend then handles presentation and interaction.

You can review current examination and year availability through the SdashAPI Coverage Page.

A practical JAMB CBT example

Suppose you want students to practise 40 Chemistry questions.

The student selects:

Examination: UTME
Subject: Chemistry
Questions: 40

Your application sends the appropriate request to your backend.

Your backend requests the question data.

The response contains the questions required for that session.

Your application can then initialise:

const exam = {
  currentQuestion: 0,
  answers: {},
  flagged: [],
  timeRemaining: 2400
};

When the student chooses option B for Question 82731:

exam.answers[82731] = "b";

Then they move to the next question.

At the end of the examination, your scoring system compares their selections against the correct answers.

The question API does not need to manage that entire process.

Your application does.

Build the examination session before the timer starts

One useful design choice is to prepare the question session before starting the examination timer.

Avoid this:

Start Timer
   ↓
Request Question 1
   ↓
Wait
   ↓
Request Question 2
   ↓
Wait

A better approach is:

Student taps Start
       ↓
Request examination questions
       ↓
Validate response
       ↓
Create session
       ↓
Display Question 1
       ↓
Start timer

This prevents students from losing examination time simply because a network request is slow.

Fetch questions in batches

A CBT application normally needs multiple questions.

If you need 40 questions, making 40 separate requests may be unnecessary.

Instead:

Request 40 questions
       ↓
Receive question array
       ↓
Store session temporarily
       ↓
Student navigates locally

Now clicking Next does not necessarily require another network request.

That can make the examination experience faster and more stable.

Your CBT should survive temporary network problems

This is especially important for mobile applications.

Imagine a student begins a 40-question examination and their internet connection disappears after Question 17.

If every Next button depends on another API request, the examination may stop completely.

A better architecture is to retrieve the examination session first and allow navigation through the already loaded questions.

For example:

Internet available
       ↓
Load examination session
       ↓
Questions stored temporarily
       ↓
Student begins examination
       ↓
Temporary internet interruption
       ↓
Student can continue current session

Whether and how you cache API data should always follow the terms of your API plan and licence.

For projects requiring extensive permanent offline question storage, discuss the requirement separately through SdashAPI Contact.

Don't expose answers before they are needed

Your frontend architecture also deserves attention.

If you're building a competitive or controlled CBT environment, returning every correct answer directly to an easily inspectable browser frontend may make cheating easier.

For a simple practice application, that may not matter much.

For a school examination system, it can matter considerably.

A more controlled architecture could be:

Student App
      ↓
Your Backend
      ↓
Question Service

Your backend can decide what information the frontend receives during the examination and what is revealed after submission.

For example, during the test:

{
  "id": 82731,
  "question": "Which of the following...",
  "options": {
    "a": "...",
    "b": "...",
    "c": "...",
    "d": "..."
  }
}

After submission:

{
  "id": 82731,
  "selected": "b",
  "correct": "c",
  "explanation": "..."
}

That separation can make sense for applications where answer visibility matters.

Keep production API credentials on your server

Avoid unnecessarily exposing production credentials in public frontend code.

For example, avoid an architecture where your permanent API key can easily be extracted from a website or mobile application.

A common production setup is:

Mobile App
    ↓
Your API
    ↓
SdashAPI

Your server communicates with SdashAPI.

Your application communicates with your server.

This also lets your backend apply your own rules.

For example:

Is this user logged in?

Does this user have an active subscription?

How many mock exams can this user take?

Should this request be cached?

Has this user exceeded a daily limit?

Only after those checks does your server request the necessary data.

Build practice mode and examination mode differently

A good JAMB CBT app doesn't necessarily need to treat every session the same.

You could have:

Practice Mode

The student answers one question and immediately sees:

Correct

Explanation:
...

Examination Mode

The student answers questions without seeing results.

At the end:

Score: 31/40

Correct: 31
Incorrect: 9

[ Review Answers ]

Both modes can use the same underlying question API.

The difference is your application logic.

Add a question palette

A proper CBT experience often benefits from a question navigator.

For example:

1  2  3  4  5
6  7  8  9  10
11 12 13 14 15

You can visually distinguish:

Answered

Unanswered

Current Question

Flagged for Review

Your state might look like:

{
  1: "answered",
  2: "answered",
  3: "flagged",
  4: "unanswered"
}

Again, this functionality belongs to your application rather than the question API.

Add flag-for-review functionality

Students may want to skip difficult questions and return later.

Your application could maintain:

const flaggedQuestions = [82731, 82742, 82801];

Before submission, show:

You have:

36 Answered
4 Unanswered
3 Flagged

Submit examination anyway?

These details help your product feel like an actual CBT system instead of a basic online quiz.

Use question IDs properly

Question IDs are useful for much more than displaying data.

Suppose the API returns:

Question ID: 82731

Your application can associate activity with that ID.

For example:

{
  "question_id": 82731,
  "student_answer": "b",
  "time_spent": 47,
  "correct": false
}

Later, you can use this information for:

Performance analytics
Revision
Bookmarks
Question reporting
Duplicate prevention
Weak-topic analysis
Recommendation systems

Stable question IDs make these features much easier to implement.

Measure how long students spend on questions

A CBT application can collect useful learning information without changing the question itself.

Suppose a student spends:

Question 1 → 18 seconds
Question 2 → 24 seconds
Question 3 → 2 minutes 31 seconds
Question 4 → 17 seconds

Question 3 may indicate difficulty even if the student eventually answers correctly.

Over time, you can identify areas where a student is both slow and inaccurate.

That creates much richer performance feedback than simply showing a final percentage.

Use topic metadata for performance analysis

If question metadata includes topics, you can create reports such as:

BIOLOGY PERFORMANCE

Ecology             82%
Genetics            41%
Cell Biology        76%
Reproduction        58%
Evolution           69%

Now your application can say:

Genetics needs the most attention.

This is where richer question metadata becomes valuable.

The API is no longer only powering the examination screen.

It can also support the learning system surrounding the examination.

Difficulty can support adaptive practice

Suppose questions contain difficulty information.

Your application could build:

Easy Practice

Standard Practice

Difficult Practice

Mixed Practice

Or automatically adjust the session.

For example:

Student performs well
       ↓
Introduce harder questions
       ↓
Performance drops
       ↓
Adjust difficulty

This kind of feature is optional, but structured question data makes it easier to develop.

Handle images properly

Some UTME questions depend on:

Graphs
Diagrams
Maps
Tables
Scientific illustrations
Mathematical figures

Your question component should therefore support optional images.

For example:

{question.image && (
  <img
    src={question.image}
    alt="Question diagram"
  />
)}

Don't design your interface assuming every question is plain text.

Test your layout with large diagrams and small screens.

Handle passages properly

Comprehension and passage-based questions also need special treatment.

You might display:

PASSAGE

[Passage content]

Question 4 of 8

According to the passage...

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

On mobile, you need to decide whether the passage remains visible while the student changes questions.

Possible approaches include:

Expandable passage

Sticky passage button

Split-screen layout

Passage modal

The right choice depends on your application.

Don't design only for short questions

Developers frequently create their CBT interface using dummy data such as:

What is 5 + 5?

Everything looks perfect.

Then a real question arrives with six lines of text and long options.

The design breaks.

Before launching, test:

Short questions
Long questions
Long options
Images
Passages
Mathematical notation
Slow internet
Small screens
Large screens

Using realistic question data during development helps expose these problems early.

SdashAPI provides 2,000 free credits for testing

You don't need to purchase a large question bank simply to start developing your CBT application.

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

You can use those 2,000 free credits to connect your application, make test requests and understand how the API behaves before choosing a production plan.

A development workflow could be:

Create SdashAPI account
        ↓
Get 2,000 free credits
        ↓
Generate development API key
        ↓
Build CBT interface
        ↓
Connect API
        ↓
Fetch UTME questions
        ↓
Test scoring
        ↓
Test explanations
        ↓
Fix problems

The 2,000 free credits are particularly useful during this stage because you're still experimenting.

You can start from the SdashAPI Website.

Use separate development and production keys

Once your CBT application is ready for real users, generate a separate production API key.

For example:

DEVELOPMENT

localhost
    ↓
Development API Key
    ↓
SdashAPI

Then:

PRODUCTION

cbt.example.com
    ↓
Your Backend
    ↓
Production API Key
    ↓
SdashAPI

This makes your credentials easier to manage and reduces the impact of accidentally exposing a development key.

Estimate production usage before choosing a plan

After development, calculate roughly how your application will consume question data.

Suppose you expect:

1,000 students
×
40 questions per mock examination
×
3 examinations each month

That represents approximately:

120,000 question interactions

The exact relationship between application activity and billable API usage depends on your implementation and current plan rules, but doing this calculation gives you a useful starting point.

You can compare current options through the SdashAPI Pricing Page.

You don't necessarily need the largest plan simply because you have finished development.

Choose according to the expected scale of your product and increase capacity when required.

Pay As You Go can work for gradual launches

Some applications launch with a small group.

Perhaps you're initially testing with:

50 students

before opening registration to thousands.

In that situation, a flexible usage arrangement may make more sense than committing immediately to capacity you don't yet need.

As your application grows, you can review the available plans and move to an option that better matches your usage.

The goal should be predictable infrastructure rather than paying for scale before the users exist.

JAMB CBT API vs a bulk question database

These solve related but different requirements.

With API access:

Your Application
      ↓
Your Backend
      ↓
SdashAPI
      ↓
Question Response

With a bulk dataset:

Licensed Dataset
      ↓
Your Database
      ↓
Your Backend
      ↓
Your Application

Bulk data can make sense when your architecture requires extensive offline operation, direct database ownership or another specialised setup.

API access is often simpler when you want managed access without maintaining the complete source dataset yourself.

For bulk-data requirements or unusual architectures, you can discuss the project through SdashAPI Contact.

Don't confuse offline sessions with owning the dataset

Your application being able to survive a temporary internet interruption is not necessarily the same as permanently downloading an entire examination database.

For example, temporarily preparing one examination session:

API
 ↓
40 Questions
 ↓
Current CBT Session

is very different from:

API
 ↓
Download every available question
 ↓
Permanent local database

Developers should understand the caching and licensing rules of whichever API they use.

If your product requires permanent offline access, confirm that arrangement before designing your architecture around it.

Handle failed requests properly

A real application needs to expect failures.

Possible problems include:

No internet

Request timeout

Invalid API key

No matching questions

Quota exhausted

Server error

Invalid parameter

Never show raw backend errors to students.

Instead of:

HTTP 429

show:

We couldn't prepare your examination right now. Please try again shortly.

You can log the technical error privately for debugging.

Don't let one failed image destroy the examination

Suppose a question contains an image URL but the image fails to load.

Your entire examination screen shouldn't crash.

Handle the failure gracefully.

For example:

Question diagram couldn't be loaded.

[ Retry Image ]

You can also log:

Question ID
Image URL
Timestamp
Error

for investigation.

Save examination progress

A student can accidentally close an application.

Their phone can restart.

The browser can refresh.

A good CBT system should consider whether an active session can be restored.

You might periodically save:

{
  "exam_id": "UTME-BIO-2841",
  "current_question": 23,
  "answers": {},
  "remaining_time": 1042
}

If the application restarts, you can decide whether the examination can continue.

This is application logic rather than something the question API needs to control.

Prevent accidental double submission

When a student taps Submit, disable the button while the request is being processed.

Otherwise:

Tap Submit
Tap Submit again
Tap Submit again

can produce duplicate requests or inconsistent examination records.

A simple state such as:

isSubmitting = true;

can prevent that.

Small implementation details matter in real CBT software.

Add review after submission

After an examination, don't stop at:

27/40.

Allow students to review.

For example:

Question 12

Your Answer: B
Correct Answer: D

Explanation:
...

[ Practise This Topic ]

That turns the CBT system into a learning product rather than only a scoring tool.

Build a "questions I got wrong" feature

Store incorrect question IDs.

Then provide:

Revision

Questions I Got Wrong
Bookmarked Questions
Weak Topics
Previous Mock Exams

Students can revisit their mistakes without searching manually.

This is one of the simplest ways to make question data more useful.

Add a report-question button

Historical question datasets can contain issues that need correction.

Give students a way to report them.

For example:

Report Question

[ ] Wrong answer
[ ] Missing image
[ ] Incomplete question
[ ] Formatting issue
[ ] Explanation issue
[ ] Other

Always attach the question ID automatically.

Developers using SdashAPI can also discuss issues in the SdashAPI Community or reach the team through SdashAPI Contact.

Check UTME coverage before launch

Before promising students a particular subject and year, confirm that the data exists.

Use the SdashAPI Coverage Page to review currently available examination coverage.

Your application can also avoid displaying unsupported combinations.

For example, instead of hard-coding every year:

your system can show only years that are available for the selected subject.

That prevents students from selecting something that produces no results.

Is SdashAPI the official JAMB CBT API?

No.

SdashAPI is an independent examination-data service for developers.

It is not an official API operated by JAMB.

Your application should make the same distinction.

Using UTME question data doesn't mean your product should present itself as an official JAMB application.

Clear branding is important.

What should you look for in a JAMB CBT API?

Before integrating any provider deeply into your application, test it yourself.

Look at:

Question coverage

Does it support the subjects and years you need?

Answers

Can your application mark examinations automatically?

Explanations

Can students understand their mistakes?

Images

Are diagram-based questions supported?

Passages

Can comprehension questions be represented correctly?

Metadata

Are topics, difficulty or other fields available if your product needs them?

Response structure

Is the JSON predictable?

Batch requests

Can you retrieve enough questions efficiently?

Authentication

Can you protect your production credentials?

Testing

Can you experiment before committing financially?

Pricing

Does the production model fit your expected usage?

Support

Can you report technical or question-data issues?

These questions are more useful than simply asking which API claims to have the largest database.

A practical path from idea to production

You can approach development in stages:

1. Design the CBT interface

2. Create your SdashAPI account

3. Start with 2,000 free credits

4. Generate a development API key

5. Fetch your first UTME question

6. Display the question and options

7. Add answer selection

8. Fetch a batch of questions

9. Add Previous and Next navigation

10. Add the examination timer

11. Add a question palette

12. Add flag-for-review

13. Add automatic scoring

14. Add explanations

15. Add subject selection

16. Add year selection

17. Test passages

18. Test images and diagrams

19. Add error handling

20. Save examination progress

21. Add results and analytics

22. Test the complete experience

23. Generate a production API key

24. Choose an appropriate production plan

25. Launch with real users

You can begin through the SdashAPI Website, verify available examination data through SdashAPI Coverage, compare production options through SdashAPI Pricing, ask implementation questions in the SdashAPI Community, or contact the team directly through SdashAPI Contact.

A JAMB CBT API handles the examination-data part of the system. It doesn't replace good software engineering, a reliable backend or a well-designed student experience.

That is actually the useful part of the separation: the API handles structured UTME data while you concentrate on building the CBT product around it.

What is a JAMB CBT API?

A JAMB CBT API is not the same thing as a CBT application

Why developers search for a JAMB CBT API

How SdashAPI fits into a JAMB CBT application

A practical JAMB CBT example

Build the examination session before the timer starts

Fetch questions in batches

Your CBT should survive temporary network problems

Don't expose answers before they are needed

Keep production API credentials on your server

Build practice mode and examination mode differently

Practice Mode

Examination Mode

Add a question palette

Add flag-for-review functionality

Use question IDs properly

Measure how long students spend on questions

Use topic metadata for performance analysis

Difficulty can support adaptive practice

Handle images properly

Handle passages properly

Don't design only for short questions

SdashAPI provides 2,000 free credits for testing

Use separate development and production keys

Estimate production usage before choosing a plan

Pay As You Go can work for gradual launches

JAMB CBT API vs a bulk question database

Don't confuse offline sessions with owning the dataset

Handle failed requests properly

Don't let one failed image destroy the examination

Save examination progress

Prevent accidental double submission

Add review after submission

Build a "questions I got wrong" feature

Add a report-question button

Check UTME coverage before launch

Is SdashAPI the official JAMB CBT API?

What should you look for in a JAMB CBT API?

A practical path from idea to production

How can we help?