I Built a Free English Dictionary API Using Wiktionary Data extract

I wanted to build something useful for developers: a free English dictionary API that anyone could integrate into their applications without worrying about API keys, registration, or complicated onboarding.

That idea eventually turned into my Free Dictionary API.

🔗 Try it: https://api.suvankar.cc/docs/dictionary

In this article, I'll share what I built, where the dictionary data comes from, the technology behind it, and some of the engineering challenges I encountered along the way.

Why build another dictionary API?

There are already several dictionary APIs available. However, I wanted to build something that was:

• Free to use.
• Accessible without an API key.
• Easy to integrate into applications.
• Based on a comprehensive, openly available dictionary dataset.
• Simple enough for developers to experiment with.

I also wanted to learn more about processing large dictionary datasets and building a public-facing API that could serve real-world applications.

Rather than starting with manually curated dictionary entries, I decided to explore Wiktionary.

The data: Wiktionary

The foundation of this project is data derived from Wiktionary, the collaborative, multilingual dictionary project.

I used structured Wiktionary data available through Kaikki.org, which makes Wiktionary content available in machine-readable formats.

This was particularly interesting because dictionary entries contain much more than just a word and its definition.

An entry can include information such as:

• Definitions and senses.
• Parts of speech.
• Pronunciations.
• Etymology.
• Examples of usage.
• Translations.
• Grammatical information.

Processing this information into a structure that could be efficiently queried through a REST API was one of the interesting parts of the project.

Designing the database

One of the first challenges was deciding how to represent dictionary data in a relational database.

A dictionary entry isn't necessarily a simple one-to-one relationship between a word and a definition.

A single word can have multiple meanings, different parts of speech, examples, translations, and additional metadata.

I use PostgreSQL as the primary database and a relational structure to represent these relationships.

The objective was to keep the data structured while making common dictionary lookups efficient.

The data ingestion and processing pipeline is maintained separately from the API repository. The repository linked below contains the API application itself.

Building the API

I used Java 21 and Spring Boot 3 to build the REST API.

The API exposes dictionary information through straightforward HTTP endpoints that return structured JSON responses.

Some of its current capabilities include:

• Looking up English word definitions.
• Searching for words by prefix.
• Retrieving translations.
• Accessing Word of the Day.

For example, retrieving a definition is as simple as:

curl "https://api.suvankar.cc/dictionaryapi/v1/definitions/en/happy?compact=true"

You can also search for words:

curl "https://api.suvankar.cc/dictionaryapi/v1/words/en/?filter=happ&page=0&size=5"

And retrieve translations:

curl "https://api.suvankar.cc/dictionaryapi/v1/translations/en/?word=secure&pos=verb"

The API returns JSON that can be consumed by web applications, mobile applications, scripts, or other backend services.

You can explore the available endpoints and response structures in the interactive documentation:

https://api.suvankar.cc/docs/dictionary

Some engineering decisions

Building the endpoints was only one part of the project. Making them efficient and suitable for public consumption required additional infrastructure.

Here's a look at some of the technologies involved.

PostgreSQL

PostgreSQL stores the structured dictionary data.

Given the relationships between words, senses, definitions, examples, and translations, a relational database was a natural choice.

Redis

I introduced Redis caching to avoid repeatedly querying PostgreSQL for frequently requested dictionary entries.

Dictionary lookups are particularly suitable for caching because the underlying data doesn't change with every request.

Rate limiting

Since the API is publicly accessible without API keys, I also needed a way to protect the service from excessive request volumes.

I implemented rate limiting using Bucket4j.

The idea is to keep the service accessible while protecting the underlying infrastructure from excessive traffic.

Docker

The application is containerised using Docker, making deployment and environment management easier.

Making it accessible without API keys

One decision I deliberately made was not to require API keys.

I wanted developers to be able to open the documentation, make their first request, and get a response immediately.

No registration forms, no API key generation, and no complicated setup.

Of course, public access doesn't mean unlimited resources. The API has rate limits to help maintain service availability.

What can you build with it?

There are plenty of possible applications for a dictionary API.

For example:

• English dictionary applications.
• Vocabulary learning tools.
• Word-of-the-day applications.
• Language learning platforms.
• Browser extensions for instant word lookup.
• Writing assistants.
• Educational applications.

I'm also building an Android dictionary application called Lexicall, which is one of the projects that makes this API particularly interesting to me.

Building an actual client application has helped me think beyond simply returning JSON responses. API usability, response structures, search performance, and caching all become much more important when there's a real application consuming the service.

What's next?

This is an ongoing project, and there's still plenty I'd like to improve.

Some areas I'm interested in exploring further include:

• Improving dictionary data coverage.
• Optimising search and database queries.
• Expanding language and translation support.
• Improving caching and API performance.
• Making the documentation and developer experience better.

I'd also love to hear how other developers use the API and what features they would find useful.

Try the API

If you're building something that needs English dictionary data, feel free to give it a try.

API Documentation: https://api.suvankar.cc/docs/dictionary

Source Code: https://github.com/suvankar-mitra/free-dictionary-rest-api

No API key required. Just make a request and start building.

The API code is open source under the Apache License 2.0. The dictionary data is sourced from Wiktionary and licensed under CC BY-SA 4.0. Please refer to the repository for licensing and attribution details.

If you have feedback, suggestions, or ideas for improvement, I'd genuinely love to hear them.

Thanks for reading!