A Free API for Chinese Web Novel Data: What You Can Build With It

If you build things for web novel readers, you've probably wanted this: give a program a Qidian link or a Chinese title and get back the English title, the author, the status, the length and the numbers.

Since the 1.12 release you can. DaoSearch has a public API, free for personal projects and tools. This post is the tour: what's in it, what it costs, and a few things worth building. The full reference is the API guide.

What it is

A read-only JSON API over the same data as the site. Every call is a GET, every answer is JSON, and there's nothing in it the pages don't already show a reader. It covers all six platforms: Qidian, Fanqie, JJWXC, Faloo, Qimao and Zongheng.

It's for tools that look things up. It isn't a way to copy the catalogue, and the limits are set with that in mind.

What you can ask for

A book. Name a platform and the book's id there, the same id that's in the platform's own link, and you get everything its page shows: titles and author in English and Chinese, the English synopsis, genre and tags, the platform's own figures, the ranking boards it sits on now, whether the platform still carries it, the same novel on other platforms, and a link to an English translation when we know of one.

Search. A title in English or Chinese returns up to five books across all six platforms. Paste a book's link from its platform and you get that one book. There's an author search too.

A catalogue. Each platform's Browse page as data, with the same filters: title, author, status, genre, tags to include and exclude, length, last update, the platform's own extras, the minimum filters and Hide dropped, and every sort.

Genres and tags. Each platform's vocabulary with book counts, the same lists as the genre index and the tag index.

Rankings. The boards we hold for a platform, and any board's entries with each book's position and how it moved since the previous day.

Booklists. A platform's reader-made lists, the lists that contain a given book, and one list with its books. Zongheng has no booklists, and the API says so up front.

One call, /sources, describes all of it: for each platform, what every figure means, which sorts and filters its catalogue takes and on which steps. Start there, and read the allowed values from it instead of hard-coding them.

What it costs

Nothing. You need an account and a key.

• One key per account. Create it on your account page, under "API key". The account has to be a day old.
• The key is shown once. Store it when you create it. We keep only a hash, so nobody can show it to you again. Regenerate replaces it and the old key stops at once. Revoke stops it and leaves you without one.
• 60 requests a minute and 5,000 units a day. A single record, like one book, costs 1 unit. A page of a listing, up to 50 books or lists, costs 5. A refused request costs nothing.
• Every answer says where you stand. Three headers carry your daily units, how many are left and when they come back, so a tool can pace itself without hitting the wall.

For scale: 5,000 units is 5,000 book lookups a day, or a thousand pages of rankings. A Discord bot for a busy server won't come close.

We keep the day your key was last used and today's count against the limits. We don't keep what a key asked for.

Things worth building

A lookup bot. Someone pastes a qidian.com or fanqienovel.com link in your Discord server. The bot sends it to search, gets the book, and replies with the English title, author, status, length and a link to the page. One unit.

A "has it finished yet" checker. Keep a list of book ids and ask for each once a day. Status, chapter count and last update are all on the book record. (If you only want this for yourself, the daily digest already does it for the books on your shelf.)

A userscript for raw readers. On a platform's book page, call the API with the id from the address bar and show the English title and synopsis beside the Chinese. The API can't be called from an ordinary web page on another site, but a userscript or a browser extension can call it.

A ranking watcher. Fetch a board once a day and post the new entries. Each entry says whether it's new, up, down or flat, so you don't have to keep yesterday's copy.

A tool for an AI agent. The OpenAPI document gives every endpoint a name that reads as an intent, like get_book and search_books, with a description of when to use it and what it costs. Most agent tooling can turn that into tools directly. There's also an llms.txt that describes the site's public pages in a few lines.

A translator's shortlist. Ask a catalogue for completed books in a length range with a floor on a reader figure, and you have candidates for your next project, with the Chinese title and author ready to copy.

How answers are shaped

A few choices that make the data easier to work with:

• A book is named by its platform and its id there, sent as text. Fanqie's ids are 19 digits, longer than a JavaScript number holds.
• Text in two languages comes as a pair, English and Chinese. English is null until a book has been translated. Genres and tags are named by their Chinese in parameters, since that's the part that never changes.
• A missing fact is null, never zero or an empty string.
• Numbers are raw. 22256029, not "22.3M". Times are in UTC.
• Figures come as a list. The six platforms count different things, so each figure has a key, the label the site prints, a value and the period it covers. Don't compare a figure across platforms. Why not.
• Every object carries the address of its page here.
• A parameter the endpoint doesn't have is refused, not ignored. A typo gets you an error that says which parameter, and not a quietly wrong answer.

Errors are JSON with a stable code to branch on and a message that says what to do next.

What it won't do

• No chapters. DaoSearch is a catalogue. It hosts no chapter text and neither does the API.
• No Chinese synopsis. Chinese titles and tags are sent because they identify a book. The synopsis is sent in English only.
• No anonymous access and no demo key. Every request needs a key, in the Authorization header. A key in the address is refused, because addresses end up in logs.
• No calls from a web page on another site. A key in a public page is a published key. Call the API from a server, a script, an extension or a userscript.
• No catalogue across platforms. Each platform has its own, as on the site, because their figures don't compare.
• No deep paging of a filtered view. A view with two or more filters goes five pages deep. Narrow it to see more.

The terms, in short

Creating a key means agreeing to six things:

1. It's free, for personal projects and tools. It may change or stop, and a breaking change gets a new version path and 90 days' notice.
2. Show a link to the book's page wherever you show its data.
3. Keep to the limits and cache what you fetch.
4. Don't use it to copy the catalogue or to train on it in bulk. Titles, synopses and covers belong to their authors and the platforms.
5. Keep your key out of public pages and repositories. A published key gets revoked.
6. Send a User-Agent that names your tool.

Getting started

1. Sign in, open your account page and create a key.
2. Read the API guide. It has a request and a real answer for every endpoint.
3. Call /sources first, then try search with a title you know.
4. Point your tooling at the OpenAPI document if it can read one. It needs no key.

The status page shows whether the API is up, beside the website, search and rankings. If a limit is too tight for something reasonable, or you find a bug, tell us on the Discord or through the contact page.

And if you build something, show us. We'd like to see it.