JAMB Past Questions API: How Developers Can Add UTME Questions to CBT and EdTech Apps

If you are building a JAMB CBT app, UTME practice website, examination simulator, school portal or EdTech platform, one of the first problems you will encounter is where to get JAMB past questions in a format your application can actually use.

A JAMB past questions API solves this differently from downloading PDFs, manually typing questions or maintaining thousands of questions yourself.

Instead of storing every question directly inside your application, your software sends a request to an API and receives structured data containing the question, options, correct answer and other available information.

For example, your application could request:

UTME + Biology + 2022

and receive the matching question data as JSON.

This article explains how a JAMB past questions API works, what developers should look for before choosing one, and how SdashAPI can be used as the question-data layer of a CBT or examination-preparation application.

What Is a JAMB Past Questions API?

A JAMB past questions API is an application programming interface that allows another application to retrieve UTME examination questions programmatically.

Instead of having something like this buried inside a PDF:

Question → Options → Answer

your application receives structured information that can be processed directly by your code.

A basic question object may contain fields such as:

{
  "id": 4821,
  "question": "Question text goes here",
  "section": null,
  "option": {
    "a": "Option A",
    "b": "Option B",
    "c": "Option C",
    "d": "Option D"
  },
  "answer": "b",
  "solution": "Explanation of the answer",
  "image": null,
  "examtype": "UTME",
  "examyear": "2022"
}

Your frontend can then decide how that information should appear to the student.

For example, you might display the question inside a React Native application, allow the student to select an option, save the selected answer and calculate the score when the examination ends.

The API supplies the examination data. Your application controls the experience around that data.

Why Not Just Store JAMB Questions Yourself?

You certainly can.

For a very small application, manually maintaining a question database might even make sense.

The problem becomes clearer when the application grows.

Imagine maintaining questions across Mathematics, English Language, Biology, Chemistry, Physics, Economics, Government, Commerce, Geography and many other subjects.

Then imagine separating those questions by examination year.

You may also need to maintain:

• Options
• Correct answers
• Solutions
• Passages
• Images and diagrams
• Topics
• Difficulty levels
• Unique question IDs
• Corrections
• Metadata

At that point, you're no longer only building a CBT application.

You're also building and maintaining an examination-data infrastructure.

An API separates these responsibilities.

Your team can concentrate on things such as authentication, subscriptions, examination timers, leaderboards, student performance, UI/UX, notifications and analytics while the question service handles structured examination content.

How a JAMB Past Questions API Works

The process is fairly straightforward.

Your application sends an HTTP request containing information about the questions it needs.

For example:

GET /questions?exam=utme&subject=biology&year=2022

The API processes the request and returns matching questions.

Your application then reads the response and displays it however you want.

A typical flow looks like:

Student selects Biology
        ↓
Student selects 2022
        ↓
Your application sends API request
        ↓
Question API finds matching UTME questions
        ↓
JSON is returned
        ↓
Your application displays the questions
        ↓
Student answers
        ↓
Your application calculates the result

This means the question API does not have to determine how your entire CBT application works.

It provides the data your application needs.

Using SdashAPI as a JAMB Past Questions API

SdashAPI provides REST endpoints for retrieving structured examination questions.

Its documentation currently supports filtering questions using parameters including:

subject

type

year

limit

id

For JAMB questions, the examination type is specified as utme. SdashAPI

For example:

curl "https://sdashapi.com/api/v1/q?subject=biology&type=utme&year=2022" \
  -H "AccessToken: YOUR_ACCESS_TOKEN"

That request asks for a Biology question from UTME 2022.

You don't have to download an entire database simply because a student wants to practise one subject.

Your application requests what it needs.

You can explore the available examinations, subjects and years through the SdashAPI Coverage Page. SdashAPI currently lists UTME coverage spanning 1988–2026, although availability can differ by subject and year. SdashAPI

Fetching JAMB Questions by Subject

Most CBT applications need subject filtering.

If a student chooses Chemistry, you don't want to return random Government or Biology questions.

A request can therefore specify:

subject=chemistry

combined with:

type=utme

For example:

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

You can use the same pattern for other supported subjects.

This makes it possible to create interfaces such as:

Choose a Subject

[ Mathematics ]
[ English Language ]
[ Biology ]
[ Chemistry ]
[ Physics ]
[ Economics ]
[ Government ]

When the student makes a selection, your application sends the appropriate subject parameter.

Fetching JAMB Past Questions by Year

Year filtering is useful when students want to practise a particular examination year.

For example:

type=utme
subject=chemistry
year=2022

Together:

https://sdashapi.com/api/v1/q?type=utme&subject=chemistry&year=2022

Your application could therefore provide:

Practice by Subject

or

Practice by Year

without maintaining separate static files for every combination.

SdashAPI's API reference documents year as one of the supported question filters. SdashAPI

Fetching Multiple Questions for a CBT Session

A real CBT session usually needs more than one question.

SdashAPI supports a limit parameter for retrieving multiple questions in one request.

For example:

GET /api/v1/q?type=utme&subject=biology&limit=20

This can return a batch of questions rather than requiring your application to make twenty separate requests.

The current documentation states that up to 50 questions can be returned in a single request. When limit=1, data is returned as an object; when the limit is greater than one, data becomes an array of question objects. SdashAPI

That distinction is important when writing your frontend logic.

For example:

const questions = response.data;

questions.forEach(question => {
  console.log(question.question);
});

Your CBT application can then move through the array locally as the student clicks Next and Previous.

What Should a Good JAMB Questions API Return?

Getting thousands of questions is useful, but quantity alone shouldn't determine which API you use.

The structure of the data matters.

At minimum, most CBT applications need:

Question

The actual question shown to the student.

Options

The available answer choices.

Correct answer

Required for automatic marking.

Question ID

Useful for bookmarks, reports, progress tracking and preventing unwanted repetition.

Exam year

Useful for year-specific practice.

Exam type

Useful if your application supports multiple examinations.

More advanced applications may also need:

Solutions

Students increasingly expect to understand why an answer is correct.

Passages

Important for comprehension and passage-based questions.

Images and diagrams

Some Mathematics, Physics, Chemistry and other questions cannot be represented properly using text alone.

Topics and subtopics

Useful for features such as:

Practice only Organic Chemistry.

Difficulty

Useful for adaptive practice.

Tags and skills

Useful for analytics and recommendation systems.

This is why developers should inspect the response structure rather than choosing a provider based only on the number of questions advertised.

Basic Questions vs Rich Question Data

Not every application needs the same amount of information.

A simple school CBT system might need only:

Question
Options
Answer
Solution

An adaptive learning platform might need:

Question
Options
Answer
Solution
Topic
Subtopic
Difficulty
Skill
Tags
Passage
Detailed explanation

SdashAPI handles this through different API versions.

V1 provides the core question structure.

Higher versions add additional metadata and explanation information. For example, the documentation describes V2 as adding metadata such as topic, subtopic, difficulty, skill and tags, while V3 adds a more detailed explanation block. SdashAPI

That lets developers choose the amount of data their product actually needs instead of making every application process the same large payload.

Example: Building a Simple JAMB CBT Application

Suppose you're building a mobile application where students can practise 20 Biology questions.

The student opens the application and selects:

Exam: UTME
Subject: Biology
Questions: 20

Your backend requests:

/api/v1/q?type=utme&subject=biology&limit=20

The returned questions are stored temporarily for that examination session.

Your application displays:

Question 1 of 20

[Question]

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

Previous             Next

When the student selects an option, you save the choice locally.

For example:

answers[question.id] = "b";

When the examination ends, compare the student's selections with the answer field.

let score = 0;

questions.forEach((question) => {
  if (answers[question.id] === question.answer) {
    score++;
  }
});

Then display:

Score: 16/20
Percentage: 80%

Notice what happened.

SdashAPI handled the question data.

Your application handled the CBT experience.

That separation is useful because you remain in control of your product.

Should You Call the API Directly From Your Mobile App?

For prototypes, developers sometimes call APIs directly from the frontend.

For production applications, you should think carefully about API-key security.

A better architecture for many applications is:

Mobile/Web App
      ↓
Your Backend
      ↓
SdashAPI
      ↓
Your Backend
      ↓
Mobile/Web App

Your API credentials remain on your server rather than being unnecessarily exposed inside client-side code.

SdashAPI's documentation recommends sending the AccessToken through the HTTP header for production use rather than placing the token in the URL. SdashAPI

JAMB API and Offline CBT Apps

An API normally requires an internet connection when data is being requested.

That doesn't necessarily mean every screen of your application must continuously request questions.

One possible architecture is:

API
 ↓
Your Backend
 ↓
Approved Cache / Database
 ↓
Student's CBT Session

For applications that require significant offline access or permanent local datasets, however, API access and bulk-data licensing are different requirements.

SdashAPI's coverage information notes that bulk datasets are available separately for teams that need offline datasets in formats such as JSON, CSV or SQL. SdashAPI

If your application needs permanent offline storage or large-scale data access, discuss your intended architecture through the SdashAPI Contact Page rather than assuming ordinary API access automatically grants every type of data-storage right.

Testing Before Launching Your CBT App

Another mistake is paying for large infrastructure before knowing whether your application will actually work with it.

During development, you need to test things like:

• Authentication
• Question fetching
• Subject filters
• Year filters
• Loading states
• Error handling
• Answer selection
• Scoring
• Explanations
• Images
• Network failures
• Empty responses

SdashAPI allows developers to create an account and obtain an access token so they can begin testing the integration. Its current homepage states that developers can sign up without a card to get started. SdashAPI

Once you've confirmed that your application works correctly, you can choose the production arrangement that fits your expected usage through the SdashAPI Pricing Page.

Error Handling Matters

Your application should never assume every API request succeeds.

For example, you may encounter:

400 — Invalid request
401 — Invalid or missing authentication
404 — No matching questions
429 — Quota exceeded

These should produce useful messages inside your application.

Instead of showing:

Undefined is not an object

show something meaningful:

We couldn't load questions right now. Please try again.

Or, if there are no questions matching the selected combination:

No questions are currently available for this subject and year. Choose another year.

The SdashAPI documentation publishes its response and error-code structure so developers can build handling for these cases. SdashAPI

Don't Make One Request for Every Question

Suppose your examination contains 40 questions.

Avoid doing this unnecessarily:

Request question 1
Request question 2
Request question 3
...
Request question 40

Batching is usually cleaner.

For example:

/api/v1/q?type=utme&subject=biology&limit=40

You retrieve the examination data and let the student navigate through it locally.

This reduces unnecessary network activity and can produce a smoother CBT experience.

SdashAPI specifically recommends batching questions rather than making a separate API request for every question. SdashAPI

Can You Use a JAMB Past Questions API With React Native, Flutter or a Website?

Yes.

A REST API isn't tied to one frontend framework.

You can integrate it into applications built with technologies such as:

• React
• React Native
• Flutter
• Next.js
• Vue
• PHP
• Laravel
• Node.js
• Python
• Java
• C#
• Native Android

What matters is that your application can make HTTP requests and process JSON.

SdashAPI also currently documents JavaScript/TypeScript and Python SDKs alongside normal REST access. SdashAPI

API vs Buying a Complete JAMB Question Bank

Neither approach is automatically right for every project.

An API is useful when you want managed access to questions without maintaining the entire underlying dataset yourself.

A bulk dataset can make more sense when your architecture requires permanent local storage, extensive offline access or direct database ownership under an appropriate licence.

Think about the difference as:

API
You request the data your application needs.

Bulk Dataset
You receive licensed data and manage the infrastructure yourself.

If you're still developing your first version, API access is often easier to test because you don't have to import and maintain a large database before your product is working.

For large projects that specifically need bulk data, SdashAPI provides a contact route for discussing those requirements through SdashAPI Contact.

Check Coverage Before Designing Your Product

Don't assume every subject has exactly the same number of questions in every year.

Before advertising something like:

Every JAMB subject from every year

verify the actual available coverage.

SdashAPI maintains a dedicated Exam Data Coverage Page showing the examinations, years and other coverage information currently available. SdashAPI

Your application should also be designed gracefully for combinations where no matching question exists.

Reporting Incorrect Questions

Question quality matters just as much as API reliability.

A wrong answer in a normal application is a bug.

A wrong answer in an educational application can teach somebody the wrong thing.

Your system should therefore retain question IDs so users can report problematic questions.

For example:

Report Question #4821

instead of:

The Chemistry question I saw yesterday was wrong.

Unique IDs make issues much easier to trace.

SdashAPI's documented SDK includes a question-reporting function, and developers can also use the SdashAPI Community and Contact Page when they need help with an integration or dataset issue. SdashAPI

Is SdashAPI an Official JAMB API?

No.

SdashAPI should be understood as an independent educational API infrastructure for developers. It is not JAMB's official API.

That distinction is important when describing your application to users.

Your application can use UTME/JAMB past-question data for educational and practice functionality without presenting SdashAPI as JAMB itself.

When Does a JAMB Past Questions API Make Sense?

A JAMB questions API is particularly useful if you're building:

• JAMB CBT practice apps
• UTME mock examination platforms
• School CBT systems
• Exam preparation websites
• AI tutoring applications
• Student revision platforms
• Learning management systems
• Performance-analysis tools
• Quiz applications
• Admission preparation platforms

The question bank becomes one component of the product rather than the entire product.

Your differentiation can then come from the experience you build around it.

Getting Started With a JAMB Past Questions API

A sensible development process is:

1. Create your account
2. Generate an API key
3. Make a test request
4. Fetch one UTME question
5. Add subject filtering
6. Add year filtering
7. Test multiple questions
8. Build your CBT interface
9. Add scoring and explanations
10. Handle errors and empty results
11. Separate development and production configuration
12. Launch

You don't need to import thousands of questions before building your first screen.

Start by proving that one question can successfully travel from the API into your interface.

Then build outward.

You can start from the SdashAPI Website, inspect current availability on the Coverage Page, compare options on the Pricing Page, or use the SdashAPI Community if you want to discuss an implementation with other developers.

A JAMB past questions API doesn't build your CBT application for you. What it does is remove one substantial infrastructure problem: getting structured examination questions into your software in a form your code can work with.

That leaves you to focus on the part that makes your product yours: the interface, learning experience, analytics, accessibility, performance and features you build around the questions.