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 
this is now partially solved, with the new service homeassistant.reload_config_entry
Thanks Ludeeus!
allowing us to do
reload_integration:
alias: Reload integration
mode: restart
sequence:
service: homeassistant.reload_config_entry #rest_command.reload_integration
data:
entry_id: >
{% set mapper =
{'AirVisual':'37redacted105b',
'Gdacs':'05redacted2d2b18a',
'Ikea':'377028redacted11b1951',
'Ipp':'999b75bdredacted1716',
'Life360':'2a76ecredacted59e7c',
'Luftdaten Rotterdam P':'c6redacted5f1281',
'Luftdaten Rotterdam T':'016redacted625012e',
'Luftdaten Tilburg P':'9565redacted09c',
'Luftdaten Tilburg T':'8redactedbf8',
'OpenWeather':'1dd0redacted93f',
'Owntracks':'6b204redacted2a',
'Philips Hue 1':'7afredactedbc5',
'Philips Hue 2':'a4redacted731e',
'Plugwise':'474redacted12',
'Plex':'dd13eredactede05',
'Spotify':'12edredacted08',
'Synology Dsm':'fd8redacted81367',
'Weatherbit':'79ae7redacted2b5c',
'Xbox':'e8cd7bredactede6'} %}
{% set state = states('input_select.select_integration') %}
{% set id = mapper[state] if state in mapper %}
{{id}}
and
input_select:
select_integration:
name: 'Select Integration:'
options:
- AirVisual
- Gdacs
- Ikea
- Life360
- Luftdaten Roosendaal T
- Luftdaten Rotterdam P
- Luftdaten Rotterdam T
- Luftdaten Tilburg P
- Luftdaten Tilburg T
- OpenWeather
- Owntracks
- Philips Hue 1
- Philips Hue 2
- Plugwise
- Plex
- Spotify
- Synology Dsm
- Weatherbit
- Xbox
initial: Weatherbit
unfortunately we still have to find the entry_id’s manually in the .storage, but we’re half way there 
hope we will see an automatic config entry map in HA core interface at anytime, or at least an easy way of finding that, without having to scroll the .storage for the numbers. Could be nice eg on the /config/integrations page per integrations under some sort of info button?
Should one use config_entry_id from core.entity_registry or entity_id? I just did a quick test and it seems entity_id works. Looking at your post it looks like you used config_entry_id. Would be keen to know if entity_id works for you too.
Thank you, but it’s not yet clear to me.
Regarding this comment from that post:
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.
And given an example config entry from core.entity_registry:
{
"entity_id": "light.redacted_light",
"config_entry_id": "redacted",
"device_id": "redacted",
"area_id": "foyer",
"unique_id": "redacted",
"platform": "some_platform",
"name": "Redacted Light",
"icon": null,
"disabled_by": null,
"capabilities": {
"min_mireds": 111,
"max_mireds": 400,
"supported_color_modes": [
"color_temp",
"hs"
]
},
"supported_features": 19,
"device_class": null,
"unit_of_measurement": null,
"original_name": "Some Smart Bulb",
"original_icon": null
},
Is entry_id referred to above then entity_id, config_entry_id or unique_id. I’m assuming config_entry_id but want to be certain, especially since this seemed to work when I used entity_id instead.