Hello,
it has come to our attention that we are unable to retrieve a list of applications from following API call:
GET https://eu1.cloud.thethings.network/api/v3/applications
Is there any reason for that? I admit, that I’m not up to date with TTN news, but I cannot find anyone having a similar issue.
It seems that this problem started on the 25th of July, late in the day (Europe). Does anyone know the reason?
Best Regards,
Aljaž
For commercial applications you can contact TTI support - but not in this instance as you appear to be using TTN. Perhaps @rish1 can help with migration.
@descartes Does that mean that TTI customers cannot use the same API reference as TTN?
I have been using the cli and loving it, but I now need to use the API no matter what I try in Postman, the routes are not found.
GET request to: https://nam1.cloud.thethings.network/api/v3/applications
{
"message": "not found",
"details": [
{
"name": "404_route_not_found",
"namespace": "proxy",
"correlation_id": "8dd3eca7-3dc3-4b16-8748-1c8de8c18855",
"message_format": "not found",
"@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
"attributes": {
"cluster": "nam1.cloud.thethings.network",
"flags": "NR"
}
}
]
}
or I get routed to the The Things Stack Cloud homepage response:
using a GET method to: The Things Stack Cloud
I am writing as last resort as I do prefer to debug things myself, but I’m at a loss. I don’t have a support package, so I am hoping for a point in the right direction.
Many thanks in advance, Tara
Not at all, quite the reverse. TTN / TTSS is the community / sandbox edition for us to play with TTS and, in reverse, it’s used to check a deployment before it goes live on TTI. So apart from premium but non-critical features like the NOC, they are identical.
I don’t have any nam1 TTI instances so I can’t explicitly test, but I do have applications on nam1 and I can only see it by using eu1.cloud.thethings.network and if I use that address, I can list devices but not with nam1
Worth trying eu1.cloud.thethings.network as a quick sanity check.
Maybe @KrishnaIyerEaswaran2 could comment?
Thank you for your quick reply.
When I use eu1 , my API key is not recognized. I did wonder if I could use it since my authentication to the console routes through eu1, but alas:
{
"code": 16,
"message": "error:pkg/identityserver:api_key_not_found (API key not found)",
"details": [
{
"@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
"namespace": "pkg/identityserver",
"name": "api_key_not_found",
"message_format": "API key not found",
"correlation_id": "4fa54830c9ee4903a35547bb76b491c6",
"cause": {
"namespace": "pkg/identityserver/store",
"name": "api_key_not_found",
"message_format": "api key with id `{api_key_id}` not found",
"attributes": {
"api_key_id": "Y4U44MKYESAK2OOFOD5EDKILDBT7WLQW2ULVR7Q"
},
"correlation_id": "601b5ad520d04037a7685c3d514e741b",
"code": 5
},
"code": 16
}
]
}
I used my all-areas-access-API key and as the identity server is EU1 and I’m using the EU1 endpoint that makes sense - I’ll setup one for the NAM1 application and see if that makes a difference …
Created a key for a NAM1 based application - call returns expected data if using EU1 but not NAM1
Is your key for you or for the application?
I suspect it’s for you as it’s referring to the identity server which is only EU1 - if so can you try an application key.
Thank you -
I am using my personal API key and I am an admin, added to applications as an individual, and via and all-access organization group.
The reason I did not use an application key is that the API call I was making was to return all applications that I had access to (per the API documentation).
If I use an API key generated for the application (all access rights) and request the devices associated with it, this is the result:
GET request https://nam1.cloud.thethings.network/api/v3/applications/restaurants-group/devices
{
"details": [
{
"correlation_id": "cdd828bb-3798-4ce8-8433-4ab92efca61b",
"namespace": "proxy",
"name": "404_route_not_found",
"message_format": "not found",
"@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
"attributes": {
"flags": "NR",
"cluster": "nam1.cloud.thethings.network"
}
}
],
"message": "not found"
}
Also is there a difference between {application_ids.application_id} and just {application_id}? I see them both in the documentation. Maybe I have syntax wrong?
Example: This request url follows this naming convention. (it also returns the same error message as above)
https://nam1.cloud.thethings.network/api/v3/applications/restaurants-group/rights
I may have missed a trick here. If you are on TTI, you should be using the TTI URLs prefixed with your tenant id.
So if I had a TTI instance in NAM1, the call would be to descartes.nam1.cloud.thethings.industries.
This is using my personal API key with full rights granted.
I also tried in VStudio for good measure:
This does all seem very strange - it’s not got as far as checking your API key as it’s not found the correct route.
I’m sorry, I’m out of ideas on a hacking around / forum basis. I’ll post a message on Slack to see if anyone at TTI is around to look at this. I guess this is what the extra $130/month saves you for the support plan with the NOC.
I really appreciate it, Nick. I do like this platform ALOT, but this will be a deal-breaker for long-term scalability, as you can imagine. TTI has gotten so many things right that I hope this is just a hiccup.
TBH, if you are thinking about that level of scalability, I’d actually imagine you’d have a support contract, not just for development but also in case you have an upset and need some help in a hurry.
There will be a working solution, it’s just figuring out what the magic incantation is which I can’t do without a NAM1 instance which I’d only need if I had my own devices in the Americas. I’ll ask a client if I can have a try with their NAM1 instance.
Personally I run a CLI based interface on a small VM as it’s an atomic operation unlike the main activity of adding devices via the web which is a four step process that can create a horrible tangle if it glitches part way through. I can log everything in detail and set finer levels of access control without having to mess with API keys that are all too easily passed around.
It will be a couple of days to get a test organised.
Thank you! I would have a support contact but I’m working out POCs. I have been using the platform for over a year without need for support, so engaging in a plan for this phase didn’t seem feasible.
In any case, I believe the documentation should be clear enough for a technical person to follow, and if it is actually broken, not something to be fixed on my dime! 
If only - as both consumer of docs and creator of docs, ‘stuff’ happens.
You could read the source code, but I should have a test end point by Monday, so enjoy the weather whilst you are out of the way of the fire & brimstone (snow)!
