Free JAMB WAEC NECO API for developers

You have an idea for a CBT app.

Maybe it is a JAMB practice app, a WAEC revision platform, a school CBT system or something more ambitious involving several examinations.

Then you reach an annoying problem surprisingly early:

Where do the questions come from?

Paying for a large question database before you've even proved your app works doesn't make much sense. A free exam API can be useful here, not necessarily because your finished product will run free forever, but because it lets you build and test the product before committing money.

SdashAPI currently provides a free developer Sandbox with 2,000 API credits for this purpose. SdashAPI

What is actually free?

This needs to be clear because "free API" can mean almost anything online.

The current SdashAPI Sandbox costs ₦0 and includes:

2,000 API credits
V1 API access
JAMB/UTME data
WAEC/WASSCE data
basic usage analytics
API documentation

It is specifically intended for testing and development, not as an unlimited free production plan. SdashAPI

There is one important limitation: although SdashAPI's wider database includes NECO and Post-UTME, the current free Sandbox lists UTME and WASSCE as its included examination datasets. Broader exam access is available on production plans. SdashAPI

So if you're searching specifically for a completely free production-ready JAMB + WAEC + NECO API, don't confuse the Sandbox with that.

The free access is primarily there so you can build first.

You can make a real API request

This isn't a demo response hard-coded into a documentation page.

After creating an account and getting an access token, the current V1 endpoint is:

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

SdashAPI uses an AccessToken request header rather than the more common Authorization: Bearer format. SdashAPI

For example, a JAMB/UTME Mathematics request is:

curl -X GET \
  "https://sdashapi.com/api/v1/q?type=utme&subject=mathematics" \
  -H "AccessToken: YOUR_API_KEY"

That is the same request pattern used in the current SdashAPI documentation. SdashAPI

For WASSCE Mathematics:

curl -X GET \
  "https://sdashapi.com/api/v1/q?type=wassce&subject=mathematics" \
  -H "AccessToken: YOUR_API_KEY"

And when you have production access that includes NECO, the documented exam type is:

type=neco

SdashAPI's PHP developer guide, for example, demonstrates a NECO Chemistry request using /api/v1/q?type=neco&subject=chemistry. SdashAPI

What comes back?

V1 returns JSON.

A typical question contains the information a basic CBT application needs:

{
  "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
  }
}

Those fields and this example structure come from the current API reference. SdashAPI

That means your application doesn't have to extract:

Question
Options
Answer
Solution
Year
Exam

from a PDF before it can use them.

They're already structured.

2,000 credits can go further than you might think

Here's a useful detail from the current documentation.

For free-tier users, a standard V1 /api/v1/q request currently consumes one credit even when requesting a batch of questions, rather than one credit for every individual question in that batch. SdashAPI allows up to 50 questions in one request. SdashAPI

So instead of doing this:

Request Question 1
Request Question 2
Request Question 3
...
Request Question 40

you can batch:

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

The API documentation specifically uses that combination of filters as an example. SdashAPI

That's a much better way to build a CBT session.

There's another detail to watch:

limit=1

returns data as a JSON object.

But:

limit>1

returns data as an array. SdashAPI

Your code should handle that intentionally.

What can you build with the free credits?

You don't need to finish your entire EdTech startup during the Sandbox stage.

Use it to prove the difficult parts work.

For example:

Create account
      ↓
Get API key
      ↓
Fetch subjects
      ↓
Fetch 20 questions
      ↓
Render CBT interface
      ↓
Store selected answers
      ↓
Add timer
      ↓
Submit
      ↓
Calculate score
      ↓
Show explanations

Once that works, you have something much more valuable than an idea.

You have a working prototype.

The free Sandbox is therefore useful for student developers too. If you're building a final-year project around CBT, quizzes or exam preparation, you can spend your time building the actual software instead of spending days typing hundreds of questions manually.

A small JavaScript implementation

Your server could make a request like:

const params = new URLSearchParams({
  type: "utme",
  subject: "physics",
  year: "2019",
  limit: "40"
});

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

const result = await response.json();

if (!response.ok) {
  throw new Error(result.message || "Unable to fetch questions");
}

return result.data;

One thing worth copying from the documentation is the use of the API key on your backend.

SdashAPI explicitly warns developers not to commit API keys to public repositories or embed them directly in frontend code shipped to users. SdashAPI

So prefer:

React / Flutter / Mobile App
            ↓
       Your Backend
            ↓
         SdashAPI

over putting your production key inside the application bundle.

What about NECO?

This is where accuracy matters.

SdashAPI itself supports NECO. Its API reference lists neco as a valid exam type, and current paid Developer access includes UTME, WASSCE, NECO and Post-UTME. SdashAPI

But the free Sandbox currently lists only UTME and WASSCE.

So a sensible development path is:

FREE SANDBOX

UTME + WASSCE
      ↓
Build the application
      ↓
Test the CBT engine
      ↓
Validate the idea


PRODUCTION

UTME + WASSCE + NECO + Post-UTME
      ↓
depending on chosen production access

That is more useful than advertising "everything is free" and surprising developers later.

Free doesn't mean you should build badly

Even during testing, build your integration like something that could eventually reach production.

Don't request one question every time the student presses Next.

Batch questions.

Don't start the exam timer before your question session is ready.

Don't expose answers unnecessarily during a mock examination.

Don't put your API key in a GitHub repository.

Don't hard-code every subject and year if the API already provides discovery endpoints.

And don't assume every exam/subject/year combination exists. Handle an empty result normally.

SdashAPI currently documents 404 when no questions match a request, 401 for missing or invalid authentication, and 429 for quota-related limits. SdashAPI

Students should see:

We couldn't find questions for this selection. Try another year.

not:

Unhandled Promise Rejection: 404

When should you start paying?

Not when you've written your first line of code.

A more sensible point is when you've established that:

✓ API integration works
✓ CBT interface works
✓ scoring works
✓ questions display correctly
✓ images/passages are handled
✓ users can complete a session
✓ you're ready for actual students

At that point, you can decide whether Pay As You Go or a larger production plan makes sense.

The current SdashAPI pricing page lists the Sandbox alongside Pay As You Go and monthly production options. SdashAPI

The useful meaning of "free exam API"

A free API is most valuable when it reduces the cost of finding out whether your idea is worth pursuing.

You shouldn't have to buy a huge question bank merely to discover that your scoring logic is broken, your interface needs redesigning or nobody wants the product.

With SdashAPI's current free Sandbox, a developer can get 2,000 credits, connect to a real REST API, retrieve structured UTME and WASSCE questions, build the first version of a CBT product and understand how the integration behaves before choosing a production plan. SdashAPI

Start with the SdashAPI documentation, make your first real request, and build the smallest version of the product that proves your idea works.