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

[Teasday]

2021-01-15 b
- Fixed /user/:id/followed-manga returning an object instead of an array like it should have, previous to the last update

 

[Jophnny1023]

@Teasday Sorry to bother you, I'm still being blocked out of my delayed chapters. This issue is not completely resolved yet...

Is it a matter of the update still rolling out?

EDIT: Guest accounts can open the delayed chapters but not the uploader or group members?!? Something's really wrong here...

 

[Teasday]

2021-01-17
- Fixed group leaders and members still not being able to read their delayed chapters

 

[Teasday]

@Jophnny1023 Mistakes were made, should be fine now.

 

[alexsilener]

I'm not a web developer, but when trying to authenticate my api requests with the session and remember me cookies I get from Edge (88.0.705.45 beta) I kept getting hit with 403s.
Used the same cookies from Firefox and it worked.
Checking the response headers in Edge, the session cookie gets deleted whenever I try to access the api (which I think results in the 403s?). Even through the browser itself, which should be storing all needed cookies. This also semi-randomly logged me out of the main site. (endpoint was the 'followed updates' endpoint in this case.)
Response headers in Firefox showed a new session cookie being set each time.
I guess this might not be appropriate here, or might be an issue with Edge, but I use that as my main browser and I had the biggest headache for hours trying to figure out why the heck this wasn't working. Thought I should point the erratic behaviour out in case it might actually be an issue.

Also, there is a difference in results between

user/{id}/followed-updates

and

user/{id}/followed-updates?type=1

. After following some new series as reading, the new type 1s only show up in the earlier request but not in the latter, even after quite a few hours.

followType

in

user/{id}/followed-manga

show these new additions as type

1

.

shownChapterLangs

in

user/{id}/settings

gives a list of ids. But I couldn't find a way to get the corresponding language names for the id numbers. (Apart from which, changes to followed languages are not reflected in api results, though I guess that's a matter of time.)

 

[alexsilener]

Also, there is a difference in results between user/{id}/followed-updates and user/{id}/followed-updates?type=1. After following some new series as reading, the new type 1s only show up in the earlier request but not in the latter, even after quite a few hours. followType in user/{id}/followed-manga show these new additions as type 1.

@Teasday

user/{id}/followed-updates?type=1

is still not showing proper results for me. For example, taking "Isekai Ojisan" (mangaId: 31488) which I followed around two days ago, it shows up in

user/{id}/followed-manga

as

followType: 1

. A recent update for it shows up in

user/{id}/followed-updates

but is not showing up in

user/{id}/followed-updates?type=1

.
The update does show up in the follows tab on the main Mangadex page.

 

[0TheWatcher0]

Can anyone login with the new api link (https://api.mangadex.org/v2/user/me) using python or any other language?
For some reason it does not work. The old one (https://mangadex.org/api/v2/user/me) works fine though.
Quite confused because I am using the exact same method to read the json but the new link does not work.
Note: - I am using python to call the API

 

[Teasday]

@alexsilener That's a caching issue on the api.mangadex.org server, not a problem with the API per se. Working on it.

As for the login issues (for @0TheWatcher0 as well), my best guess is that the script rejects the session cookie for security reasons and invalidates the session. Changing the User-Agent could in some situations cause that to happen, as far as I understand.

 

[0TheWatcher0]

Changing the User-Agent could in some situations cause that to happen, as far as I understand.

@Teasday but it works for the previous v2 api link without changing anything (i have tried changing the headers as well but it does not work). I will try again once the old link gets decommissioned.

 

[sarusa]

@Teasday I was able to convert PMDL's code over to use API v2 in a just over an hour (using Newtonsoft JSON). Very nicely done, this is so much better than scraping HTML.


edit: The mark_read doesn't seem to be working, though, even when specifically parameterized. Not a showstopper, though.

 

[nicoelson]

@Teasday, good day. Could there be an issue with the API? Chapters are not being updated. Thanks.

 

[Halo]

@nicoelson yep, they know. Join the MD discord channel for the latest updates and communications #ad

 

[volcelhmptn]

feels like a stupid question but I cant seem to parse the api at all. When i replace the md url with any random .json file i parse it fine so I'm completely clueless. It also worked when I just copy pasted the object and tried extracting different values as if it was a local .json file.

 

[sarusa]

@volcelhmptn - the dedicated API server is just completely hosed right now, so if you attempt to parse what you get back you may be parsing a blank page. That's the first thing I'd check - write what you think is the page content to a debug file and see if it's anything sane.

So assuming you do get a good response, it really is this easy (using Newtonsoft as an example):

            var req = (HttpWebRequest) HttpWebRequest.Create(  chapterUrl  );
            // whole lot of cookie and header stuff skipped
            rsp = (HttpWebResponse) req.GetResponse();   // ignore error handling for all this
            var rspStream = rsp.GetResponseStream();
            using (var sr = new System.IO.StreamReader( rspStream  )  )
                page = sr.ReadToEnd();   // this is now the text page data, string page

            // Ignoring all try/catch and null checking here
            dynamic json = JsonConvert.DeserializeObject( result.page );
            string serverUrl = json.data.server + json.data.hash + "/";

            var imageUrls = new List<string>();
            foreach( var p in json.data.pages )
                    imageUrls.Add( serverUrl + p.Value );

 

[DrMuhammad]

@Teasday
Hello! Mangadex follows do not seem to sync with Neko (Tachiyomi). And incidently when in a logged in browser I go to this link https://api.mangadex.org/v2/user/me/followed-manga I find all the unsynced mangas of mangadex to Neko, missing from the list. This is probably an api server cache issue? Can it be fixed? Thanks
Edit. Found similar issue here on neko bugs list https://github.com/CarlosEsco/Neko/issues/402
Neko dev says its an issue on mangadex end. Maybe? Or is the issue on my end? Thanks for your time.

 

[volcelhmptn]

@sarusa yeah after some debugging (swapping NASA api, etc. in the place of the MD url) I came to the conclusion that it was returning a blank page and my parsing method was fine. I'm dumb as shit and just use XMLHttpRequest or AJAX (forgot to mention im using JS) so idk what all that means but if the server is the issue as you say then don't worry about it lol. It's a free API so these things happen.

 

[marcus-beta]

the mangadex api is open source?

 

[Teasday]

@DrMuhammad As mentioned, it's a caching issue that we're working on.

@volcelhmptn If you're using XHR in browser (well, first of all you should be using

fetch

) outside of the mangadex.org domain, your problem is probably CORS rather than anything to do with the server. We don't allow cross-origin requests.

 

[volcelhmptn]

@Teasday really sorry if this is a dumb question but does that mean i can't access the mangadex api from a different domain? besides the md team internally, who else would even be able to use it without cross-origin requests?

 

[Teasday]

_{@volcelhmptn posted:}

really sorry if this is a dumb question but does that mean i can't access the mangadex api from a different domain? besides the md team internally, who else would even be able to use it without cross-origin requests?

That's what it means, yes. Obviously we don't want other sites just directly acting as a frontend for our data. They'll have to go through some effort ripping us off at least.

What you should realize is that CORS is specifically just a commonly implemented web browser security feature designed to prevent unapproved cross-origin fetch calls, which means that it doesn't really apply to any client that isn't a browser. There's no "origin" in that case, after all, and there's nothing that forces you to implement such a feature into your client.

This means that one way to get around the CORS issue inside the browser would be to route your api calls via a proxy server - although that obviously means the proxy server may have to take care to not hit our rate limits and get autobanned if several people are using it.