Question API with difficulty level

A question API with difficulty level allows developers to retrieve questions based not only on examination, subject or year, but also on how easy or difficult each question is.

This becomes useful when building adaptive learning systems, topic practice, mock examinations and personalised revision features.

Instead of giving every student the same random questions, your application can create sessions such as:

Biology Practice

Easy:   10 questions
Medium: 20 questions
Hard:   10 questions

For developers building UTME, WASSCE, NECO and Post-UTME applications, SdashAPI provides richer question metadata through its higher API versions.

Difficulty is question metadata

A basic examination question might contain:

{
  "question": "Which organelle is responsible for photosynthesis?",
  "option": {
    "a": "Nucleus",
    "b": "Chloroplast",
    "c": "Ribosome",
    "d": "Mitochondrion"
  },
  "answer": "b"
}

For a more advanced learning application, you may also need metadata describing the question:

{
  "metadata": {
    "topic": "Cell Biology",
    "subtopic": "Cell Organelles",
    "difficulty": "easy",
    "type": "MCQ",
    "skill": "Recall"
  }
}

This additional information makes it possible to organise questions intelligently instead of treating the entire question bank as one large collection.

SdashAPI V4 and difficulty metadata

According to the current SdashAPI Documentation, V4 is the richer question-data version and includes metadata fields for questions.

The endpoint follows this structure:

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

Authentication uses the documented AccessToken header:

curl -X GET "https://sdashapi.com/api/v4/q?subject=biology&type=utme&year=2024" \
  -H "AccessToken: YOUR_ACCESS_TOKEN"

V4 can provide richer information around the returned question, including metadata such as topic, subtopic and difficulty where that metadata is available.

This is more suitable for advanced EdTech features than relying only on the question and correct answer.

Why difficulty levels are useful

Suppose you're building a JAMB preparation app.

A new student might begin with easier questions:

UTME Biology
Difficulty: Easy
Questions: 20

As their performance improves, your system can introduce more difficult questions:

Easy
  ↓
Medium
  ↓
Hard

You can also deliberately mix them.

For example:

40-Question Practice Session

10 Easy
20 Medium
10 Hard

Your application controls this logic using the metadata returned with the question data.

Build adaptive practice

Difficulty metadata becomes especially useful when combined with student performance.

Imagine a student completes:

Cell Biology

Easy Questions:    9/10
Medium Questions:  7/10
Hard Questions:    2/10

Your application can conclude that the student understands the fundamentals but needs more challenging practice.

The next session might therefore contain:

5 Easy
10 Medium
15 Hard

This is a much more useful learning experience than continuously serving completely random questions.

Combine difficulty with topics

Difficulty becomes even more powerful when combined with topic information.

For example:

Subject: Mathematics
Topic: Algebra
Difficulty: Hard

or:

Subject: Biology
Topic: Genetics
Difficulty: Medium

Your interface could allow students to choose:

Choose Topic

Genetics
Ecology
Cell Biology
Evolution

Choose Difficulty

Easy
Medium
Hard

The application then builds the appropriate practice session from the available question metadata.

Use difficulty for mock examination balancing

Difficulty levels can also help you create more balanced mock examinations.

Instead of selecting 40 completely random questions, your backend can aim for a particular distribution.

For example:

const mockStructure = {
  easy: 10,
  medium: 20,
  hard: 10
};

Your application can then assemble those questions into one session and shuffle their order before the examination begins.

The student simply sees:

Question 1 of 40

They don't necessarily need to know the difficulty assigned to each question.

Don't show difficulty during real mock mode unless necessary

Displaying:

HARD QUESTION

before a student answers can influence how they approach the question.

For practice mode, showing difficulty can be useful.

For realistic mock mode, you may want to keep that metadata hidden and use it only internally.

After submission, you could show:

Performance by Difficulty

Easy       90%
Medium     72%
Hard       48%

That provides useful information without affecting the examination itself.

Difficulty should not be your only measurement

A question marked hard is not automatically difficult for every student.

One student may struggle with algebra but perform extremely well in geometry.

That's why a stronger adaptive system combines:

Difficulty
+
Topic
+
Student Accuracy
+
Previous Attempts
+
Time Spent

For example:

Physics

Mechanics
Accuracy: 82%

Electricity
Accuracy: 43%

Your application can recommend more Electricity questions regardless of the student's overall Physics score.

Use stable question IDs for analytics

Save performance against the question ID:

{
  "question_id": 81294,
  "selected_answer": "c",
  "correct": false,
  "time_spent": 52
}

Over time, you can build useful analytics such as:

Student Performance

Easy Questions      86%
Medium Questions    69%
Hard Questions      44%

Weakest Topic:
Organic Chemistry

The question API provides the metadata. Your own application produces the student-level analytics.

A practical architecture

For an adaptive CBT platform:

Student
   ↓
Your App
   ↓
Your Backend
   ↓
SdashAPI V4
   ↓
Question + Metadata

Your backend can then decide which questions should be included in each session.

Keeping this logic on your backend also makes it easier to change your recommendation algorithm later.

Start development with free credits

Developers can start with 2,000 free SdashAPI credits for development and testing.

That gives you room to experiment with real API responses while building features such as:

• Difficulty-based practice
• Topic practice
• Adaptive learning
• Mock examinations
• Performance analytics
• Weak-topic detection
• Question recommendations

Start from SdashAPI and check the SdashAPI Documentation for the latest V4 request parameters and response structure before implementing filters in production.

This is important because having a difficulty field in returned metadata and having a server-side difficulty query parameter are not necessarily the same thing. Your application should only use filters explicitly supported by the current API documentation rather than inventing query parameters.

Moving to production

Once your adaptive question system is working:

Development
     ↓
Test with real question data
     ↓
Validate difficulty/topic logic
     ↓
Create production API key
     ↓
Launch

You can review available examinations through SdashAPI Coverage and production options through SdashAPI Pricing.

A question API with difficulty level becomes particularly valuable when you're building something beyond a basic past-question viewer. With structured metadata, the same question bank can power beginner practice, difficult-question challenges, balanced mock examinations, weak-topic revision and personalised learning experiences.