WAEC question database JSON

A WAEC question database JSON is useful when you want WASSCE past questions in a format your website, mobile app, CBT software or backend can understand directly.

Instead of keeping questions inside PDFs, JSON turns each question into structured data:

{
  "question": "...",
  "option": {
    "a": "...",
    "b": "...",
    "c": "...",
    "d": "..."
  },
  "answer": "b",
  "solution": "...",
  "examtype": "WASSCE",
  "examyear": "2024"
}

That structure can be rendered in React, React Native, Flutter, PHP, Python or practically any modern development stack.

SdashAPI provides WASSCE past questions as JSON through a REST API, alongside UTME, NECO and Post-UTME data. Its current public coverage lists 23 WASSCE subjects across an overall 1988–2026 range. SdashAPI

WAEC and WASSCE in your database

One detail is worth getting right from the beginning.

WAEC is the examination council. WASSCE is the examination.

Developers and students naturally search for terms like:

WAEC past questions
WAEC questions JSON
WAEC question database

but SdashAPI uses:

type=wassce

when querying the question database. SdashAPI

So your user interface can still say:

WAEC Past Questions

while internally your software requests:

wassce

This keeps the interface familiar without making your data model messy.

What does real WASSCE JSON look like?

The current SdashAPI V1 schema includes:

{
  "status": 200,
  "data": {
    "id": 4821,
    "question": "Question text...",
    "section": null,
    "option": {
      "a": "Option A",
      "b": "Option B",
      "c": "Option C",
      "d": "Option D"
    },
    "answer": "a",
    "solution": "Worked solution...",
    "image": null,
    "examtype": "WASSCE",
    "examyear": "2023",
    "university": null
  }
}

The documented fields include a unique question ID, question text, optional section, options, correct answer, solution, optional image, examination type and year. SdashAPI

That is already enough to build a complete basic CBT system.

Fetch WAEC questions as JSON

The current question endpoint is:

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

Authentication uses the AccessToken header. SdashAPI

For WASSCE Mathematics:

curl "https://sdashapi.com/api/v1/q?subject=mathematics&type=wassce&limit=1" \
  -H "AccessToken: YOUR_ACCESS_TOKEN"

This is the current documented request pattern rather than a made-up endpoint. SdashAPI

You can also combine filters.

For example:

subject=biology
type=wassce
year=2024
limit=40

The API currently supports subject, type, year and limit, with a maximum of 50 questions per request. SdashAPI

Why JSON is better than putting PDFs inside an app

Imagine you've collected 30 WAEC Mathematics PDFs.

They contain plenty of useful questions, but your application cannot automatically understand:

Where does each question begin?

Which text is option A?

Which option is correct?

What year is this question from?

Does the question depend on a passage?

Does it contain an image?

What explanation belongs to it?

You either have to manually structure everything or write extraction software and then verify the results.

With JSON, the application already receives:

question.question
question.option
question.answer
question.solution
question.examyear

That makes features such as automatic marking straightforward.

const isCorrect =
  selectedAnswer === question.answer;

This is why a machine-readable question database is much more useful for EdTech development than simply having a large collection of examination PDFs.

Build a complete WAEC practice session

Suppose a student chooses:

WAEC / WASSCE
Biology
2024
40 Questions

Your backend can request the appropriate question set and pass the returned array to your CBT interface.

The application then handles:

Question 1 of 40

Question text...

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

[Previous]        [Next]

while storing answers against the question's unique ID:

answers[question.id] = selectedOption;

Using the ID rather than the question's array position becomes particularly useful when questions are shuffled.

Your JSON database should support passages too

Not every WAEC question is independent.

Some questions may depend on a common passage or instruction.

SdashAPI V1 includes an optional section field specifically for shared passage or instruction content. SdashAPI

Your interface should therefore be capable of rendering something like:

PASSAGE

Read the following passage and answer
Questions 21–25.

[passage content]

QUESTION 21

...

instead of assuming every question consists only of one sentence and four options.

This matters especially when you're designing an application that will eventually support many subjects.

Images should be part of the data model too

Science and Mathematics questions can depend on diagrams.

SdashAPI includes an optional image field in its V1 schema, and its current coverage page lists images as available for WASSCE. SdashAPI

Your component can simply check:

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

A good CBT interface should also let students enlarge diagrams on smaller screens.

Treat images as first-class question data rather than trying to add them later after the entire interface has been designed around text-only questions.

Don't hard-code all the years

Another advantage of using a structured API is that your year selector can come from the data source.

SdashAPI currently provides:

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

The years endpoint returns available examination years in descending order. SdashAPI

Your frontend can therefore generate:

Choose Year

2026
2025
2024
2023
2022
...

rather than maintaining that list manually.

You can do the same for examination types and subjects using SdashAPI's discovery endpoints. SdashAPI

A WAEC JSON database should be country-aware

This becomes particularly important if your application is meant for more than Nigeria.

WASSCE is supported across:

Nigeria          NG
Ghana            GH
Sierra Leone     SL
Liberia          LR
The Gambia       GM

SdashAPI currently supports country-specific WASSCE filtering for all five. SdashAPI

Country filtering is documented on V4.

For Ghana Mathematics, for example:

GET https://sdashapi.com/api/v4/q?type=wassce&country=GH&subject=mathematics
AccessToken: YOUR_ACCESS_TOKEN
``` :chatgpt-content-reference{index="11"}


That means your database model can eventually become:

```text
Country
   ↓
WASSCE
   ↓
Subject
   ↓
Year
   ↓
Questions

rather than treating every WAEC question as if it belongs to the same country.

API JSON vs downloadable JSON

This is an important distinction.

If you need questions when your application requests them, an API architecture works well:

Your App
   ↓
Your Backend
   ↓
SdashAPI
   ↓
JSON

You don't have to maintain hundreds of thousands of question records yourself.

But perhaps you're building software that must operate completely offline.

Then you may actually be searching for a WAEC JSON dataset, not a WAEC API.

Your architecture becomes:

Licensed WASSCE Dataset
          ↓
JSON Files
          ↓
Your Database
          ↓
Your CBT Software

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

So decide whether you need JSON responses from an API or the underlying bulk JSON dataset.

They solve different problems.

You can also cache JSON you've already fetched

There is a middle ground between those two approaches.

Historical past questions are good candidates for caching.

SdashAPI's current caching guide demonstrates storing previously fetched questions in browser storage and using Redis for server-side caching. SdashAPI

Your backend might work like this:

Request:
WASSCE Biology 2023
        ↓
Check Cache
    ↙       ↘
 Found      Missing
   ↓           ↓
Return      SdashAPI
               ↓
             Cache
               ↓
             Return

This reduces unnecessary requests and can make frequently used question sets load much faster.

How much WASSCE data is currently available?

The current SdashAPI Coverage page reports:

WASSCE

23 subjects
1988–2026 overall range
74% explanations
Images available
V1–V4 support

SdashAPI currently reports more than 368,868 questions across its entire database. SdashAPI

The year range is an overall WASSCE range. It doesn't mean every subject and country contains questions for every single year.

Your application should check availability rather than promising users combinations that don't exist.

Start with JSON before building complicated features

If you're developing a new WAEC practice product, you don't need to begin with AI, leaderboards and adaptive learning.

Get this working first:

Fetch JSON
    ↓
Display Question
    ↓
Display Options
    ↓
Select Answer
    ↓
Next / Previous
    ↓
Submit
    ↓
Calculate Score
    ↓
Review Solutions

SdashAPI currently provides 2,000 free Sandbox credits for development and testing, with V1 access to UTME and WASSCE data. SdashAPI

That gives developers a way to build the first version before deciding whether API access, a production plan or a bulk offline dataset makes the most sense.

A WAEC question database JSON is ultimately valuable because it turns WASSCE past questions into data your software can actually use.

For the live response format and endpoints, use the SdashAPI Documentation. For the current number of questions, subjects, countries and years, check SdashAPI Coverage.