SdashAPI Logo SdashAPI
Get API Key
Back to Blog

WAEC API Liberia

October 02, 2026 30 views

If you're searching for a WAEC API Liberia, the technical requirement is usually straightforward: your application needs WASSCE questions associated with Liberia in a format your code can use.

That could be for a CBT app, school practice portal, mock-exam platform, revision website or an AI-assisted learning product.

SdashAPI currently includes Liberia in its multi-country WASSCE infrastructure and identifies the country using LR. SdashAPI

WAEC or WASSCE?

These terms are often mixed together in searches, but they're not exactly the same thing.

WAEC is the West African Examinations Council.

WASSCE is the West African Senior School Certificate Examination.

So someone may Google "WAEC API Liberia", while the actual API request should identify the examination as:

wassce

SdashAPI handles it this way too. Its country information associates Liberia with both familiar identifiers, while WASSCE questions are requested using type=wassce. SdashAPI

Liberia has its own country identifier

SdashAPI currently defines Liberia as:

{
  "code": "LR",
  "name": "Liberia",
  "exams": ["waec", "wassce"]
}

You can retrieve the supported countries from:

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

The current list also contains Nigeria, Ghana, Sierra Leone and The Gambia. SdashAPI

That gives a Liberia-focused application a useful structure:

Liberia (LR)
     ↓
WASSCE
     ↓
Subject
     ↓
Year
     ↓
Questions

Check Liberia's available data first

One particularly useful part of the current SdashAPI structure is that you don't have to guess what is available for Liberia.

You can request Liberia's examinations:

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

Subjects:

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

And years:

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

These country-specific routes are documented by SdashAPI. SdashAPI

This is better than hard-coding something like:

const years = [
  2026, 2025, 2024, 2023, 2022,
  2021, 2020, 2019, 2018
];

because a general WASSCE year being present does not automatically prove that your chosen Liberia subject/year combination contains questions.

Fetching Liberia WASSCE questions

For country filtering, the current SdashAPI documentation points developers to V4.

The documented pattern is:

GET /api/v4/q?type=wassce&country=COUNTRY_CODE&subject=SUBJECT
AccessToken: YOUR_ACCESS_TOKEN

For Liberia Mathematics:

curl -X GET \
  "https://sdashapi.com/api/v4/q?type=wassce&country=LR&subject=mathematics" \
  -H "AccessToken: YOUR_ACCESS_TOKEN"

Here:

type=wassce

chooses WASSCE,

country=LR

identifies Liberia, and

subject=mathematics

selects Mathematics. SdashAPI

That's the current documented SdashAPI structure rather than a guessed API example.

Adding a year

Past-question applications normally need more than country and subject.

Suppose the student chooses:

Liberia → WASSCE → Chemistry → 2022

SdashAPI documents year as a question filter and recommends combining filters when building CBT applications rather than querying broad datasets unnecessarily. SdashAPI

Your application can construct the request programmatically:

const params = new URLSearchParams({
  type: "wassce",
  country: "LR",
  subject: "chemistry",
  year: "2022"
});

const response = await fetch(
  `https://sdashapi.com/api/v4/q?${params.toString()}`,
  {
    headers: {
      AccessToken: process.env.SDASH_API_KEY
    }
  }
);

const result = await response.json();

The access token should normally remain on your server rather than being exposed inside public client-side code.

Why structured data beats manually collecting PDFs

Imagine you're building this:

WASSCE Liberia

Mathematics
English Language
Biology
Chemistry
Physics
...

A student selects a subject and starts a 40-question practice session.

If your source is a PDF, your software doesn't naturally know:

Where does Question 1 start?
Which text belongs to Option A?
What's the correct answer?
Which year is this?
Does this question have an image?
What's the explanation?

You have to extract and structure all of that yourself.

SdashAPI already returns machine-readable JSON. Its core question schema includes fields such as question ID, question text, options, answer, solution, image, examination type and examination year. SdashAPI

That's the part an API actually saves developers from doing.

Don't build another PDF reader

Once you have structured questions, there's no reason to limit your product to:

Question → Answer → Next Question

You could create a proper practice system:

WASSCE Liberia
      ↓
Choose Subject
      ↓
Choose Year
      ↓
Practice
      ↓
Submit
      ↓
Score
      ↓
Review Mistakes

You could also add a mock mode where answers and solutions remain hidden until submission.

Or build a revision page:

Your Mathematics Performance

Attempt 1     51%
Attempt 2     58%
Attempt 3     69%
Attempt 4     76%

Questions answered: 160
Questions missed: 43

The API doesn't need to build those features for you.

It supplies the examination data. Your application supplies the learning experience.

A useful detail for CBT developers: up to 50 questions per request

The current SdashAPI documentation allows the limit parameter to request multiple questions, with a maximum of 50 questions per request.

It also notes an implementation detail worth knowing:

  • limit=1 returns data as an object.
  • limit>1 returns data as an array. SdashAPI

That's important when writing your parser.

For example, your application shouldn't blindly assume:

result.data.map(...)

will always work if some requests ask for only one question.

Use subject slugs, not whatever text appears on your button

Another small thing that prevents frustrating bugs: SdashAPI distinguishes the display name from the API slug.

For example, the API may provide:

{
  "name": "Computer Studies",
  "slug": "computer"
}

Your interface displays:

Computer Studies

but your API request uses:

subject=computer

The current SdashAPI subject guide specifically recommends using the returned slug rather than constructing API values from human-readable names yourself. SdashAPI

That's why dynamically retrieving subjects is preferable to maintaining your own list.

What happens when Liberia data isn't available?

This deserves more attention than it usually gets.

Imagine someone chooses:

Liberia
WASSCE
Some Subject
Some Year

and there are no matching questions.

That's not necessarily an application failure.

SdashAPI currently documents 404 for cases where no questions match the supplied filters. SdashAPI

Your app should turn that into something useful:

No questions are currently available for this subject and year. Please choose another year.

Not:

404 NOT FOUND

Likewise, 401 indicates a missing or invalid access token, while 429 relates to quota usage. SdashAPI

Those errors belong in your application's error-handling logic, not on a student's screen.

How broad is the current WASSCE database?

The SdashAPI Coverage page currently reports 368,868+ questions across the platform.

For WASSCE, it currently lists:

23 subjects
Overall year range: 1988–2026
Explanations: 74%
Images: available
API versions: V1, V2, V3 and V4

Liberia (LR) is explicitly listed as available for country-filtered WASSCE data. SdashAPI

One distinction is important: these are overall WASSCE coverage figures, not a promise that every Liberia subject contains every year between 1988 and 2026.

Use the Liberia-specific subject and year endpoints to determine what your application should actually advertise.

API or complete Liberia question database?

They solve slightly different problems.

If you're building an internet-connected product, this may be enough:

App
 ↓
Your Backend
 ↓
SdashAPI
 ↓
WASSCE Data

But perhaps you're developing CBT software for a school where dozens of computers need to take an exam over a local network even when the internet is unavailable.

Then you may want:

Local School Network
        ↓
Local CBT Server
        ↓
Your Own Question Database

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

That's a separate requirement from ordinary API access and should be planned accordingly.

Liberia today, West Africa tomorrow

One reason country-aware architecture is worth doing properly is expansion.

You might launch only for Liberia:

LR → WASSCE

but your internal model could already support:

Country
   ↓
Exam
   ↓
Subject
   ↓
Year
   ↓
Questions

SdashAPI's current WASSCE country infrastructure includes:

NG → Nigeria
GH → Ghana
SL → Sierra Leone
LR → Liberia
GM → The Gambia
``` :chatgpt-content-reference{index="13"}


So you don't necessarily need five completely different codebases to build five country experiences.

The branding, curriculum decisions and student experience may differ by market, but your underlying question-data architecture can remain consistent.

## Where SdashAPI fits

SdashAPI isn't WAEC and shouldn't be presented as an official WAEC service. It is an independent examination-data API for developers.

Its role is narrower and pretty practical:

```text
You build:
• the app
• the CBT engine
• the timer
• student accounts
• results
• analytics
• revision features

SdashAPI provides:
• structured examination questions
• options
• answers
• solutions
• metadata
• country-aware WASSCE access

That's the useful division of responsibility.

Developers can start from the SdashAPI Documentation, verify the available Liberia data through SdashAPI Coverage, and then build the student experience around the actual data returned by the API.

A WAEC API Liberia becomes valuable when it saves you from spending months building and cleaning the question-data layer before you can even find out whether students want the product.

Avatar

How can we help?

We reply immediately

Hello! 👋 How can we help you today?
Powered by SdashAPI