I have a brand new ZZ Bond running 2.5.2. I have been able to get the token, but when requesting the devices, I am getting:
curl: (52) Empty reply from server.
Here is the command I am running:
curl -X “BOND-Token: xxxxxxx” -i http://x.x.x.x/v2/devices
Ditto. Well, it’s a BB running v2.5.1-44-g9d5c43d-jacob-uglydb
Remember you are trying to send the BOND-Token in the header, and the action type for this command is a GET, so try this syntax:
curl -i -H “BOND-Token: xxxxxxxxxxxxxxxx” http://ZZxxxxxxx.local/v2/devices
or
curl -i -H “BOND-Token: xxxxxxxxxxxxxxxx” http://x.x.x.x/v2/devices
I have been able to get a list of devices and traverse each node within the list of devices on both BD and ZZ revision BONDs.
Thanks much. This is working with “-H”.
The documentation currently states that “-X” should be used.
Oh I see what you mean - those screenshots show it with -X.
I was relying on a part earlier in the document when it says “Copy the token and use it with a BOND-Token header in subsequent requests”.
There are also some pretty good quick 'n dirty examples in the video I shared from Chris in the Beta sign up thread.
Thanks. I’ll take a look at the video.
Ah, many thanks. I’ve got it working now.
Following the above conversation, I am unable to get devices from the BOND bridge:
$ curl -H "BOND-Token: 890XXXXXXXXa4460" -i http://10.0.0.245/v2/devices
HTTP/1.1 200 OK
Content-Length: 18
Content-Type: application/json; charset=utf-8
{"_":"615e7200"}
In the app, it shows two devices:
Out of curiosity, are these fairly high tech remotes with screens and such?
I saw Chris Merck mention in one of the threads that a fan was stored in the cloud and unavailable to the local API, but I don’t know the specifics around that. I just assumed that a more complicated remote would maybe be the one stored in the cloud.
(BOND Local API BETA Sign-Up)
The remotes don’t have displays. When I reverse engineered the cloud API it showed the fans for my old BOND. I have the newer hardware revision now (ZZ) which supports the local API. I would think that it should at least return the devices associated with the bridge.
Ah, you’re that guy! I followed the reverse engineering you did but was holding out hope for the official API.
I re-read the post about a cloud device. Seems like it’s backwards from what I remembered. There was a user that was missing 3 out of 4 devices, and Chris said “The 1 device that remains is because it is stored on the Cloud. Those devices are not currently available via the Local API. I know this is not evident from the current UI, and we are planning on straightening that out.”
So I feel like I’m barking up the wrong tree. Have to wait for Chris or others to actually help you since I don’t really see an answer.
Yup, that’s me! Official docs are much cleaner than anything I was able to put together. Thrilled that it’s a local API too!
I may have gotten my subtraction wrong @residualimages 
We do have two different types of devices internally: “legacy devices” and “cloud devices”. The “cloud devices” are currently only stored in the cloud and do not actually have any record on the BOND’s database, so, sadly they are not available via the Local API. — They will be available via the Cloud API when that is released.
We do plan to migrate the current “cloud devices” offline, at least for newly-recorded devices, once support for these more sophisticated protocols is there in the firmware.
So, for the time-being, you may see what @danmandle is seeing, and have missing devices on the Local API.
So how do we know which devices will be cloud only for the time being?
For now, there’s no way to tell until you check on the local API. We consider it a temporary issue that the devices are not accessible via local API, and are working on making all devices work offline.
@merck any updates on “cloud devices” being moved to the local API?
It’s probably the toughest technical challenge that we have attempted, but with big community upside… Will be attacking this after fully rolling out the V2 firmware.
Where is that in the queue vs exposing the cloud API? Just trying to figure out if/where I can control my fans via any API before the height of summer.
Cloud API first for sure. 
@joaoricardo will announce it!
I just updated the firmware to 2.6.21-beta on a snowbird device:
{
"target": "snowbird",
"fw_ver": "v2.6.21-beta",
"fw_date": "Fri May 24 21:31:07 UTC 2019",
"uptime_s": 599,
"upgrade_http": true,
"api": 2,
"_": "2523894a"
}
However, when I list devices, this is what I get:
http://x.x.x.x/v2/devices
{
"_": "f4e91b3d"
}
I think that means that only the hash value of the devices object was returned, with no devices? That is unfortunate, because I actually have two devices configured: a fan and a fireplace. I assume that they must be cloud devices? @merck: Is there any way to confirm the device type for the devices attached to my BOND bridge (BD23512)? Thanks!