---
date: "2015-05-12T17:00:00Z"
title: Nintendo's Hotspot 'API'
description: "Using Nintendo's 3DS Hotspot API for Streetpass and Spotpass"
tags: [android, nintendo, technology]
---

Since getting a DS, [StreetPass](http://www.nintendo.com/3ds/built-in-software/streetpass) has become quite addictive. It's actually pretty fun checking the device after walking through town or using public transport to see a list of Miis representing the people you've been near recently, and the minigames (such as StreetPass Quest) that require you to 'meet' people in order to advance also make it more involved. Essentially the more you're out and about, the further you can progress - this is further accentuated through Play Coins, which can be used to help 'buy' your way forward and are earned for every 100 steps taken whilst holding the device.

![Nintendo Zone](/media/blog/nintendozone2.png)

The DS systems can also use relay points in Nintendo Zone hotspots to collect StreetPass hits. These zones are special WiFi access points hosted in certain commercial venues (e.g. in McDonalds and Subway restaurants), and allow you to 'meet' people around the world who also happen to be in another Nintendo Zone at the same time. As such, users can get a lot of hits very quickly (up to a maximum of 10 at a time). There are various ways people have [found](https://gbatemp.net/threads/how-to-have-a-homemade-streetpass-relay.352645) to set up a 'home' zone, but Nintendo have also published a [map](https://microsite.nintendo-europe.com/hotspots) to display official nearby zones.

However, their map seems a little clunky to use while out and about, so I wanted to see if there could be an easier way to get this information more quickly. When using the map, the network logs revealed `GET` requests being made to:

```
https://microsite.nintendo-europe.com/hotspots/api/hotspots/get
```

The location for which to retrieve data is specified through the `zoom` and `bbox` parameters, which seem to map directly to the zoom level and the bounds reported by the underlying Google Maps API being used. For some reason, the parameter `ummary_mode=true` also needs to be set. As such, a (unencoded) request for central Cardiff may look like this:

```
/hotspots/api/hotspots/get?summary_mode=true&zoom=18&bbox=51.480043,-3.180592,51.483073,-3.173028
```

Where the coordinates (`51.480043,-3.180592` and (`51.483073,-3.173028<`) respectively represent the lower-left and upper-right corners of the bounding box. The response is in JSON, and contains a lat/lng for each zone, a name, and an ID that can be used to retrieve more information about the host's zone using this URL format:

```
https://microsite.nintendo-europe.com/hotspots/#hotspot/&lt;ID&gt;
```

When the map is zoomed-out (to prevent map-cluttering) a zone 'group' might be returned instead of an individual zone, for each of which the size is indicated. Zooming back in to a group then reveals the individual zones existing in that area.

![Nintendo Zone 2](/media/blog/nintendozone1.png)

It seems that this server endpoint does not support cross-origin resource-sharing (CORS), which means that the data is not retrievable for a third-party web-app (at least, without some degree of proxying) due to browser restrictions. However, and especially since the endpoint currently requires no session implementation or other kind of authentication, the data seems very easily retrievable and manageable for non-browser applications and other types of systems.
