JAMB question bank for CBT app

A JAMB question bank for CBT app development is the collection of UTME questions, options, answers, explanations and related examination data that powers the practice and mock-exam sections of a CBT application.

You can build an excellent CBT interface with a timer, question navigation, scoring, bookmarks and student accounts, but without a properly structured question bank, there is nothing meaningful for students to practise.

For developers, the main question is therefore not simply:

Where can I find JAMB past questions?

It is:

How can I get JAMB questions in a structured format that my CBT application can reliably use?

There are several ways to approach this. You can manually create your own database, obtain a properly licensed bulk dataset, or use an examination-data API such as SdashAPI to retrieve the questions your application needs.

What is a JAMB question bank?

A JAMB question bank is an organised collection of UTME questions.

For software development, a useful question bank should contain more than question text.

A basic record might contain:

{
  "id": 89421,
  "question": "Which of the following statements is correct?",
  "option": {
    "a": "Option A",
    "b": "Option B",
    "c": "Option C",
    "d": "Option D"
  },
  "answer": "b",
  "solution": "Explanation of the correct answer.",
  "examtype": "UTME",
  "examyear": "2023",
  "image": null
}

That structure allows your application to understand each part of the question.

Your CBT interface can display the question.

The option object becomes selectable choices.

The answer field can be used for marking.

The solution can appear during review.

The examyear can be used for year-based practice.

The id can be used for bookmarks, reports, analytics and revision.

This is considerably more useful to a developer than a PDF containing hundreds of pages of past questions.

A PDF is not a CBT question bank

This distinction causes problems for many developers.

Suppose you download a PDF containing JAMB Biology past questions.

A student can read it.

Your application cannot automatically know:

Where Question 14 begins

Where Question 14 ends

Which options belong to it

Which answer is correct

Which year it belongs to

Whether it has a diagram

Which explanation belongs to it

You would first need to extract and structure that information.

For one examination paper, this may be manageable.

Across many subjects and years, it becomes a significant data project.

A question bank intended for a CBT application should therefore be machine-readable, not simply digitally available.

What should be inside a JAMB CBT question bank?

At minimum, you should look for:

• Unique question ID
• Question text
• Options
• Correct answer
• Subject
• Examination type
• Examination year

Depending on your application, you may also need:

• Solution
• Detailed explanation
• Passage
• Question image
• Explanation image
• Topic
• Subtopic
• Difficulty
• Skill
• Tags
• Section information

You don't necessarily need every field for your first version.

But understanding what is available matters because it determines what features you can build later.

Why unique question IDs matter

Every question should ideally have a stable identifier.

For example:

{
  "id": 89421
}

At first, this might seem unimportant.

Once your application grows, it becomes extremely useful.

Suppose a student answers the question incorrectly.

You can store:

{
  "question_id": 89421,
  "selected_answer": "a",
  "correct": false
}

Now you can build:

Questions I Got Wrong

Bookmarked Questions

Recently Attempted

Report Question

Practise Again

You can also analyse how students perform on a particular question.

Without reliable IDs, these features become harder to maintain.

Organise the question bank by subject

A JAMB CBT application normally needs subject selection.

For example:

Choose Subject

English Language
Mathematics
Biology
Chemistry
Physics
Economics
Government
Commerce
Geography
...

When a student selects Biology, your application should be able to retrieve Biology questions without searching through an unstructured collection.

Conceptually:

Exam: UTME
Subject: Biology

If the student selects Physics:

Exam: UTME
Subject: Physics

This sounds simple, but it depends on every question being properly categorised.

A spelling inconsistency such as:

Biology
biology
BIO
Biology.

can create unnecessary problems in a large database.

Consistent data matters.

Organise questions by year

Students often want to practise a particular examination year.

Your application might provide:

JAMB Biology Past Questions

2024
2023
2022
2021
2020
...

The question bank therefore needs reliable year information.

For example:

{
  "examtype": "UTME",
  "examyear": "2023"
}

Now you can request or filter:

UTME
+
Biology
+
2023

and create a year-specific practice session.

Developers can review currently available UTME years and other examination coverage through SdashAPI Coverage.

Topics make the question bank more useful

Year-based practice is useful, but students don't always want random questions from an entire subject.

Sometimes a student knows exactly where they are struggling.

For example:

Biology

Cell Biology
Genetics
Ecology
Evolution
Reproduction

If questions contain topic metadata, your application can provide targeted practice.

A question could contain:

{
  "metadata": {
    "topic": "Genetics",
    "subtopic": "Inheritance",
    "difficulty": "medium"
  }
}

Now you can build:

Practise Genetics

instead of forcing the student to answer random Biology questions until a Genetics question appears.

Topic information also improves student analytics

Suppose a student completes several Biology tests.

Their overall score is:

68%

That's useful, but limited.

With topic metadata, you could calculate:

Cell Biology        81%
Ecology             74%
Genetics            38%
Evolution           72%
Reproduction        69%

Now the application can identify that Genetics requires attention.

You could then provide:

Recommended Next:

Genetics Practice

[ START 20 QUESTIONS ]

The question bank is now supporting a learning system rather than simply a digital past-question booklet.

Difficulty information can support different practice levels

If questions contain difficulty information, you can create:

Practice Difficulty

Easy

Normal

Difficult

Mixed

You could also create adaptive sessions.

For example:

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

You may not need this in version one of your application.

But choosing structured data early can make these features easier to add later.

Explanations are important for learning

Consider this result:

Incorrect.

Correct Answer: B

The student knows the answer.

But they may still not understand the concept.

A better question bank can provide an explanation.

For example:

{
  "answer": "b",
  "solution": "Option B is correct because..."
}

Then your application can display:

Your Answer: D

Correct Answer: B

Explanation:

[Explanation]

For an exam-preparation application, this can be much more valuable than simply revealing the correct option.

Good explanations should be question-specific

Having an explanation field is not enough if every explanation says something generic like:

B is correct because it is the correct answer.

A useful explanation should address the actual concept tested.

For mathematical questions, it may need to show the calculation.

For Biology, it should explain the biological principle.

For Economics, it should explain why the selected concept applies.

For English, it may need to explain grammar, vocabulary or interpretation.

When evaluating a question bank, inspect the quality of the explanations rather than only checking whether an explanation field exists.

Don't forget passages

Some UTME questions depend on passages.

The data structure should preserve that relationship.

For example:

{
  "passage": "Read the passage below...",
  "question": "According to the writer..."
}

Your application can then display:

[ VIEW PASSAGE ]

Question 3 of 5

According to the writer...

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

On mobile, an expandable passage or dedicated passage view may provide a better experience than repeating a very long passage above every question.

Images and diagrams are part of the question

A question bank isn't complete if a question depends on an image that isn't available.

This is particularly important for subjects such as:

Mathematics
Physics
Chemistry
Biology
Geography

A question may say:

Find the value of x in the diagram.

Without the diagram, the question is unusable.

Your data structure should therefore support something like:

{
  "question": "Using the diagram, calculate x.",
  "image": "https://example.com/question-image.jpg"
}

Your frontend can display the image only when necessary.

if (question.image) {
    // Render question image
}

Test diagrams on mobile devices

A diagram that works on a laptop may be difficult to understand on a phone.

Consider adding:

Tap image to enlarge

Students can then open a full-screen version.

For diagrams containing small labels, graphs or mathematical details, zoom support can make a major difference.

This is a product-design issue that developers sometimes discover only after integrating real questions.

Don't build your UI using only dummy questions

During development, it's tempting to use:

What is 2 + 2?

A. 2
B. 3
C. 4
D. 5

Everything fits perfectly.

Then you connect a real question bank and discover questions with:

Long scenarios

Long options

Passages

Images

Mathematical notation

Tables

Multiple paragraphs

Your layout suddenly struggles.

Real examination data should be introduced early in development.

Where should you store a JAMB question bank?

You generally have two broad approaches.

Store the dataset yourself

Your architecture becomes:

Question Dataset
       ↓
Your Database
       ↓
Your Backend
       ↓
CBT Application

You are responsible for:

Hosting
Database design
Indexing
Updates
Corrections
Backups
Images
Search
Performance

Use a question API

Your architecture becomes:

CBT Application
       ↓
Your Backend
       ↓
Question API
       ↓
Question Data

The question provider maintains the underlying data infrastructure.

Both approaches can work.

The right choice depends on your application.

Using SdashAPI instead of maintaining the entire question bank yourself

SdashAPI provides structured examination data through an API.

For a JAMB CBT application, SdashAPI can operate as the question-data layer.

For example:

Your CBT App
      ↓
Your Backend
      ↓
SdashAPI
      ↓
UTME Questions

Your application remains responsible for:

Users
Subscriptions
CBT interface
Timer
Navigation
Scoring
Analytics
Results
Revision

SdashAPI provides the examination-data infrastructure.

This separation can reduce the amount of data maintenance your team needs to handle.

Build your own backend between the app and question API

For a production application, a useful architecture is:

React Native / Flutter / Website
              ↓
         Your Backend
              ↓
           SdashAPI

rather than exposing your production credentials unnecessarily inside the frontend.

Your backend can decide:

Is this user authenticated?

Does the user have access?

Which subject did they select?

How many questions should be requested?

Has the user exceeded a usage limit?

Then it requests the appropriate question data.

Prepare an entire CBT session before starting

Suppose the student selects:

UTME

Biology

40 Questions

30 Minutes

A sensible flow is:

Student taps Start
       ↓
Backend prepares questions
       ↓
Application receives session
       ↓
Question 1 is ready
       ↓
Timer starts

Avoid starting the timer before the required data is available.

A student's examination time shouldn't disappear while your application is waiting for the network.

Don't request a new question every time the student taps Next

If the examination contains 40 questions, retrieve the required session as a batch where appropriate.

Then:

40 Questions Loaded
        ↓
Question 1
        ↓
Question 2
        ↓
Question 3
        ↓
...
        ↓
Question 40

Navigation happens locally.

This creates a smoother experience and reduces dependence on the network during an active examination.

A question bank can support different CBT modes

Once your data is properly structured, you can reuse it across several experiences.

Quick Practice

10 random questions

Subject Practice

40 Biology questions

Year Practice

UTME Biology 2023

Topic Practice

Biology → Genetics

Mock Examination

Timed examination
No answers until submission

Revision

Questions previously answered incorrectly

You don't need six separate databases.

You need one well-structured question source and different application logic around it.

Avoid unnecessary repetition

Students don't want to repeatedly see the same five questions when hundreds are available.

Store recently attempted question IDs.

For example:

{
  "recent_questions": [
    89421,
    89422,
    89435,
    89461
  ]
}

When preparing the next practice session, your backend can reduce unnecessary repetition where your data-access method supports it.

Eventually, older questions can return to the pool.

Build "Questions I Got Wrong"

This is one of the easiest high-value features to create.

Whenever the student gets a question wrong, save its ID.

For example:

{
  "question_id": 89421,
  "selected": "d",
  "correct": "b"
}

Then create:

Revision

Questions I Got Wrong     67

The student can return specifically to their mistakes.

This makes the question bank much more useful than simply serving random practice questions.

Add bookmarks

Some students will encounter questions they want to revisit.

Allow:

[ Bookmark Question ]

Store:

user_id
question_id
date_bookmarked

Then provide:

Saved Questions

This is another feature made much easier by stable question IDs.

Build a question-reporting system

Large question banks can contain records that require correction.

Give students an easy way to report problems.

For example:

Report Question

○ Answer appears incorrect

○ Question is incomplete

○ Diagram is missing

○ Formatting problem

○ Explanation problem

○ Other

Automatically include:

Question ID
Subject
Year
Exam type

This is far more useful than receiving:

One Biology question is wrong.

Developers using SdashAPI can also use the SdashAPI Community for discussions and the SdashAPI Contact Page when direct assistance is required.

Start building with 2,000 free credits

If you're still developing your CBT app, you don't necessarily need to buy an entire question bank before knowing whether your product works.

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

A developer can:

Create account
      ↓
Get 2,000 free credits
      ↓
Generate development API key
      ↓
Connect CBT application
      ↓
Test with real question data

Those credits can be used while you work on your integration and application behaviour.

You can start through the SdashAPI Website.

What should you test with the free credits?

Use the development stage to test real scenarios.

For example:

Fetch one question

Fetch multiple questions

Filter by subject

Filter by year

Display long questions

Display long options

Render images

Handle passages

Show explanations

Calculate scores

Handle failed requests

Handle empty results

You should know how your application behaves with real data before moving it into production.

Separate development and production

During development:

Local Application
      ↓
Development API Key
      ↓
SdashAPI

When you're ready for actual users:

Production Application
      ↓
Your Backend
      ↓
Production API Key
      ↓
SdashAPI

Using separate credentials makes your infrastructure easier to manage.

A development key can be replaced without unnecessarily affecting your live application.

Choosing a production plan

Once your CBT application is working, estimate expected usage.

Suppose:

1,000 students

× 40 questions

× 5 practice sessions per month

That's approximately:

200,000 question interactions

A platform with 20,000 active students has very different requirements.

Use realistic estimates rather than guessing.

Current production options can be reviewed through SdashAPI Pricing.

SdashAPI provides different ways to move beyond development, including API plans and Pay As You Go, depending on the requirements of the project.

API question bank vs bulk JSON dataset

If you want the questions stored permanently in your own infrastructure, you may actually need a bulk dataset rather than ordinary API access.

API approach

Your CBT App
      ↓
Your Backend
      ↓
SdashAPI
      ↓
Question Data

Bulk dataset approach

Licensed Question Dataset
          ↓
Your Database
          ↓
Your Backend
          ↓
Your CBT App

With a bulk dataset, your team takes responsibility for database infrastructure and data management.

With API access, the question-data infrastructure remains managed externally.

Neither option is automatically right for every application.

When does a bulk JAMB question bank make sense?

A bulk dataset may be appropriate when your application specifically requires:

• Extensive offline operation
• Permanent local question storage
• Your own search infrastructure
• Direct database queries
• Special institutional deployments
• Another architecture that cannot depend on normal API access

These requirements should be discussed separately because bulk-data rights and ordinary API usage are not necessarily the same thing.

You can explain your requirements through SdashAPI Contact.

Offline CBT needs more than downloading questions

If your goal is an offline JAMB CBT application, think beyond the question text.

You may need offline access to:

Questions
Options
Images
Passages
Explanations
Student answers
Timers
Results
Progress

Then you need a strategy for updating that information when internet access returns.

For example:

Online
   ↓
Synchronise permitted data
   ↓
Offline Practice
   ↓
Store results locally
   ↓
Internet returns
   ↓
Synchronise progress

Offline architecture should therefore be planned from the beginning rather than added at the last minute.

Your question bank should not determine your business model

The fact that your application uses an API doesn't mean your users have to pay per question.

You can design your own model.

For example:

FREE

10 questions daily
Basic results

and:

PREMIUM

Unlimited practice
Mock exams
Detailed explanations
Weak-topic analytics
Bookmarks
Revision

Or your application could be completely free and monetised differently.

The question bank is infrastructure.

Your product and business model remain your decisions.

Check question coverage before promising students everything

Before advertising:

Every JAMB subject and every year

verify the actual dataset.

Coverage can vary across subjects and years.

Developers using SdashAPI can check currently available information through the SdashAPI Coverage Page.

Your application can also dynamically show available combinations.

For example:

Student selects UTME
        ↓
Show supported subjects
        ↓
Student selects Physics
        ↓
Show available years

This is better than presenting options that return no questions.

Is SdashAPI an official JAMB question bank?

No.

SdashAPI is an independent examination-data platform for developers and is not an official service operated by JAMB.

If you build a CBT application using UTME examination data, your own product should also avoid presenting itself as an official JAMB application unless it actually has the appropriate official status.

Clear branding helps avoid confusion.

What should you check before choosing a JAMB question bank?

Before committing your application to a question source, inspect it carefully.

Check:

Subject coverage: Does it contain the subjects your application needs?

Year coverage: Are the required historical years available?

Question structure: Is the data machine-readable and consistent?

Answers: Are correct answers provided?

Explanations: Are they useful and question-specific?

Images: Are diagrams preserved?

Passages: Are passage relationships maintained?

Topics: Can students practise specific areas?

Difficulty: Can you build difficulty-based practice if needed?

IDs: Can questions be tracked individually?

Filtering: Can you request the subset you need?

Testing: Can you test before making a larger commitment?

Pricing: Does production usage fit your expected scale?

Licensing: Does your intended commercial or offline use fit the available arrangement?

Support: Is there somewhere to report data or integration problems?

A question bank should be evaluated as infrastructure, not simply by counting how many questions are advertised.

A practical development path

If you're starting a JAMB CBT app, you can approach the question-bank integration in stages:

1. Design your CBT question screen

2. Create your SdashAPI account

3. Get the 2,000 free development credits

4. Generate a development API key

5. Fetch one UTME question

6. Display the question and options

7. Add answer selection

8. Add automatic marking

9. Fetch multiple questions

10. Add subject selection

11. Add year selection

12. Add question navigation

13. Add a timer

14. Add explanations

15. Test images and diagrams

16. Test passages

17. Add bookmarks

18. Add Questions I Got Wrong

19. Add question reporting

20. Add progress saving

21. Add analytics

22. Test with real students

23. Generate a production API key

24. Choose an appropriate production plan

25. Launch and monitor usage

You can start from the SdashAPI Website, check available UTME data through SdashAPI Coverage, review production options through SdashAPI Pricing, join developer discussions through the SdashAPI Community, or discuss a specific project through SdashAPI Contact.

A JAMB question bank for a CBT app should ultimately do more than give you a large collection of questions.

It should provide structured, usable examination data that your software can organise, display, score, analyse and turn into a useful learning experience for students.