Api/device_tracker/see 405 method not allowed

Hello all,

I am trying to integrate some airtags into homeassistnat with this method:

The trouble is that I can’t get it working because apparently the method is not allowed:

curl -X GET https://my.server/api/services/device_tracker/see -H 'Authorization: Bearer super-strong-tocken'
405: Method Not Allowed

Nothing I do seems to work. Can anyone point me in the right direction?


You call HA services with a POST, not a GET

with POST I get:

400: Bad Request

And this I get from both local network (i.e. using http://ip:8123/api/services/…) and outside network

You might need to ask the author.
You are starting with their code.

i did but they are not answering… but why does the command above have anything to do with the author? Isn’t that command what one would use in a script?

Just trying to help.
If you tried that then fine.
You may be surprised on how many people don’t think to ask questions from the source first. The source of the knowledge often provides the best answer. Streetlight Effect.

  1. Did you check the documentation I linked?
  2. What exact curl command did you execute?
  3. What errors do you see in the HA log?

@Sir_Goodenough and @koying

Thank you for your help! I tried the following curl commands:

curl -X POST https://my.server/api/service/device_tracker/see -H 'Authorization: Bearer the-token'

The answer is 400: Bad Request

Then I tried

curl -X GET https://my.server/api/services/device_tracker/see -H 'Authorization: Bearer the-token'

The answer is: 405: Method Not Allowed

I have also tested the command to see if the api is enabled with:

curl -X GET https://my.server/api/ -H 'Authorization: Bearer the-token'

The answer is: {"message":"API running."}

On the documentation page, it states that there are GET and POST actions for /api/services/

Also I don’t see anything in the logs. What should I look for? How would this error be logged?

If you checked the doc, you’d have noticed you have to pass a payload to the service, containing the actual entity_id of the device tracker.

Not sure how you thought HA would have guessed it :wink:

@koying Thank you for pointing this out! This is my first time working with the rest api and I was in really big waters!

After you pointed that out I went and dug into the findmysync program and found what it was trying to send.
Then I tried to replicate with the curl command to see where the problem was.
Couldn’t figure it out, but I kept searching and through pure coincidence I realized that it might be a problem with the Authorized header that is being sent because my HA is behind nginx reverse proxy.

Then I found this post where this user managed to overcome a similar authentication problem by passing the authorized header with the Bearer tocken directly in nginx.

So I changed it for my use case by adding to the nginx conf file the following for the api part:

    location /api {
        proxy_pass http://local.server.ip:8123/api;
        proxy_set_header Content-Type application/json;
        proxy_set_header Authorization "Bearer long-token";

Now in the FindMySync app all I had to do is fill in the host section with the server address: https://my.home.assistant.server/api/services/device_tracker/see/
and leave the authorization blank.

and it works!


I found a better (I think more secure) way to do this:

    location /api {
        proxy_pass http://local.server.ip:8123/api;
        proxy_set_header Content-Type application/json;
        if ($http_authorization != "Bearer <long-tocken>") {
        return 401;
        proxy_set_header Authorization $http_authorization;
        proxy_pass_header Authorization;

And now one has to also add the Bearer token to the FindMySync->Endpoint->Authorization header section in the form: Bearer <long-tocken>

This way, only this tocken will be accepted for this api call. I tested it by changing one letter and I got a 401 response.

Edit2: while this second version works for FindMySync appliaction, it will break access to the Addons section in HA and some other parts where there are api calls. Not sure how to fix this at the moment. I’ll keep checking.