Background: I made Splatoon2.ink, a site that shows the current and upcoming map schedules for Nintendo’s Splatoon 2. It pulls data from SplatNet2, their app/site that connects you to game info via the Nintendo Switch mobile app. More information about the SplatNet 2 API can be found here, and source code for Splatoon2.ink can be found here.
Yesterday, a number of sites and tools that pull data from SplatNet 2 stopped working. This seems to be caused by a change to the Nintendo Switch app’s login procedure:
Looks like there’s some new 64-char hash value called “f” on the call to /Account/Login, I’m guessing that’s it. Not sure how it’s generated pic.twitter.com/Nqu2h8xmwx
— Matt Isenhower (@mattisenhower) September 14, 2017
This new parameter appears to be an HMAC SHA256 hash that is likely made up of several pieces of user data and, potentially, a secret key stored within the app itself. Depending on how they’ve implemented this, it may be difficult or impossible to determine how to calculate this hash.
Getting your site back online
Splatoon2.ink continued working through these changes because I don’t actually attempt to log in to SplatNet 2 on an automated basis. I’ve been using the same
iksm_session ID to retrieve data since launching the site a month ago without any trouble.
If you run a site that just provides generic data from SplatNet, this is the method I’d recommend using for now. Just pull the
iksm_session ID from your phone using Fiddler or some other MITM tool and use that to access the SplatNet API endpoints. You can see this in my code here.
If you make a tool that accesses user-specific data to upload it to stat.ink or some other site, unfortunately this change makes the initial sign-in procedure more cumbersome for your users. Using a MITM tool seems to be the only reliable way to get the user’s session ID at the moment. Make sure you explain the potential dangers of using MITM tools, and instruct your users to remove the tool’s root certificate from their phone when they are done.
Obtaining the session ID and accessing SplatNet API endpoints this way may not work forever, but it seems to be pretty reliable so far. My guess is that these login changes were a deliberate action by Nintendo in an attempt to improve account security. It’s possible they noticed increased login activity from “unauthorized” tools and implemented these changes to prevent account takeover attacks, etc.
There are still various ways Nintendo could block us from accessing the SplatNet API, but if we (as people building tools that access their API) don’t give them any reason to block us, hopefully they won’t.
Don’t make Nintendo angry
It’s always important to be careful when accessing someone else’s API. This is especially true when using an unofficial API where they don’t intend for anything other than their own apps to be accessing it.
Here are some tips to ensure your site or tool’s API activity have as low of an impact as possible:
- For most Splatoon data, there is no need to update more than once per hour. Try to minimize the number of requests you make to the API. Map rotations only occur every two hours, so there’s little reason to retrieve schedule data more frequently than that. Other types of data (like battle history) update more frequently, so use your judgment to set a reasonable rate.
- Cache a local copy of SplatNet data and images. If your site receives 1,000 hits, this shouldn’t translate to 1,000 hits to Nintendo’s API. This includes images – don’t just hotlink images from app.splatoon2.nintendo.net, save a local copy to your server and host them yourself.
- Make sure you handle error responses properly. If the API goes down or if you get blocked, make sure your tool doesn’t start hammering their API endlessly.
- Provide a useful user agent string for your requests. Include the name of your site or tool and a link to it in the
User-Agentheader for each of your requests. This way, if your tool starts misbehaving, Nintendo has an easy way to block it (or contact you) without affecting other sites or tools.
This list can easily be applied to any other unofficial API you might want to access, too. If we all implement our sites properly, hopefully Nintendo won’t have any reason to make changes that may block us in the future 😀