Wikipedia-API, a Python wrapper with matching sync and async clients

What the library covers and the sync/async split

Wikipedia-API is an easy to use Python wrapper for the Wikipedia API, and it supports extracting texts, sections, links, categories and translations. The goal is stated plainly: to provide a simple and easy to use API for retrieving information from Wikipedia, and the documentation provides code snippets for the most common use cases.

The library offers both a synchronous client, Wikipedia, and an asynchronous one, AsyncWikipedia, and the README spends a paragraph on exactly how they differ, which is the part worth knowing before you write code against it.

All the data-fetching attributes, which the README lists as summary, text, sections, langlinks, links, backlinks, categories, categorymembers, coordinates, images, pageid, fullurl and displaytitle, are explicit property definitions in both APIs. In the async client every one of them returns a coroutine, so you write await page.summary and await page.sections. In the sync client they are plain attribute reads.

A few things are plain properties in both, with no await needed: title, ns, namespace, language and variant. Those are values the client already knows rather than things it has to fetch.

exists() is a plain method in the sync API and a coroutine method in the async one, and section_by_title() and sections_by_title() are plain synchronous methods in both, so the section lookup does not need awaiting even in the async client.

That consistency is the design goal and it is a good one. Most wrappers that offer both variants make you learn two different shapes. Here the difference is confined to whether you await, and the documentation shows the sync and async versions of the same operation side by side so you can check.

The package requires at least Python 3.9 to install, because it uses IntEnum.

The user agent requirement and why it is not optional

To initialise the client you have to provide two things, and the first is the one people get wrong.

The user_agent must identify your project, must include contact information such as an email or website, and must follow the Wikimedia Foundation User-Agent policy. The language argument specifies the language mutation and has to be one of the supported languages.

import wikipediaapi

# Synchronous client
wiki = wikipediaapi.Wikipedia(user_agent='MyProjectName ([email protected])', language='en')

# Asynchronous client
wiki = wikipediaapi.AsyncWikipedia(user_agent='MyProjectName ([email protected])', language='en')

The fact that the user agent is a required constructor argument rather than an optional one is a deliberate design choice that follows from how the Wikimedia API works. Requests without a proper user agent are hard to attribute, and the foundation's policy is explicit that clients should identify themselves and provide a way to be contacted. A wrapper that made the field optional would be helping people build clients that get blocked.

The supported languages list lives on the MediaWiki meta site, and the practical point is that language is the edition of the encyclopaedia, so en gives you the English Wikipedia and de the German one, with completely different article sets.

Getting a page is then a single call:

import wikipediaapi
wiki_wiki = wikipediaapi.Wikipedia(user_agent='MyProjectName ([email protected])', language='en')

page_py = wiki_wiki.page('Python_(programming_language)')

And the async version is the same shape inside a coroutine, with the note that data is fetched lazily, so you await any attribute or property to trigger it.

Checking existence and reading a summary

The exists method is the cheapest way to find out whether an article is there, and the README shows the sync and async forms of the same check.

page_py = wiki_wiki.page('Python_(programming_language)')
print("Page - Exists: %s" % page_py.exists())
# Page - Exists: True

page_missing = wiki_wiki.page('NonExistingPageWithStrangeName')
print("Page - Exists: %s" % page_missing.exists())
# Page - Exists: False

The async form awaits the result, and the README explains what it does under the hood: it lazily fetches the pageid via the info API call if it is not already cached, the same approach used for awaiting the fullurl. So the existence check is a metadata lookup rather than a full article fetch, which is what makes it cheap enough to call on every candidate name.

That caching behaviour has a consequence worth understanding. Because the properties fetch lazily and cache, a page object that has already had its summary awaited will not re-request it. If you are walking a large number of pages, the number of requests is roughly the number of distinct properties you touch per page, not the number of pages.

The summary property is the other workhorse. WikipediaPage has a summary property, and in the async client reading it is an await. The summary is the short lead text that appears at the top of an article and in search results, which makes it the field most people actually want.

The rest of the property list follows the same pattern: text for the full plain text, sections for the table of contents with their levels, links and backlinks for the article graph, categories and categorymembers for the classification, langlinks for the equivalent articles in other languages, coordinates for the point, images for the files used, and the displaytitle for the rendered title.

The section accessors are the part that needs no await in either API. section_by_title() looks up a single section by its title, and sections_by_title() looks up several at once, and both are plain synchronous methods because the section structure comes from a single fetch.

Where it fits against calling the API directly

The obvious alternative is to call the MediaWiki API yourself with requests or httpx, and for a single endpoint that is a perfectly reasonable choice. The API is a plain HTTP API with query parameters, and the response is JSON.

The difference in approach is that Wikipedia-API gives you an object model. A page is an object, the summary is an attribute of it, and the sections are a list of section objects with titles and levels, rather than a dict you index into. For code that touches several different parts of an article, that is a real saving, and it is why the library says it supports extracting texts, sections, links, categories and translations in one interface.

The cost is that you inherit the wrapper's model. If the API gains a field the wrapper does not expose, you cannot reach it without dropping down to raw requests, and the wrapper's caching means the raw call and the wrapped call can see different data if you mix them.

The second alternative is a scraper rather than an API client, and the repository topics include wikipedia-scraper and wikipedia-web-crawler, which suggests both have been used. Scraping the rendered page is the wrong tool for structured data: it is slower, it breaks when the HTML changes, and it does not give you the category graph or the interlanguage links. The API is the supported route and it is what this wrapper targets.

Two practical cautions. The first is rate limiting: the Wikimedia API asks clients to be reasonable, and the wrapper does not add a retry or throttle policy of its own, so if you are walking thousands of pages you need to add your own pacing. The second is that the user agent policy is not a formality, and a project that identifies itself as a scraper rather than a project with a contact address is the pattern that gets a client blocked.

For reference, the library is MIT licensed, the version is 0.16.0 from September 2026, and the release cadence through 2026 has been regular, with the last push on 2026-10-14.

Editorial conclusion

Adopt Wikipedia-API if you are pulling article text, sections or metadata in Python and want the sync and async clients to behave identically. Skip it if you need to work against a Wikimedia instance other than Wikipedia, since the wrapper targets the public encyclopaedia API. Verify first by constructing the client with a user agent that names your project and includes a contact address, then fetching one page and checking that the summary and section list come back as you expect.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. martin-majlis/Wikipedia-API on GitHub
4. README
5. Releases