WAEC CBT API

A WAEC CBT API provides developers with structured WASSCE examination data that can be used to build computer-based testing applications, mock examination platforms, school CBT systems and other EdTech products.

This is becoming increasingly relevant as examination preparation moves beyond PDFs and printed past-question booklets toward interactive digital experiences.

If you are building a WAEC/WASSCE CBT application, the visible examination interface is only part of the project. Behind that interface, your software needs a reliable source of questions, options, answers, explanations, passages, images and other examination information.

You can build and maintain that entire database yourself, purchase a licensed dataset where appropriate, or connect your software to an examination-data API.

SdashAPI provides an API approach, allowing developers to work with structured examination data while keeping control of the actual application they are building.

What is a WAEC CBT API?

A WAEC CBT API is an application programming interface through which software can request WASSCE examination data.

Suppose a student opens your application and chooses:

Examination: WASSCE
Subject: Mathematics
Year: 2024
Questions: 40

Your application needs to turn those selections into an actual examination.

A question API can receive the requirements and return matching data in a structured format.

For example:

{
  "id": 76128,
  "question": "Evaluate the expression...",
  "option": {
    "a": "12",
    "b": "15",
    "c": "18",
    "d": "21"
  },
  "answer": "b",
  "solution": "The expression can be simplified by...",
  "examtype": "WASSCE",
  "examyear": "2024",
  "image": null
}

Your application then determines how that information is presented.

The API supplies the examination data.

Your software supplies the CBT experience.

WAEC and WASSCE are not exactly the same term

This distinction is worth understanding when designing your application.

WAEC is the West African Examinations Council.

WASSCE is the West African Senior School Certificate Examination.

Students commonly say things such as:

I am preparing for WAEC.

So displaying WAEC in your user interface may make sense.

Internally, however, your application may identify the examination as:

wassce

A clean implementation could therefore use:

{
  "display_name": "WAEC/WASSCE",
  "exam_type": "wassce"
}

This becomes particularly useful if your platform eventually supports multiple examinations.

Why would a CBT application need an API?

Imagine you're developing a complete examination application.

You already need to build:

Authentication
Student profiles
Dashboard
Subject selection
Exam interface
Timer
Question navigation
Answer selection
Submission
Scoring
Results
Analytics
Subscriptions

Now add question management.

You also need:

Thousands of questions
Options
Answers
Explanations
Years
Subjects
Passages
Images
Diagrams
Topics
Question IDs
Corrections

Maintaining both systems can become a substantial workload.

A WAEC CBT API separates the question-data layer from your application's business logic.

Your development team can concentrate on building the product while requesting the examination information it needs from an existing data service.

A simple WAEC CBT architecture

A production application might use an architecture similar to:

Student
   ↓
Web/Mobile CBT Application
   ↓
Your Backend
   ↓
SdashAPI
   ↓
WASSCE Question Data
   ↓
Your Backend
   ↓
Student Application

This architecture also means your production API credentials don't necessarily need to be exposed directly to the student's device.

Your backend becomes the layer between your application and the examination-data service.

Building a WASSCE CBT session

Suppose a student wants a 50-question Economics practice examination.

Your application collects:

Exam: WASSCE
Subject: Economics
Questions: 50
Mode: Mock Examination

Your backend requests the appropriate data.

After receiving the questions, create a session.

For example:

const session = {
    questions: questions,
    currentQuestion: 0,
    answers: {},
    flagged: [],
    remainingTime: 3600
};

The student sees:

WASSCE ECONOMICS

Question 1 of 50

[Question]

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

Previous                    Next

Time Remaining: 59:43

When an option is selected:

session.answers[question.id] = "c";

The student's answer remains associated with that question.

When the examination ends, your system can calculate the result.

Prepare questions before starting the examination

Network conditions should not unnecessarily reduce a student's examination time.

Avoid:

Start Timer
    ↓
Request Question 1
    ↓
Wait for server

Instead:

Student taps Start
       ↓
Prepare examination
       ↓
Retrieve question batch
       ↓
Validate questions
       ↓
Create session
       ↓
Display first question
       ↓
Start timer

This small architectural decision creates a much better user experience.

Fetch questions in batches

A CBT session normally contains several questions.

If you need 40 questions, repeatedly making a new request whenever the student presses Next is usually unnecessary.

A better approach is:

Request 40 questions
        ↓
Receive 40-question batch
        ↓
Create CBT session
        ↓
Navigate locally

Now the student can move:

Question 1
↓
Question 2
↓
Question 3
↓
Question 4

without waiting for another API request every time.

It also makes your application more resilient when internet connectivity becomes unstable during a session.

Temporary internet problems should not automatically end an exam

Internet connectivity can fluctuate.

If your architecture requires an active API request for every question, a temporary network interruption can make your application frustrating to use.

Preparing the examination session beforehand can help.

For example:

Internet available
       ↓
Questions loaded
       ↓
Examination starts
       ↓
Connection temporarily drops
       ↓
Student continues loaded session
       ↓
Connection returns
       ↓
Progress synchronises

How much data you may cache and for how long depends on your API agreement and implementation.

Temporary examination-session storage is also different from permanently copying an entire question database.

For applications requiring extensive offline data, discuss the requirement through SdashAPI Contact.

A WAEC CBT API can support more than one mode

You don't have to build only one examination experience.

The same underlying question data can support several modes.

Practice Mode

A student answers a question.

Immediately show:

Correct Answer: B

Explanation:
...

Mock Examination

Questions are timed.

Answers and explanations remain hidden until submission.

Topic Practice

The student chooses a particular area.

Mathematics

Algebra
Geometry
Statistics
Trigonometry

Past Question Mode

The student chooses an examination year.

Select Year

2024
2023
2022
2021
...

Revision Mode

Show questions previously answered incorrectly.

These modes don't necessarily require different question databases.

Your application logic determines how the same structured data is used.

Explanations can turn a CBT app into a learning app

Suppose a student gets a question wrong.

A basic application shows:

Incorrect.

Correct Answer: C

A more educational application can show:

Incorrect.

Your Answer: A

Correct Answer: C

Explanation:
[Explanation of the concept]

This matters because students aren't using an examination-preparation application only to discover their score.

They are also trying to improve it.

If your product is designed around learning rather than only testing, examine the explanation data available from whichever API you integrate.

Question metadata can power better features

Imagine every question contains information such as:

{
  "topic": "Algebra",
  "subtopic": "Quadratic Equations",
  "difficulty": "medium",
  "skill": "problem-solving"
}

Your application can do considerably more with this than simply display a question.

After several sessions, you could generate:

MATHEMATICS PERFORMANCE

Algebra                 81%
Geometry                64%
Statistics              73%
Trigonometry            42%

Now the student knows where improvement is needed.

Your application could recommend:

Your lowest-performing area is Trigonometry. Try a focused practice session.

Structured metadata turns examination history into useful learning information.

Images and diagrams must be handled correctly

WASSCE questions can contain visual material.

Depending on the subject, you may encounter:

Graphs
Tables
Maps
Diagrams
Scientific illustrations
Geometrical figures
Charts

If a question says:

Study the diagram above...

and your application doesn't display the diagram, the question becomes useless.

Your question component should therefore support optional image information.

For example:

if (question.image) {
    displayQuestionImage(question.image);
}

Your UI should also be tested with large images.

A diagram that looks fine on a desktop monitor may require resizing or zoom functionality on a small phone.

Consider image zoom

For detailed diagrams, a student may need to inspect an image closely.

A useful mobile interaction could be:

[Question Diagram]

Tap to enlarge

Then:

Full-screen image

[ Zoom ]
[ Pan ]
[ Close ]

This can be especially useful for graphs, maps and scientific diagrams.

Passages need a good mobile experience

Some questions depend on passages.

A desktop interface might comfortably display:

Passage | Question

Side by side.

That may not work on a small smartphone.

Alternative designs include:

[ VIEW PASSAGE ]

Question 4 of 7

...

or an expandable passage above the question.

The important thing is that students should not lose access to the passage when moving between related questions.

WASSCE is a West African examination

A WAEC CBT product doesn't necessarily have to remain Nigeria-only.

Developers planning regional products should think about country support early.

Your database architecture might need:

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

rather than assuming:

{
  "exam": "waec"
}

automatically means Nigeria.

This matters if you eventually want to support students in countries such as Ghana, Sierra Leone, Liberia or The Gambia.

You can review currently available data through the SdashAPI Coverage Page.

Design your application for country filtering

A regional application could ask:

Choose Your Country

Nigeria
Ghana
Sierra Leone
Liberia
The Gambia

Then:

Choose Examination

WASSCE

Then:

Choose Subject

This creates an architecture that can expand without forcing you to redesign your entire question system later.

Don't assume questions are identical across countries

Supporting WASSCE across West Africa doesn't mean every question, subject configuration or historical record should automatically be treated as identical.

Your application should respect the country metadata supplied with the examination data.

If a student selects Ghana, request or display data appropriate to the supported Ghanaian collection rather than simply mixing every WASSCE record together.

This is particularly important for products that want to position themselves as regional EdTech platforms.

Using SdashAPI for WAEC CBT development

SdashAPI provides structured examination data that developers can use while building CBT and educational applications.

Instead of beginning development by purchasing and importing a huge question database, you can first test the integration.

The development process can look like:

Create account
       ↓
Generate API key
       ↓
Connect application
       ↓
Request WASSCE data
       ↓
Build CBT interface
       ↓
Test
       ↓
Move to production

You can begin from the SdashAPI Website.

Start with 2,000 free credits

SdashAPI provides 2,000 free credits for developers to test while building.

This means you can start working on your WAEC CBT integration before choosing a paid production plan.

Use the 2,000 free credits to test things such as:

Fetching questions
Subject filters
Year filters
Country filters
Question rendering
Options
Answers
Explanations
Images
Passages
Error handling

The idea isn't that 2,000 credits will operate a large public CBT platform forever.

They provide room to build and test the integration before committing to production infrastructure.

Use real data while designing the interface

This is one of the most useful things you can do with your development credits.

Don't test only with:

What is 2 + 2?

Real examination questions can be much more complicated.

Use the testing stage to see how your interface handles:

Long questions
Long answer options
Passages
Images
Diagrams
Mathematical expressions
Different subjects
Different years

Problems discovered during development are much cheaper to fix than problems discovered after thousands of students install the application.

Keep development and production API keys separate

During development:

Development App
      ↓
Development API Key
      ↓
SdashAPI

When you're ready to launch:

Live Application
      ↓
Your Backend
      ↓
Production API Key
      ↓
SdashAPI

This gives you cleaner credential management.

You can revoke or replace a development key without unnecessarily affecting the production application.

Protect the production API key

Avoid publishing production credentials in public source code.

For example, don't commit secrets to a public GitHub repository.

A better production setup is usually:

Frontend
   ↓
Your Backend
   ↓
SdashAPI

Your backend holds the API credential.

This also allows your server to decide whether a user is authorised to make a request.

For example:

if (!user.subscriptionActive) {
    return subscriptionRequired();
}

Only authorised requests continue to the question service.

Build your own usage controls

Your application may have completely different pricing from the API underneath it.

For example:

FREE USER

10 questions daily
1 mock exam weekly
Basic results

and:

PREMIUM USER

Unlimited practice
Mock examinations
Detailed explanations
Analytics
Weak-topic reports

SdashAPI doesn't need to manage those product decisions.

Your backend controls your customers.

The examination API remains an infrastructure component.

Calculate expected usage before production

Suppose you expect:

2,000 students

× 30 questions

× 5 sessions each month

That gives:

300,000 question interactions

This doesn't automatically mean your API usage will equal exactly that number because architecture, caching rules and plan structure can affect consumption.

But the calculation gives you an idea of your product's scale.

You can then compare current production options through the SdashAPI Pricing Page.

Start according to your actual size

A common startup mistake is designing infrastructure around the company you hope to become instead of the product you currently have.

If you are launching with 100 students, you don't necessarily need infrastructure intended for one million students on day one.

Start with realistic capacity.

Monitor:

Active users
Questions requested
Sessions per student
Peak usage
Failed requests
Response times

Then increase capacity as the application grows.

SdashAPI also provides Pay As You Go options for projects where that model fits the expected usage.

API or bulk question database?

A WAEC CBT API isn't the only way to obtain examination data.

Some applications genuinely need a licensed bulk dataset.

The distinction is:

API

Your App
   ↓
Your Backend
   ↓
SdashAPI
   ↓
Requested Data

versus:

BULK DATA

Licensed Dataset
   ↓
Your Own Database
   ↓
Your Backend
   ↓
Your App

Bulk data may make sense if your application requires extensive offline availability or another architecture where you need to host the dataset yourself.

API access can be simpler when you don't want the responsibility of maintaining the complete examination database.

If you're unsure which architecture fits your project, describe the requirements through SdashAPI Contact.

Offline CBT requires planning

An offline CBT application is not simply an online application with the internet turned off.

You need to think about:

Question storage
Images
Student answers
Timers
Session recovery
Result calculation
Synchronisation
Updates
Security

If you need an examination to continue through temporary connectivity problems, preparing the current session locally may be sufficient.

If you want thousands of questions permanently available without internet access, that's a different architecture and may require an appropriate bulk-data arrangement.

Plan this before development becomes too advanced.

Save answers as students progress

Don't wait until the final Submit button to remember every answer.

A student might:

Close the app accidentally

Refresh the browser

Lose power

Experience an app crash

You can periodically save progress.

For example:

{
  "session_id": "WASSCE-MATH-8201",
  "current_question": 27,
  "answers": {
    "76128": "b",
    "76129": "d"
  },
  "remaining_time": 1120
}

If your application allows session recovery, this information can be used to restore progress.

Add proper submission confirmation

Students can accidentally tap Submit.

Before ending a timed examination, show something useful:

You are about to submit your examination.

Answered: 43
Unanswered: 7
Flagged: 4

Are you sure you want to submit?

[ CONTINUE EXAM ]   [ SUBMIT ]

This reduces accidental submissions.

Results should be useful

A final score is important, but it doesn't have to be the end of the experience.

Instead of:

32/50

consider:

Score: 32/50
Percentage: 64%

Correct: 32
Incorrect: 18

Strongest Topic:
Demand and Supply

Needs Improvement:
National Income

Then provide:

[ Review Answers ]

[ Practise Weak Topics ]

[ Try Another Mock Exam ]

This gives students a reason to continue using the application.

Build a revision system around incorrect answers

Every incorrect answer is useful learning information.

Store the question ID.

Then create:

REVISION

Questions I Got Wrong

Bookmarked Questions

Weak Topics

Previous Exams

A student who repeatedly gets the same topic wrong can be directed toward focused practice.

This is where your CBT application starts becoming a learning platform rather than simply a digital examination paper.

Question reporting should be built in

No large historical question database should be treated as incapable of containing an error.

Your application should provide a simple reporting mechanism.

For example:

Report this question

Reason:

○ Incorrect answer
○ Missing diagram
○ Incomplete question
○ Formatting issue
○ Explanation issue
○ Other

Automatically include the question ID.

This makes investigation much easier.

SdashAPI developers can also use the SdashAPI Community to discuss implementation and data issues or use SdashAPI Contact when direct assistance is needed.

Check coverage before advertising subjects and years

Don't assume every subject contains exactly the same years or number of questions.

Before displaying a subject/year combination to users, verify that the necessary data exists.

The SdashAPI Coverage Page can be used to review available examination data.

A good application can also dynamically hide unavailable combinations rather than allowing the student to select something that will fail.

Is SdashAPI an official WAEC API?

No.

SdashAPI is an independent examination-data platform for developers.

It is not an official API operated by the West African Examinations Council.

Developers using examination data should make their own application's independent status clear as well.

A preparation application should not create the impression that it is an official WAEC application when it isn't.

What should you check before choosing a WAEC CBT API?

The number of available questions matters, but it shouldn't be your only consideration.

Look at:

Coverage: Are the countries, subjects and years your application needs available?

Question structure: Is the returned data consistent?

Answers: Can examinations be marked automatically?

Explanations: Can students learn from incorrect answers?

Passages: Are passage-based questions represented properly?

Images: Can diagrams and visual questions be displayed?

Metadata: Are topics and difficulty available if your application needs them?

Batching: Can you retrieve examination sessions efficiently?

Authentication: Can credentials be protected?

Documentation: Can your developers understand the integration?

Pricing: Does it make sense at your expected scale?

Licensing: Does it fit your intended use?

Support: Is there somewhere to report technical or question issues?

Then test the API inside your own product before making a larger commitment.

From your first request to a working WAEC CBT app

A practical development path could be:

1. Design your CBT interface

2. Create your SdashAPI account

3. Receive 2,000 free testing credits

4. Generate a development API key

5. Fetch your first WASSCE question

6. Display the question and options

7. Record answer selections

8. Fetch multiple questions

9. Add Previous and Next navigation

10. Add the examination timer

11. Add question navigation

12. Add flag-for-review

13. Add scoring

14. Add explanations

15. Add subject filtering

16. Add year filtering

17. Add country support where required

18. Test passages

19. Test diagrams and images

20. Add network-error handling

21. Add session recovery

22. Add results and revision

23. Test with real users

24. Generate a production API key

25. Choose a production plan

26. Launch

You can start through the SdashAPI Website, review currently available examination data on SdashAPI Coverage, compare plans through SdashAPI Pricing, ask questions through the SdashAPI Community, or discuss a particular project through SdashAPI Contact.

A WAEC CBT API is ultimately infrastructure. It gives your application structured examination data, but it doesn't decide what kind of product you build.

The quality of the final application still depends on what you do around that data: the interface, reliability, explanations, analytics, accessibility, revision tools and overall experience you provide to students.