yes, it does, I use it for many other rest sensors too. Also I have tried it with the full token in the config, with the same result.
but wait, what do you say now:
? it should not contain the config entry shouldn’t it, it should contain the bearer token…?
Sorry, my bad. Of course the bearer token. But also the word bearer in front of it.
ok no worries, and yes, I have Bearer included
shell_command:
shark_restart: "/usr/bin/curl -X 'POST' -H 'authorization: Bearer <token>' http://localhost:8123/api/config/config_entries/entry/b11d6ff3d1b17655fcba7649d1703d70/reload"
alias: SharkIQ
description: ''
trigger:
- platform: state
entity_id: vacuum.baby_shark
to: unavailable
for: '00:05:00'
condition: []
action:
- service: shell_command.shark_restart
data: {}
mode: single
Does the job for me (where <token> is long lived token I’ve generated in profile section)
@dmatora: any ideas what I am doing wrong as this is not working? I would guess it has to do with my https URL or the fact that I am on Ubuntu with a supervised install? Thanks.
shell_command:
shark_restart: "/usr/bin/curl -X 'POST' -H 'authorization: Bearer eyJ0eXAiOiJKV1QiLCJhNhNTU5Mjg5OSIsImlhdCI6MTYxMDM5MDcyMywiZXhwIjoxOTI1NzUwNzIzfQ.51pmUUiCAuYLNuIKVRrYVZ2bVBsd7eijkbfPhEPO3jY' https://192.168.1.57:8123/api/config/config_entries/entry/fbf820a4e4e76b9fa/reload"
All codes have been replaced by dummy ones.
I would suggest to install ssh addon, run your command in terminal in sidebar and see what is it complaining about. Otherwise I would try
how exactly do we do that?
Click Reload on integration settings while checking Network tab on Chrome inspector
thx, so reloading IKEA Tradfri results in this:
what does that teach me on the integration id to use in the shell_command?
Click on network request line and check request url
thanks, though still somewhat confused because I dont see a ‘network request line’, a column called ‘Name’ is displayed, in which a line ‘reload’ appears upon reloading…
clicking reload, makes the right field show General, Response headers, and Request headers. Under General, I can see the Request URL, under Response headers the content-type is shown, and under Request Headers the authorization is displayed.
Which makes it possible indeed to collect all necessary field for the rest_command:
rest_command:
reload_ikea:
url: https://mydomain.duckdns.org:port/api/config/config_entries/entry/3770284redacted51/reload
method: POST
headers:
authorization: !secret api_bearer_token
content-type: application/json
Also, the post by @Henk72 contains 1 significant typo, that caused my mishaps unto now 
the [Config Entry] should be the data in the top line, ‘entry_id’ field in the config/.storage/core.config_entries and not the Identity field.
thanks!
update
to make it a bit more flexible, I use a template in the rest_command url (stored in secrets) and an input_select:
select_integration:
name: 'Select Integration:'
options:
- Gdacs
- Ikea
- Ipp
- Life360
- Luftdaten Rotterdam P
- Luftdaten Rotterdam T
- Luftdaten Tilburg P
- Luftdaten Tilburg T
- Owntracks
- Philips Hue 1
- Philips Hue 2
- Plugwise
- Plex
- Synology Dsm
- Weatherbit
initial: Weatherbit
and:
script:
reload_integration:
alias: Reload integration
mode: restart
sequence:
service: rest_command.reload_integration
data:
entry_id: >
{% set mapper =
{'Gdacs':'058redacted18a',
'Ikea':'37redacted1951',
'Ipp':'99redacted716',
'Life360':'2aredactede7c',
'Luftdaten Rotterdam P':'c6aredacted1',
'Luftdaten Rotterdam T':'01redacted12e',
'Luftdaten Tilburg P':'9redacted09c',
'Luftdaten Tilburg T':'85redacted1bf8',
'Owntracks':'6b2042redacted22a',
'Philips Hue 1':'7afbredactedc5',
'Philips Hue 2':'aredacted31e',
'Plugwise':'474redacted412',
'Plex':'dd13e18redacted4e05',
'Synology Dsm':'fd8redacted367',
'Weatherbit':'79aredacted5c'} %}
{% set state = states('input_select.select_integration') %}
{% set id = mapper[state] if state in mapper %}
{{id}}
rest_command:
reload_integration:
url: !secret reload_integration_url #https://mydomain.duckdns.org:port/api/config/config_entries/entry/37redacted1951/reload
method: POST
headers:
authorization: !secret api_bearer_token
content-type: application/json
payload: >
{{entry_id}}
in secrets, have the url be:
reload_integration_url: https://mydomain.org:port/api/config/config_entries/entry/{{entry_id}}/reload
Lovelace:
input_select.select_integration:
templates:
entity_picture: >
var path = '/local/images/integrations/';
return state.includes('Luftdaten')
? path + 'luftdaten.png'
: state.includes('Philips') ? path + 'hue.png'
: path + state.toLowerCase() + '.png';
only thing is I dont see a confirmation box yet, so not sure if everything works 
no errors either
update
can confirm the above setup to work meanwhile, so for the time being this will do.
If you are using tasker and autoinput for android there is also another way - just open the browser with URL of the integrations page and have autoinput click the dots and then reload button. I have a dedicated old phone for this and other autoinput actions, works every time.
Just checking, you all know that what you are doing here is not reloading an integration as the OP states, but reloading individual config entries right?
And you are aware that a single integration can have multiple config entries?
yes I know, that’s why I have multiple entries eg for the Luftdaten integration in my setup above.
would that matter for the feature request? I suppose that could be precized with an extra config option in a data field?
It would be so welcome if core would have the requested service integration.reload, opposed to the fiddling with shell_commands and scripts we now need to undertake
btw, on the integrations containing multiple entries, the button ‘reload integration’ only appears on these individual entries, not in the main integrations. So my request would completely align with that setup.
+1 to reloading integrations via automation . Home Connect (Bosch) is buggy for me atm, it would need some kind of reauthorization after being online for a while, but its entities are just not updating. But if I reload the integration, all is good. So, to be able to automate this every few hours or something would be nice.
nice, testing this out with TPLink, thank you!
cant seem to get this working…
rest_command:
reload_tplink:
url: http://homeassistantssd.local:8123/api/config/config_entries/entry/xxxx/reload
method: POST
headers:
authorization: 'Bearer xxxxx'
content-type: application/json
2021-02-11 18:41:31 ERROR (MainThread) [homeassistant.components.rest_command] Client error http://homeassistantssd.local:8123/api/config/config_entries/entry/xxxxx/reload
The reload REST API doesn’t seem to be working all the time. It’s not executing a fully reload. Whenever I saw a TP-LINK switch that’s not responding, executing REST call to reload the integration won’t help. But if I go to the integration web page to click reload TP-LINK integration manually, it will fix the problem.
Unfortunately, nobody replied to you on that github issue 