WAEC past questions API

Developers building WAEC/WASSCE preparation apps, CBT platforms, school examination software or EdTech products eventually face an important question: how do you get WAEC past questions into your application in a structured format that your software can actually use?

PDF past questions can be useful for students who simply want to read or print questions. They are much less convenient when you're building software.

Your application needs data it can understand.

It may need the question, options, correct answer, explanation, examination year, subject, passage, images and other information as individual fields.

This is where a WAEC past questions API becomes useful.

Instead of manually copying thousands of questions into your database, your application can request WASSCE question data programmatically and receive structured JSON that can be displayed, processed and incorporated into your own user experience.

Developers can use SdashAPI to work with structured WASSCE examination data alongside other supported examinations.

What is a WAEC past questions API?

A WAEC past questions API is an interface through which your application can request WASSCE question data.

Imagine you're developing an examination practice platform.

A student selects:

Examination: WASSCE
Subject: Biology
Year: 2023

Your application sends those requirements to the API.

The API returns questions matching the request.

Instead of receiving a PDF page, your application receives structured information that may look conceptually like this:

{
  "id": 57281,
  "question": "Which of the following is responsible for...",
  "option": {
    "a": "Option A",
    "b": "Option B",
    "c": "Option C",
    "d": "Option D"
  },
  "answer": "b",
  "solution": "The correct answer is B because...",
  "examtype": "WASSCE",
  "examyear": "2023",
  "image": null
}

Your application determines what happens next.

You could display it as a normal practice question, put it inside a timed examination, generate a mock test, create a revision session or use the information for learning analytics.

The API provides the data.

Your software provides the experience.

Why developers need structured WAEC questions

Consider what happens when you're building a serious WASSCE preparation platform.

You might need thousands of questions covering different subjects and years.

Every question potentially needs:

• Question text
• Answer options
• Correct answer
• Explanation
• Examination year
• Subject
• Unique identifier
• Passage
• Image or diagram
• Topic information
• Difficulty information

If you obtain the questions as PDFs, your application cannot simply treat the PDF as a database.

Someone has to extract the questions.

Someone has to separate the options.

Someone has to identify the answers.

Someone has to connect passages to their questions.

Images must be handled separately.

The resulting information then has to be converted into a consistent structure.

Doing this for a few hundred questions is one thing.

Doing it across multiple WASSCE subjects and years becomes a separate data-engineering project.

A WAEC past questions API allows the development team to spend more time building the actual product.

WAEC and WASSCE terminology

There is an important distinction developers should understand.

WAEC is the West African Examinations Council, while WASSCE refers to the West African Senior School Certificate Examination.

This matters when designing your database and API requests.

Users commonly search for phrases such as:

WAEC past questions

while structured examination data may identify the examination as:

WASSCE

If your application supports multiple examinations, it is better to maintain consistent internal identifiers while still displaying terminology that students understand.

For example:

Display name: WAEC/WASSCE
Internal type: wassce

That prevents inconsistencies later.

WAEC is not only relevant to Nigeria

This is another important consideration when developing a WASSCE application.

WAEC operates across multiple West African countries, and examination requirements and question coverage can differ.

A developer building only for Nigerian students may not notice this immediately.

But suppose your platform eventually expands to Ghana.

You may now need to distinguish between questions relevant to different countries or examination contexts.

A scalable architecture could therefore support something similar to:

Exam: WASSCE
Country: Ghana
Subject: Mathematics
Year: 2024

rather than assuming every WAEC question belongs to one universal pool.

SdashAPI's current documentation includes country filtering for WASSCE and identifies supported country values for Nigeria, Ghana, Sierra Leone, Liberia and The Gambia.

Developers planning a regional product can check the currently available examination data through the SdashAPI Coverage Page.

How a WAEC past questions API fits into an application

A simple architecture could look like this:

Student
   ↓
Your CBT App
   ↓
Your Backend
   ↓
Question API
   ↓
Structured WASSCE Data
   ↓
Your Application

Suppose the student selects Mathematics.

Your application could request Mathematics questions.

If the student selects a particular year, you add the year filter.

If your product supports country-specific WASSCE data, the relevant country can also become part of the request.

Your frontend doesn't need to know how the entire question database is maintained.

It only needs a predictable response.

Example: Building a WAEC Biology practice session

Imagine you're creating a web application where students practise 30 Biology questions.

The student chooses:

WAEC/WASSCE

Biology

2023

30 Questions

Your backend requests the appropriate questions.

The response contains an array.

Conceptually:

{
  "status": "success",
  "data": [
    {
      "id": 101,
      "question": "Question one...",
      "option": {
        "a": "Option A",
        "b": "Option B",
        "c": "Option C",
        "d": "Option D"
      },
      "answer": "a"
    },
    {
      "id": 102,
      "question": "Question two...",
      "option": {
        "a": "Option A",
        "b": "Option B",
        "c": "Option C",
        "d": "Option D"
      },
      "answer": "c"
    }
  ]
}

Your application stores the session questions temporarily.

The student begins the test.

Your interface could display:

BIOLOGY

Question 7 of 30

[Question text]

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

Previous                 Next

Time Remaining: 21:43

Nothing about the API dictates how this page should look.

That remains your responsibility as the developer.

The question API should not become your entire application

This distinction matters.

Using a WAEC past questions API doesn't mean you're simply reselling an API.

Your application can still contain features such as:

• Student accounts
• Timed examinations
• Practice mode
• Mock examinations
• Performance analytics
• Topic recommendations
• Bookmarks
• Revision history
• Leaderboards
• Teacher dashboards
• School accounts
• Subscription systems
• Offline sessions
• AI tutoring
• Weak-topic detection
• Progress tracking

The API simply supplies one important component: examination data.

Your product determines what is done with that information.

Answers alone are not always enough

A basic CBT application can work with:

Question
Options
Correct Answer

But educational applications increasingly need more.

Suppose a student selects the wrong answer.

Showing:

Incorrect. Correct answer: C.

is useful for scoring, but it doesn't necessarily help the student understand the topic.

A better learning experience might show:

Correct answer: C.

followed by an explanation of the underlying concept.

That means developers should consider whether their WAEC question source includes explanations and solutions.

For a learning application, the difference between an answer database and an explanation database can become significant.

Passages need special handling

Some examination questions depend on passages.

Consider a comprehension section where questions 1–5 refer to the same passage.

Your data architecture should preserve that relationship.

A poor implementation might repeat the entire passage five times.

A better system might store:

{
  "passage": "Passage text...",
  "questions": [
    {},
    {},
    {},
    {},
    {}
  ]
}

or attach a passage identifier to each related question.

Whichever architecture you use, your application should know that those questions are connected.

This is one reason developers should inspect the structure of an API before integrating it deeply into their product.

Images and diagrams matter

Not every WASSCE question can be represented correctly with plain text.

Subjects such as:

• Mathematics
• Physics
• Chemistry
• Biology
• Geography
• Technical subjects

can contain diagrams, graphs, tables, illustrations or other visual information.

Suppose the original question says:

Study the diagram above and answer the question.

If your database contains only that sentence and the diagram is missing, the question is effectively unusable.

When evaluating a WAEC past questions API, developers should therefore ask:

Does the question contain an image field?

How are image URLs returned?

Are diagrams connected to the correct question?

What happens when no image exists?

A clean API might return:

{
  "question": "Study the diagram and identify X.",
  "image": "https://example.com/question-image.jpg"
}

and use:

"image": null

when the question doesn't require one.

Your frontend can then conditionally display the image.

Your application should support long questions

Another mistake is designing the CBT interface using only short dummy questions.

During development you might test with:

What is photosynthesis?

Then real examination data arrives containing a long passage or detailed scenario.

Suddenly the layout breaks.

Buttons move outside the screen.

The timer overlaps the question.

Options become difficult to read.

A real WAEC practice application should therefore be tested with:

• Short questions
• Long questions
• Long options
• Passages
• Images
• Mathematical expressions
• Questions with four options
• Questions with different content structures

Realistic testing matters.

Fetch only the data you need

Suppose your application needs 20 Chemistry questions.

You generally don't need to download every WASSCE question in your system before starting the test.

Request the appropriate batch.

For example, the logical request might contain:

exam = wassce
subject = chemistry
limit = 20

Your backend receives the questions and starts the examination session.

This is much more manageable than transferring an entire question database for every student session.

Use batching

Avoid making unnecessary requests.

If a student needs 40 questions, requesting one question forty times creates additional network overhead.

A better pattern is:

Request 40 questions
       ↓
Receive question array
       ↓
Start examination
       ↓
Navigate locally

Your application can then handle Next and Previous navigation without making another network request every time the student changes questions.

The exact batch limits depend on the API version and provider, so developers should check the current documentation before implementation.

Separate your API layer from your user interface

Avoid writing your entire application around one specific response object.

Instead of scattering API calls throughout your components, create a service layer.

For example:

async function getWassceQuestions({
  subject,
  year,
  country,
  limit
}) {
  // Request questions from your backend/API service.
}

Your interface can then call:

const questions = await getWassceQuestions({
  subject: "biology",
  year: 2023,
  country: "nigeria",
  limit: 30
});

This gives you cleaner code.

If your backend implementation changes later, you don't have to rewrite every examination screen.

Keep API credentials away from public frontend code

This is particularly important for web and mobile applications.

Avoid exposing production API credentials unnecessarily inside:

• Public JavaScript
• GitHub repositories
• Mobile source code
• Client-side environment files
• Browser requests

A safer production architecture is often:

Student App
     ↓
Your Backend
     ↓
SdashAPI

Your backend authenticates the user, requests the necessary examination data and sends only the required response to the frontend.

That gives you more control over your credentials and usage.

Development should come before production spending

You shouldn't need to buy a huge question database just to find out whether your application architecture works.

During development, your priorities are different.

You need to determine whether you can:

• Authenticate successfully
• Request WASSCE questions
• Parse the JSON
• Display options correctly
• Handle passages
• Render images
• Record answers
• Calculate scores
• Display explanations
• Handle API errors

SdashAPI provides 2,000 free credits that developers can use while testing their integration.

Those 2,000 credits are useful because they allow you to develop against actual structured data instead of creating hundreds of dummy questions.

Your development flow can therefore be:

Create account
      ↓
Receive 2,000 free credits
      ↓
Generate development API key
      ↓
Build integration
      ↓
Test WASSCE questions
      ↓
Complete application
      ↓
Generate production API key
      ↓
Choose production plan

The point of the 2,000 free credits isn't to operate a large production platform indefinitely.

They're there to give you room to build and understand the API before committing your application to production.

Developers can begin from the SdashAPI Website.

Development and production keys should be separate

Once your application is ready for actual students, consider creating a new API key for production rather than continuing to use the same key you used throughout development.

For example:

Development

Local App
   ↓
Development API Key
   ↓
SdashAPI

and:

Production

Live Application
   ↓
Your Backend
   ↓
Production API Key
   ↓
SdashAPI

This makes access easier to manage.

If a development key is accidentally exposed, it can be revoked without necessarily disrupting your live application.

What happens after the free testing stage?

Once development is complete, you need to estimate actual usage.

Ask:

How many students will use the application?

How many questions will each student answer?

How often will they practise?

Will you cache permitted responses?

How many examinations will you support?

Are you launching publicly or with a small group?

Your answers should determine the plan you choose.

SdashAPI provides different options for different usage requirements. Developers can review the current plans and limits on the SdashAPI Pricing Page.

If you're launching gradually, a smaller or Pay As You Go arrangement may make more sense than immediately purchasing capacity intended for a much larger platform.

API access vs bulk WAEC question database

These are different requirements.

An API is suitable when your application requests data from an external service.

A bulk dataset is different.

With a bulk dataset, you may receive question data that you host and manage yourself under the relevant licensing terms.

For example:

API MODEL

Application
   ↓
API request
   ↓
Question provider
   ↓
Response

versus:

BULK DATA MODEL

Licensed Dataset
   ↓
Your Database
   ↓
Your Backend
   ↓
Your Application

Neither model is universally better.

If you're developing a normal online examination app, API access may be considerably easier.

If you're building something that requires extensive offline operation or your own permanent database infrastructure, bulk licensing may be worth discussing.

For requirements that go beyond standard API access, use the SdashAPI Contact Page.

Think beyond Nigeria when designing your database

If your product may eventually serve West Africa, don't hard-code everything around Nigeria.

Instead of:

{
  "exam": "waec"
}

consider an architecture capable of supporting:

{
  "exam": "wassce",
  "country": "ghana"
}

or:

{
  "exam": "wassce",
  "country": "sierra-leone"
}

even if you initially launch in one country.

That decision can save significant restructuring later.

The SdashAPI Coverage Page can be used to check currently available examination, country, subject and year coverage before you advertise a particular combination to your users.

Don't assume every year contains the same number of questions

Historical examination data isn't always perfectly symmetrical.

You might have:

Biology 2021 → X questions
Biology 2022 → Y questions
Biology 2023 → Z questions

Your application should handle this gracefully.

Don't write code that assumes every request must return exactly 50 questions.

If only 37 matching questions are available, decide how your application should respond.

You might:

• Reduce the session size
• Notify the student
• Include another year
• Ask the student to select a different year

Good software anticipates imperfect data conditions.

Add proper loading and error states

Your application shouldn't freeze while waiting for questions.

Display something meaningful:

Preparing your WASSCE Biology practice...

If the request fails:

We couldn't load the questions. Check your connection and try again.

If the requested combination doesn't exist:

We couldn't find questions matching this subject and year.

If authentication fails:

The examination service is temporarily unavailable.

The exact wording depends on your product, but the important point is that raw server errors should not become the student's user experience.

Store question IDs

Every question should have a reliable identifier.

This becomes useful for:

Reporting

A student can report Question #57281.

Bookmarks

The student can save a question.

Analytics

You can determine which questions students frequently fail.

Revision

You can create a “Questions I Got Wrong” feature.

Duplicate control

You can reduce unnecessary repetition.

Support

A developer can identify the exact problematic record instead of trying to locate it manually.

This small implementation detail becomes extremely valuable as your platform grows.

Question quality still needs feedback

No historical examination database should be treated as something that can never contain an issue.

Questions can have formatting problems.

An option can be incomplete.

An image can fail.

An explanation can need correction.

A mature educational platform should therefore have a reporting mechanism.

For example:

Was something wrong with this question?

[ Report Question ]

Then send the question ID and issue category.

SdashAPI users who encounter data or integration issues can use the SdashAPI Community or reach the team through the SdashAPI Contact Page.

WAEC past questions API for school CBT systems

The same infrastructure can also be useful for schools.

A school might want teachers to create mock examinations using historical WASSCE-style material.

The workflow could be:

Teacher Dashboard
      ↓
Select Subject
      ↓
Select Year(s)
      ↓
Choose Questions
      ↓
Create Mock Exam
      ↓
Students Write CBT
      ↓
Automatic Marking
      ↓
Results Dashboard

The school doesn't necessarily need to manually type every question into its CBT software.

The API becomes a data source while the school's software handles students, classes, examinations and results.

WAEC past questions API for AI learning applications

Structured question data can also be useful when building AI-assisted educational products.

For example, your application could identify the topic of questions a student repeatedly misses and use that information to recommend revision material.

A possible flow:

Student answers question incorrectly
        ↓
Application records topic
        ↓
Several mistakes occur in same topic
        ↓
System detects weakness
        ↓
Student receives targeted practice

Rich metadata such as topic, subtopic and difficulty can make features like this easier to implement.

This is why the structure and depth of the question data matter just as much as the raw number of questions.

Choosing a WAEC past questions API

Before integrating any provider into a production application, check:

Coverage

Does it contain the subjects, countries and years you need?

Structure

Is the JSON predictable?

Answers

Are correct answers included?

Explanations

Does your learning product require them?

Passages

Are comprehension questions properly connected?

Images

Are diagrams and illustrations supported?

Filtering

Can you request specific subjects and years?

Authentication

Can credentials be protected properly?

Error handling

Are response codes documented?

Usage limits

Can your application operate within the available quota?

Licensing

Does your intended commercial use fit the terms?

Support

Can you report technical or question-data problems?

These questions are more important than simply asking which provider advertises the largest number.

Is SdashAPI an official WAEC API?

No.

SdashAPI is an independent examination-data API for developers. It should not be presented as an official API operated by the West African Examinations Council.

If your application uses SdashAPI data, your branding should make that distinction clear.

Likewise, developers should avoid designing an independent preparation application in a way that could make students believe it is an official WAEC product when it is not.

A sensible way to start

If you're currently building a WAEC or WASSCE application, don't begin by trying to solve every possible problem.

Start small.

1. Create an account

2. Generate a development API key

3. Use the 2,000 free credits for testing

4. Fetch one WASSCE question

5. Display it correctly

6. Add answer options

7. Add scoring

8. Fetch multiple questions

9. Add subject filtering

10. Add year filtering

11. Add country filtering if required

12. Test passages and images

13. Add proper error handling

14. Complete your CBT interface

15. Create a production API key

16. Select an appropriate production plan

17. Launch

That gives you a working foundation before you begin adding more complicated features.

You can start through the SdashAPI Website, check available examination data through SdashAPI Coverage, compare production options on the SdashAPI Pricing Page, discuss implementation questions in the SdashAPI Developer Community, or contact the team through SdashAPI Support.

A WAEC past questions API ultimately solves one specific but substantial problem: turning examination questions into structured data that software can work with.

Once that layer is handled, you can spend more of your development time building the things students actually interact with: the CBT interface, revision experience, analytics, recommendations, performance tracking and other features that make your EdTech product useful.