West African Past Questions API

Building an exam-preparation app for West Africa becomes messy surprisingly quickly if every country and examination gets its own disconnected question database.

You might start with Ghana WASSCE questions. Then you add Sierra Leone. Later, someone asks for Liberia and The Gambia. Before long, your backend has five different structures for essentially the same job.

A West African Past Questions API provides a cleaner approach: one structured data layer that your application can query by examination, country, subject and year.

SdashAPI currently provides structured exam data for UTME, WASSCE, NECO and Post-UTME, with country-aware WASSCE support for five West African countries. SdashAPI

Which West African countries are currently supported?

For WASSCE, SdashAPI currently recognises:

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

The countries endpoint is:

GET https://sdashapi.com/api/countries

The current documentation returns each country with its code and supported examination types. SdashAPI

This matters because WASSCE really is a regional examination. WAEC The Gambia, for example, describes WASSCE as the Council's international examination taken across the five countries operating under the WAEC framework. WAEC Gambia

So instead of designing your database as:

WASSCE
  ↓
Mathematics
  ↓
Questions

a better West African structure is:

Country
   ↓
Exam
   ↓
Subject
   ↓
Year
   ↓
Questions

A single API, different countries

Suppose you're building a WASSCE Mathematics app.

For Ghana, your data request may need:

country=GH

For Sierra Leone:

country=SL

For Liberia:

country=LR

For The Gambia:

country=GM

SdashAPI documents country filtering on its V4 question endpoint. The documented pattern is:

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


The country becomes a parameter rather than requiring a completely separate API.

## Don't assume every country has the same subjects

This is where a West African API needs to be more than a big JSON file.

The countries may share WASSCE, but developers should not assume their exact subject availability is identical.

A current example comes from The Gambia. WAEC The Gambia says 20,610 candidates from 170 senior secondary schools registered for the 2026 school-candidate WASSCE, with candidates registered across 40 subjects. Its current private-candidate offering also publishes its own subject list. :chatgpt-content-reference{index="4"}

Your application should therefore discover what its **data provider** has for a particular country instead of copying one country's subject list into every market.

SdashAPI provides:

```http
GET /api/countries/{code}/subjects

For example:

GET /api/countries/GH/subjects
GET /api/countries/SL/subjects
GET /api/countries/LR/subjects
GET /api/countries/GM/subjects

It also provides country-level exam and year endpoints. SdashAPI

What about Nigerian examinations?

Not everything in a West African exam API needs to be regional.

SdashAPI currently covers:

UTME
WASSCE
NECO
Post-UTME

But its coverage page makes an important distinction: UTME, NECO and Post-UTME are Nigerian examinations in the platform, while WASSCE is the multi-country examination. SdashAPI

So your application might look like:

Choose Country

Nigeria
  ├── UTME
  ├── WASSCE
  ├── NECO
  └── Post-UTME

Ghana
  └── WASSCE

Sierra Leone
  └── WASSCE

Liberia
  └── WASSCE

The Gambia
  └── WASSCE

That's much more accurate than showing "JAMB" to a student in Ghana simply because JAMB exists somewhere in your database.

What does the API return?

SdashAPI serves question data as JSON.

At the core level, its documented question structure contains information such as:

Question ID
Question
Section
Options
Answer
Solution
Image
Exam Type
Exam Year

Its richer API versions add additional educational metadata and explanation data. SdashAPI

That gives developers the raw material for much more than a list of past questions.

Build one CBT engine, not five

Here's where the architecture starts paying off.

You can create one reusable question component:

┌──────────────────────────────┐
│ Question 12 of 40            │
│                              │
│ Question text...             │
│                              │
│ A. ...                       │
│ B. ...                       │
│ C. ...                       │
│ D. ...                       │
│                              │
│ Previous              Next   │
└──────────────────────────────┘

The component doesn't particularly care whether the question came from Ghana or Liberia.

Your backend determines:

country
exam
subject
year

and sends the resulting questions to the same CBT engine.

That allows you to spend more development time on the parts students actually notice: speed, navigation, explanations, scoring and revision.

A real multi-filter request

SdashAPI's documentation recommends combining filters for production CBT applications rather than making unnecessarily broad requests.

Its documented example combines:

subject
type
year
limit

like this:

GET https://sdashapi.com/api/v1/q?subject=physics&type=utme&year=2019&limit=40
``` :chatgpt-content-reference{index="8"}


For multi-country WASSCE applications, V4 adds the country dimension.

So conceptually your application collects:

```text
Country: Ghana
Exam: WASSCE
Subject: Mathematics
Year: selected year

and builds the appropriate request from those selections.

Use the current SdashAPI documentation when constructing the production query because supported parameters and API versions can evolve.

Past questions are only the beginning

A developer could use the same data to create several products.

A year practice mode lets students choose an examination year.

A mock examination selects a batch of questions, starts a timer and hides answers until submission.

A revision mode stores the IDs of incorrectly answered questions.

A weak-topic system uses richer metadata where available to identify concepts a student repeatedly misses.

An AI tutor can use structured examination questions as grounding material rather than relying entirely on generated questions.

SdashAPI's current V4 tooling also includes a similar-question endpoint designed to retrieve related questions from an existing question ID. SdashAPI

That makes a flow like this possible:

Student answers incorrectly
        ↓
Show explanation
        ↓
Find similar questions
        ↓
Practise concept again
        ↓
Measure improvement

That's a considerably more useful learning loop than simply showing "Wrong."

Design for slow connections

A West African EdTech product should also avoid assuming every student has a perfect connection.

Don't design this:

Question 1
   ↓
API request
   ↓
Question 2
   ↓
API request
   ↓
Question 3
   ↓
API request

Fetch a useful batch, prepare the session and let the student move through it without waiting for a network request after every answer.

SdashAPI's current developer guide also discusses caching previously retrieved historical questions using approaches such as browser storage and server-side Redis. SdashAPI

A better experience is:

Fetch
  ↓
Cache
  ↓
Start Session
  ↓
Practice
  ↓
Save Progress
  ↓
Sync

How large is the current database?

SdashAPI's public coverage page currently reports more than 368,868 questions across its exam database.

For WASSCE specifically, it reports:

23 subjects
Overall range: 1988–2026
Explanations: about 74%
Images: available
API versions: V1–V4
``` :chatgpt-content-reference{index="11"}


But there's an important qualification.

Those are overall WASSCE figures.

They should not be interpreted as:

> Every country × every subject × every year is available.

Country-specific subject and year endpoints exist precisely so developers can inspect the available combinations. :chatgpt-content-reference{index="12"}

## API access or a complete offline dataset?

Some developers need an API.

Others need the actual database.

For an online platform:

```text
Student
   ↓
Your App
   ↓
Your Backend
   ↓
SdashAPI

may be enough.

But perhaps you're building CBT software that will run inside schools where hundreds of computers connect to a local server.

Then you might need:

Licensed Dataset
       ↓
School Server
       ↓
Local Database
       ↓
Student Computers

SdashAPI currently advertises bulk dataset licensing in JSON, CSV and SQL for teams requiring complete offline datasets. SdashAPI

That's a different requirement from normal API access, so developers should choose the model that matches how their product will actually work.

You can start with 2,000 free credits

You also don't need to build the entire West African platform on day one.

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

Start with something small:

One Country
    ↓
One Exam
    ↓
One Subject
    ↓
Practice Screen
    ↓
Scoring
    ↓
Review

Get that right.

Then add another subject.

Then another country.

Then mocks, progress tracking, explanations and adaptive practice.

The SdashAPI documentation contains the current endpoints, while SdashAPI Coverage shows the current examinations and country support.

A West African Past Questions API is most useful when it removes the boring infrastructure problem. Developers shouldn't have to rebuild the same question database separately for Nigeria, Ghana, Sierra Leone, Liberia and The Gambia before they can start working on the learning experience students actually use.