API for exam preparation app

An API for an exam preparation app should solve one important problem: getting reliable, structured exam content into your application without forcing you to manually build the entire question bank.

If you're creating a JAMB, WAEC, NECO or Post-UTME preparation app, you still need to build the actual student experience:

Registration
Subject selection
Practice mode
Mock exams
Timer
Scoring
Results
Bookmarks
Progress tracking

The API handles a different layer:

Questions
Options
Answers
Solutions
Exam years
Subjects
Images
Educational metadata

For African exam-preparation products, SdashAPI provides a REST API for UTME, WASSCE, NECO and Post-UTME questions with structured JSON responses. SdashAPI

What should an exam preparation API provide?

At minimum, your app needs to be able to request something specific.

For example:

Give me 40 UTME Physics questions from 2019.

A good API should not force you to download thousands of unrelated questions and filter everything yourself.

SdashAPI currently supports filters for examination type, subject, year and number of questions. Its documentation gives this example:

GET https://sdashapi.com/api/v1/q?subject=physics&type=utme&year=2019&limit=40
AccessToken: YOUR_ACCESS_TOKEN

That single request combines all four filters. SdashAPI

This is exactly the sort of query an exam-preparation application needs.

What does the API return?

The current V1 response contains structured question information such as:

{
  "status": 200,
  "data": {
    "id": 4821,
    "question": "Which of the following is the chemical formula for table salt?",
    "section": null,
    "option": {
      "a": "NaCl",
      "b": "KCl",
      "c": "CaCO3",
      "d": "NaOH"
    },
    "answer": "a",
    "solution": "NaCl is sodium chloride...",
    "image": null,
    "examtype": "UTME",
    "examyear": "2022",
    "university": null
  }
}

This is based on the current documented SdashAPI response rather than a custom format invented for this article. SdashAPI

Your application can take those fields and turn them into a normal exam screen:

QUESTION 12 OF 40

Which of the following...?

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

[Previous]                 [Next]

Don't build your app around random questions

A basic quiz app can simply request random questions.

A proper exam-preparation app needs more structure.

Students may want:

Practice Biology
Practice UTME Biology 2024
Practice WASSCE Mathematics
Attempt a 40-question Physics mock
Revise questions from a particular year

SdashAPI currently supports the exam slugs:

utme
wassce
neco
post-utme

and its documentation recommends combining exam, subject and year filters rather than querying a year in isolation. SdashAPI

That gives your app a natural flow:

Choose Exam
     ↓
Choose Subject
     ↓
Choose Year
     ↓
Choose Number of Questions
     ↓
Start Practice

Let the API tell you what subjects exist

Hard-coding every subject into your app can create maintenance problems.

SdashAPI provides:

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

The response contains both a human-readable subject name and its API slug:

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

The documentation recommends displaying name to users while using slug in API requests. SdashAPI

There are also discovery endpoints for years and exam types:

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

GET https://sdashapi.com/api/v1/exams
``` :chatgpt-content-reference{index="6"}


This is better than assuming what data exists.

## Fetch the whole practice session before starting

Don't design a 40-question mock exam like this:

```text
Question 1 → API call
Question 2 → API call
Question 3 → API call
Question 4 → API call
...

That introduces unnecessary latency and makes the student's examination depend on their connection for every question.

SdashAPI supports batches of up to 50 questions in one request. When limit is greater than one, the returned data becomes an array. SdashAPI

So for a 40-question mock:

GET /api/v1/q?subject=physics&type=utme&year=2019&limit=40

Fetch the questions before the timer starts.

Then your app can move between them locally:

Fetch 40 Questions
       ↓
Store Session
       ↓
Start Timer
       ↓
Q1 → Q2 → Q3 → ... → Q40
       ↓
Submit

This also makes temporary network problems less disruptive.

Practice mode and exam mode shouldn't behave the same way

This is an important product decision.

In Practice Mode, students may benefit from immediate feedback:

Choose Answer
     ↓
Correct / Incorrect
     ↓
See Solution
     ↓
Continue

In Mock Exam Mode, that would defeat the purpose.

Use:

Answer Questions
      ↓
Finish Exam
      ↓
Submit
      ↓
Calculate Score
      ↓
Review Answers
      ↓
Read Solutions

Because V1 includes answer and solution, a stricter mock system should avoid exposing those fields unnecessarily to the active exam client. Keep the original response on your backend and send only what the student needs during the test.

Stable question IDs make revision much better

Every SdashAPI question has a unique integer ID, and the current API supports fetching a particular question using:

GET https://sdashapi.com/api/v1/q?id=8931
``` :chatgpt-content-reference{index="8"}


This means your own database can store:

```json
{
  "user_id": "student_72",
  "question_id": 8931,
  "selected_answer": "b",
  "correct": false
}

rather than duplicating the complete question.

That small decision enables features such as:

Questions I Got Wrong
Bookmarks
Attempt History
Retry Incorrect Questions
Performance History

Your question bank becomes connected to the student's learning history.

Your exam app should have its own database too

The question API shouldn't become your entire backend.

A sensible architecture is:

Exam Preparation App
         ↓
      Backend
      ↙     ↘
Your Database    SdashAPI
     ↓               ↓
Users            Questions
Attempts         Options
Scores           Answers
Bookmarks        Solutions
Progress         Exam metadata

This separation means SdashAPI handles examination content while your application controls its users and product logic.

One app can support multiple examinations

SdashAPI's current public coverage reports 368,868+ questions overall and lists: UTME with 22 subjects, WASSCE with 23, NECO with 25 and Post-UTME with 19. SdashAPI

That means you don't necessarily need separate architectures for:

JAMB App
WAEC App
NECO App
Post-UTME App

You can build one exam engine and change the data source parameters:

const params = {
  type: selectedExam,
  subject: selectedSubject,
  year: selectedYear,
  limit: 40
};

The UI remains reusable.

Your first version doesn't need AI

There's a temptation to begin an EdTech project with:

AI Tutor
Adaptive Learning
Predicted Scores
Personalized Study Plans
Smart Recommendations

Those features can be useful, but they're not where a new exam-preparation app needs to begin.

Get this right first:

Fetch Questions
      ↓
Display Correctly
      ↓
Navigate Questions
      ↓
Save Answers
      ↓
Run Timer
      ↓
Submit
      ↓
Calculate Score
      ↓
Review Solutions

SdashAPI currently describes V1 as its lightweight core endpoint and recommends it for timed CBT applications where speed matters. SdashAPI

Once the core experience works, richer educational data can be added later.

API or offline question database?

An API is a good fit for an internet-connected product:

App → Backend → SdashAPI

But it isn't automatically the right architecture for everything.

If you're building CBT software for schools where the examination must continue without internet access, a local database may be more appropriate.

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

So decide early whether you're building:

Online
Offline
or
Hybrid

rather than trying to force every product into the same architecture.

Test the idea before paying for production

A developer shouldn't have to buy a huge question bank just to find out whether their first CBT screen works.

SdashAPI's current free Sandbox provides 2,000 API credits, V1 access and UTME/WASSCE data for development and testing. No card is required for the free plan. SdashAPI

You can use that stage to test:

Question fetching
Subject selection
Year selection
CBT navigation
Answer checking
Scoring
Solutions
Error handling

The current Sandbox is for testing, not unrestricted production use, and it currently lists UTME and WASSCE rather than NECO and Post-UTME. SdashAPI

That's a useful distinction when planning your application.

What should you choose?

If you're looking for an API for an exam preparation app, don't choose based only on who advertises the largest number of questions.

Check whether the API provides the exams you need, structured JSON, subject and year filtering, stable question IDs, answers and solutions, image support, clear documentation, sensible batching and a path from development to production.

For JAMB/UTME, WAEC/WASSCE, NECO and Post-UTME products, SdashAPI documentation shows the current request structure, while SdashAPI Coverage shows the question bank currently available. SdashAPI

The API should handle the exam data. Your job as the developer is to turn that data into a preparation experience students actually want to use.