Dev news: Launching API version 2 (also v1 deprecation notice) | Last updated 2021-01-17

[Halo]

@raf555 That will probably take them a year or two. Meanwhile, non-api way:

(using the same User-Agent + mangadex_session cookie authentication)

Additional header:

{  'X-Requested-With': 'XMLHttpRequest'}

Type: GET

unfollow: mangadex.org/ajax/actions.ajax.php?function=manga_unfollow&id=123&type=123
type: same as id

follow: mangadex.org/ajax/actions.ajax.php?function=manga_follow&id=123&type=1
types: (correspond to MD list id's)

 {
    Reading: 1,
    Completed: 2,
    'On hold': 3,
    'Plan to read': 4,
    Dropped: 5,
    'Re-reading': 6,
  };

 

[raf555]

@Halo Ah, thank you so much!

 

[frankieMuniez]

I'm desperate for the alt titles to have tags of what language they are. Is this something that is planned to be added?

 

[MangaD]

First of all, thank you very much for your API system, you are one of the very few websites that allow access to their database via API, really appreciated.
I would ask what does mean when you get "restricted" while requesting pages list for a manga? For example calling https://mangadex.org/api/v2/chapter/1158264 gives me

{"code":403,"status":"error","message":"restricted"}

.
Note: If I try to access to the corrispondent manga on the website using a web browser I got a "Warning: Manga #35013 is not available. Contact staff on discord for more information." error message even after login, what it does mean? The weird thing is that the manga seems work flawlessy for other people, do I need to do something to enable access to these manga?

 

[Halo]

@MangaD It's a Korean webcomic. A number of them is set to be accessible only by authenticated users.
Send this request with the User-Agent + mangadex_session cookie headers and it werks.

It's even noted in the documentation: (naked api request)

"information": "Authentication is achieved by the same means as logging in to the site (i.e. the mangadex_session, mangadex_rememberme_token cookies, correct User-Agent). Some chapters may require authenticated permissions to access. The Content-Type header for requests with bodies must be application\/json, and the content must be valid JSON. Boolean query values are evaluated 1\/true\/on\/yes for true, otherwise false."

 

[Teasday]

2021-01-11
- Added

read

to the chapter entities in /user/:id/followed-updates. These are based on the actual stored markers, so under certain conditions they may be

false

even though chapters may appear as read on the website, such as when a manga is followed as Completed.
- [Future breaking] Added

title

the simple manga entities in /user/:id/followed-updates. IMPORTANT: This is because the entity erroneously used the

name

field for the title. Both fields currently have identical information, and

name

will be removed by the end of the month in a breaking change.
- Fixed the baseUrl in the index to reflect the new url.

 

[Teasday]

As a heads-up, the new API url is https://api.mangadex.org/v2/. The old webserver url is still up, but will be removed in about 3 weeks.

Incidentally, the v1 API can for now be found at https://api.mangadex.org/v1/, but I'm hoping to get rid of it as well alongside the removal of the webserver API url.

 

[Teasday]

_{@frankieMuniez posted:}

I'm desperate for the alt titles to have tags of what language they are. Is this something that is planned to be added?

For v5, yeah.

 

[ToaderTheBoi]

@Teasday great work on the new API! I've implemented it in the first week it was announced and I could get rid of the old ways of getting tags and such. I don't know if I'm just broken, but I actually really like the documentation in JSON, really accessible and gives me what I need to know. I have one suggestion I'd like to make though. Could you add a mangaCover field to followed-manga and followed-updates? My reasoning is that most people identify the manga they follow by the cover, rather than the name (especially if it is in Japanese).

Basically, if I don't have the cover cached for the specific manga, I need to do the initial request for the updates, and then for each update of a manga that isn't cached, I make another request to /api/v2/manga/{id} to get the cover and then cache it. This seems like a huge waste, especially for new users to my project.

Right now, I just make a request to mangadex.org and scrap the updates from the table like thingy, provided that the user is logged in. It's one request for the whole list and if the mangas aren't cached I get the cover URL straight from there. Would be a nice addition to the API.

 

[Teasday]

@ToaderTheBoi Duly noted, I'll consider it.

 

[DJScias]

A small nitpick, for whatever it's worth, but you wrote 2020-01-11 instead of 2021-01-11.

 

[nonindustrial]

Chapters like:

/api/v2/chapter/1160223

that return a string for `pages` cause problems in programming languages that require strict typing. Normally you look for an array out of `pages` (even if it's a blank array) but "official publisher's website" chapters contain a string value instead.

It's related to:

This chapter can be read for free on the official publisher's website.
Feel free to write your comments about it here on MangaDex!

 

[Teasday]

@DJScias What can I say, I live in the past. Fixed.

@nonindustrial Deserialize the entity in a way that checks for the type and assign accordingly.

 

[Xunder]

@nonindustrial Or check if the chapter "status" is "external", that way you can do something else when "pages" is a string

 

[nonindustrial]

Deserialize the entity in a way that checks for the type and assign accordingly.

That might be a solution in my specific case since I know about it, but there is no indication that the API would ever return a website link instead of an array of images for `chapter.data.pages`. It essentially requires all developers to randomly run into an "official publisher's website" chapter while testing and program a specific exception (strict typing or not).

Or check if the chapter "status" is "external", that way you can do something else when "pages" is a string

Thank you, that's a real solution. Unfortunately, it still requires randomly running into an (external) "official publisher's website" chapter while testing to know about handling it.

 

[Xunder]

@nonindustrial this is how i did it in python for my downloader

if chapter_data["status"] not in ('OK', 'delayed'):
            return

 

[Teasday]

_{@nonindustrial posted:}

That might be a solution in my specific case since I know about it, but there is no indication that the API would ever return a website link instead of an array of images for `chapter.data.pages`. It essentially requires all developers to randomly run into an "official publisher's website" chapter while testing and program a specific exception (strict typing or not).

True, I didn't bother writing up docs for the response structures. If it's any consolation, I can't remember there being any other fields that could have multiple types (excluding null).

 

[nolbat]

@Teasday thanks for the API. Is it possible for you to standardize the beginning of the covers endpoint to be like the other endpoints. For example like chapters.

Here is the start of covers (https://api.mangadex.org/v2/manga/[manga id]/covers):
{"code":200,"status":"OK","data":[{"volume":"1","url":"https:\/\/mangadex.org\/images\/covers\/19693v1.jpg"} ...

Here is the start of chapters (https://api.mangadex.org/v2/manga/[manga id]/chapters):
{"code":200,"status":"OK","data":{"chapters":[{"id":1167483,"hash":"8eaf5eceee9dad1788f6b9edca5a0fd0", ...

Could you change covers and add {"covers": :
{"code":200,"status":"OK","data":{"covers":[{"volume":"1","url":"https:\/\/mangadex.org\/images\/covers\/19693v1.jpg"} ...}

Thanks

 

[Teasday]

2021-01-15
- Fixed group leaders and members not having permission to read their own delayed chapters.
- Added parameter

blockgroups

to all endpoints that return a list of chapters (e.g. /manga/:id/chapters and others).
- Added parameters

type

and

hentai

to /user/:id/followed-manga (same params that followed-updates already had).
- Added

mainCover

to /user/:id/followed-manga and /user/:id/manga/:id.

 

[Teasday]

@nolbat The chapter lists being separated to chapters/manga/groups is the exception, not the standard.