Exam question bank for developers

An exam question bank for developers is different from a folder of past-question PDFs.

Developers need questions in a format software can actually use: structured JSON with predictable fields for the question, options, answer, solution, exam, year and a stable ID.

For example:

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

This is the current structure documented by SdashAPI for its V1 question API. SdashAPI

Once examination content is structured this way, the same question bank can power a CBT app, quiz website, school portal, revision platform or AI learning tool.

Why developers need a question bank

Suppose you're building a JAMB practice app.

You can build the interface yourself:

Login
↓
Select Subject
↓
Start Exam
↓
Timer
↓
Submit
↓
Result

But you still need the actual examination content.

If you collect PDFs manually, you'll eventually have to convert thousands of questions into structured data, verify answers, preserve images and passages, organize subjects and years, and correct errors.

That's a separate project on its own.

Using a question-bank API allows you to concentrate on the product while retrieving structured examination content when required.

What should a developer-friendly question bank provide?

At minimum, look for:

Unique question ID
Question text
Options
Correct answer
Solution
Subject
Examination
Year
Images where required

More advanced applications may also benefit from topics, subtopics, difficulty information, explanations and related-question features.

The important part is consistency. Your code shouldn't need a different parser for every subject.

One API can support several examinations

SdashAPI currently provides structured data for:

UTME
WASSCE
NECO
Post-UTME

Its current public coverage page reports 368,868+ questions across 26 subjects overall, with coverage spanning 1988–2026 across the database. SdashAPI

The examination-specific coverage currently listed is:

Exam	Subjects	Overall year range
UTME	22	1988–2026
WASSCE	23	1988–2026
NECO	25	1988–2026
Post-UTME	19	2000–2026

These are overall coverage ranges, not a promise that every subject contains questions for every year. SdashAPI

This distinction matters when you're building your year and subject selectors.

Fetch questions instead of manually entering them

The current SdashAPI V1 endpoint is:

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

Authentication uses:

AccessToken: YOUR_ACCESS_TOKEN

A documented request for UTME Chemistry from 2022 is:

GET https://sdashapi.com/api/v1/q?subject=chemistry&type=utme&year=2022
AccessToken: YOUR_ACCESS_TOKEN
``` :chatgpt-content-reference{index="4"}


Your backend receives JSON and can pass the required data to your application.

For example:

```javascript
const response = await fetch(
  "https://sdashapi.com/api/v1/q?subject=physics&type=utme&year=2019&limit=40",
  {
    headers: {
      AccessToken: process.env.SDASH_API_KEY
    }
  }
);

const result = await response.json();
const questions = result.data;

SdashAPI currently supports batches of up to 50 questions per request. Its documentation specifically recommends batching rather than making a separate request for every question. SdashAPI

The question bank shouldn't become your entire backend

An exam API handles educational content.

Your own database should handle your users.

A practical architecture is:

React / Flutter / Mobile App
            ↓
        Your Backend
        ↙          ↘
Your Database      Question API
     ↓                  ↓
Users              Questions
Attempts           Options
Scores             Answers
Bookmarks          Solutions
Subscriptions      Metadata

SdashAPI explicitly describes itself as a headless educational-data API rather than a user-management system. Its CBT documentation recommends pairing it with your own authentication/database solution. SdashAPI

That separation is useful because you can improve your application without having to maintain the underlying exam archive yourself.

Don't expose the API key

A developer-friendly API also needs to fit into a secure architecture.

Avoid:

React Native App
      ↓
Production API key
      ↓
Question API

For production, prefer:

React Native App
      ↓
Your Backend
      ↓
Question API

Keep the API key in an environment variable on your server.

SdashAPI's current authentication documentation warns developers not to expose keys in frontend code, compiled mobile applications or public repositories. SdashAPI

Different apps need different levels of question data

A timed CBT simulator doesn't necessarily need AI features.

It needs speed and predictable data:

Question
Options
Answer
Solution

SdashAPI currently describes V1 as its lightweight core question endpoint and specifically recommends it for timed CBT-style applications. SdashAPI

A learning platform may need more.

The current version structure progresses from basic question data toward richer educational metadata and intelligence features. SdashAPI

So don't automatically request the richest possible response.

Use the version that matches what the current screen needs.

A mock exam and an AI study assistant have very different requirements.

Stable IDs unlock better features

Every question in the current SdashAPI database has a unique integer ID.

A particular question can be retrieved using:

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


That makes features such as these much easier:

```text
Bookmark Question
Save for Later
Questions I Got Wrong
Attempt History
Report Question
Share Question

Instead of saving the complete question repeatedly, your database can associate student activity with its question ID.

For example:

{
  "user_id": "user_382",
  "question_id": 8931,
  "selected_answer": "c",
  "correct": false
}

That's much cleaner than copying the entire question object into every student attempt.

Think about caching early

Past examination questions are unusually cache-friendly because historical questions don't need to change every few seconds.

SdashAPI's current caching documentation recommends caching previously fetched question sets and demonstrates both client-side storage and server-side Redis. SdashAPI

A production system could use:

Request UTME Physics 2019
          ↓
      Check Cache
       ↙      ↘
    Found     Missing
      ↓          ↓
   Return     SdashAPI
                 ↓
               Cache
                 ↓
               Return

That can improve loading speed while reducing repeated API usage.

For CBT applications, SdashAPI also recommends fetching the examination questions before the test starts so the active session can continue even if the student's connection briefly drops. SdashAPI

API question bank vs buying the complete dataset

Developers should also decide whether they actually need an API.

An API makes sense when you want:

Your Application
       ↓
Your Backend
       ↓
Question API

You fetch what you need without maintaining the entire question archive.

But a school CBT system running entirely on a local network may need:

Local Server
     ↓
Local Question Database
     ↓
Student Computers

In that case, an offline dataset can be more appropriate.

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

So "exam question bank API" and "exam question bank dataset" shouldn't automatically be treated as the same product.

What if you need question search?

This is another area worth planning before choosing your architecture.

SdashAPI's current V1 endpoint is optimized around filtering by metadata such as exam, subject and year. It does not currently expose a normal full-text keyword search parameter. SdashAPI

If full-text search is central to your application, the current developer guide suggests storing/caching question data in your own PostgreSQL or MongoDB database and using native database indexing. SdashAPI

That's a good example of why an API doesn't need to solve every part of your product.

Use the API for the question infrastructure, then build specialized product features on top of it.

Test your app before committing heavily

For a prototype, you don't necessarily need to buy a huge question dataset immediately.

The current SdashAPI pricing page lists a free Sandbox with:

2,000 API credits
V1 access
UTME data
WASSCE data
Basic usage analytics
API documentation

The Sandbox is intended for development and testing. SdashAPI

That gives you enough room to test important things first:

Can my app fetch questions?

Does the CBT interface work?

Does scoring work?

Do images display correctly?

Does the timer work?

Can users review answers?

Does caching work?

Once the product itself works, you can decide what production access makes sense.

The question bank is infrastructure, not the product

Two developers can use the same examination data and build completely different products.

One might build a traditional CBT simulator.

Another might build:

Daily Practice
Weak Topic Detection
Study Streaks
Questions I Got Wrong
Detailed Explanations
Personalized Revision

A third might build a school examination platform.

That's why a good exam question bank for developers should stay focused on providing clean, predictable educational data rather than trying to dictate the entire application.

SdashAPI documentation provides the current REST endpoints, authentication method and response structure, while SdashAPI Coverage shows the examinations, subjects, years and countries currently available. SdashAPI

The question bank supplies the content. What you build around that content is where your actual product begins.