Past questions database Nigeria

A past questions database in Nigeria is the structured data behind many CBT apps, exam-practice websites, school portals and revision platforms.

Instead of storing examination material as PDFs or Word documents, a proper database separates every question into fields your software can understand:

Exam
Subject
Year
Question
Options
Correct answer
Solution
Image
Question ID

This makes it possible to search, filter, mark answers automatically and generate complete practice sessions.

For developers who don't want to build this database manually, SdashAPI provides structured Nigerian examination data through a REST API, covering UTME, WASSCE, NECO and Post-UTME. SdashAPI

PDF collection vs a real question database

A folder containing:

JAMB Mathematics 2022.pdf
JAMB Mathematics 2023.pdf
WAEC Biology 2021.pdf
NECO Chemistry 2020.pdf

is a collection of past questions.

It isn't yet a useful software database.

If you want to build a CBT app from those files, you still have to extract every question, identify its options, determine the answer, preserve diagrams and passages, assign the correct year and subject, and store everything consistently.

A database instead lets your software ask:

Give me:
Exam = UTME
Subject = Physics
Year = 2019
Number of questions = 40

and receive structured records.

That difference becomes huge once you're dealing with tens of thousands of questions.

What should the database structure look like?

At a basic level, one record might contain:

{
  "id": 4821,
  "question": "Which of the following is the chemical formula for table salt?",
  "option": {
    "a": "NaCl",
    "b": "KCl",
    "c": "CaCO3",
    "d": "NaOH"
  },
  "answer": "a",
  "solution": "NaCl is sodium chloride...",
  "image": null,
  "examtype": "UTME",
  "examyear": "2022"
}

This follows the actual structure documented by SdashAPI V1 rather than a hypothetical schema. SdashAPI

Once questions are structured like this, you can build automatic marking, bookmarks, revision history, random tests and analytics around them.

One database can cover several Nigerian examinations

A useful Nigerian question database shouldn't put everything into one undifferentiated table.

At minimum, distinguish between:

UTME
WASSCE
NECO
Post-UTME

SdashAPI currently supports all four categories. Its filtering documentation uses the API slugs:

utme
wassce
neco
post-utme
``` :chatgpt-content-reference{index="3"}


This allows one application to offer:

```text
Choose Examination

JAMB / UTME
WAEC / WASSCE
NECO
Post-UTME

without maintaining four completely different question engines.

How large can this become?

Quite large.

The current SdashAPI coverage page reports 368,868+ available questions, 26 subjects overall and an overall year range of 1988–2026. SdashAPI

Its current breakdown is:

Examination	Subjects	Overall years	Explanations
UTME	22	1988–2026	82%
WASSCE	23	1988–2026	74%
NECO	25	1988–2026	67%
Post-UTME	19	2000–2026	100%

These are platform-wide coverage figures. They should not be interpreted as a guarantee that every subject has questions for every year in the stated range. SdashAPI

That distinction matters when you're building filters for real users.

You don't necessarily need to own the database

There are two common architectures.

The first is to maintain everything yourself:

Your App
   ↓
Your Backend
   ↓
Your PostgreSQL / MySQL Database
   ↓
Hundreds of thousands of questions

That gives you direct database control, but you're also responsible for collecting, structuring, correcting and updating the content.

The alternative is:

Your App
   ↓
Your Backend
   ↓
Exam Question API

With SdashAPI, for example, the current question endpoint is:

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

and requests are authenticated with:

AccessToken: YOUR_ACCESS_TOKEN
``` :chatgpt-content-reference{index="7"}


Your own database can then concentrate on your users:

```text
users
attempts
scores
subscriptions
bookmarks
progress

while the external API handles the question bank.

Fetch questions by exam, subject and year

A real documented SdashAPI request is:

GET https://sdashapi.com/api/v1/q?subject=chemistry&type=utme&year=2022
AccessToken: YOUR_ACCESS_TOKEN
``` :chatgpt-content-reference{index="8"}


For a 40-question Physics session, the documentation gives:

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

SdashAPI supports batches of up to 50 questions per request. SdashAPI

That means a developer can create:

UTME Physics 2019 Practice

without manually creating a separate JSON file called physics-2019.json.

Don't hard-code subjects and years

Suppose your frontend contains:

const subjects = [
  "Mathematics",
  "English",
  "Physics",
  "Chemistry"
];

It works until your database changes.

SdashAPI provides a subject discovery endpoint:

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

which returns the human-readable subject name and its API slug. The documentation specifically recommends using the returned slug when making question requests. SdashAPI

There is also:

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

and:

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

for discovering available years and examination types. SdashAPI

That gives you a more maintainable flow:

Fetch Exams
    ↓
Fetch Subjects
    ↓
Fetch Years
    ↓
Student Makes Selection
    ↓
Fetch Questions

API database vs full offline database

This is an important choice.

An API is useful when your application can communicate with a server:

Mobile App
   ↓
Backend
   ↓
SdashAPI

But perhaps you're building CBT software for a secondary school with 200 computers and unreliable internet.

Then you may prefer:

Local Server
   ↓
Local Question Database
   ↓
200 CBT Computers

SdashAPI currently offers bulk dataset licensing for teams that need the complete dataset offline, including formats such as JSON, CSV and SQL. SdashAPI

So "I need a past questions API" and "I need a complete past questions database" are related requests, but they're not necessarily the same technical requirement.

A hybrid approach can work too

You don't always have to choose 100% API or 100% local database.

Historical exam data is particularly suitable for caching because old questions generally don't need to be downloaded repeatedly.

SdashAPI's current developer guide recommends caching previously retrieved question sets and demonstrates both browser storage and server-side Redis approaches. SdashAPI

You could therefore use:

Student requests UTME Physics 2019
              ↓
        Check your cache
          ↙       ↘
       Found      Missing
         ↓           ↓
      Return      SdashAPI
                     ↓
                   Cache
                     ↓
                   Return

That can improve speed and reduce unnecessary API usage.

The database becomes more valuable when you add student data

The questions themselves are only half of an exam-preparation product.

Imagine storing:

Question ID: 4821

Attempt 1: Wrong
Attempt 2: Wrong
Attempt 3: Correct

Now your app knows something about the student's learning history.

Across hundreds of attempts, you can build:

Your Performance

Mathematics       71%
English           83%
Physics           54%
Chemistry         68%

Needs attention:
Physics

Unique question IDs also make it easier to build bookmarks, avoid unwanted repetition, review previous attempts and report problematic questions. SdashAPI explicitly lists these as uses for its question identifiers. SdashAPI

What about images and explanations?

A serious Nigerian past-questions database needs to account for more than text.

Mathematics and science questions may contain diagrams. English questions can depend on passages. Students may also need solutions after attempting a question.

SdashAPI's current coverage page reports image availability across UTME, WASSCE, NECO and Post-UTME, while its core API schema includes image and solution fields. SdashAPI

That means your frontend should be designed for optional content:

if (question.image) {
  // render the question image
}

if (question.solution) {
  // make solution available during review
}

Don't design your entire CBT interface around the assumption that every question is four short lines of plain text.

You can test before buying a large database

If you're still prototyping, buying hundreds of thousands of records immediately may be unnecessary.

SdashAPI currently offers a Sandbox with 2,000 credits so developers can test the integration and build features such as subject filtering, year filtering, answer checking, question navigation and scoring before moving to production access. SdashAPI

That makes a sensible development sequence:

Build prototype
      ↓
Test real questions
      ↓
Validate your CBT flow
      ↓
Choose API or bulk dataset
      ↓
Launch
      ↓
Scale

What should you look for in a Nigerian past questions database?

The number of questions matters, but it isn't the only thing worth checking.

A useful database should have consistent exam and subject labels, stable question IDs, correct option structures, year information, answers, solutions where available, image support and predictable machine-readable output.

You should also check whether the provider supports the examinations you actually need rather than buying a giant "Nigerian questions database" and discovering that half of your product requirements aren't covered.

For developers who need an API rather than maintaining everything themselves, SdashAPI documentation shows the current REST endpoints and response structure, while SdashAPI Coverage shows the current exam, subject and year coverage. SdashAPI

A good past questions database in Nigeria is ultimately not just a pile of old questions. It is structured educational data that your software can search, filter, mark, analyse and turn into a useful learning experience.