Correct way to implement a server action with input within a dynamic notification?

Calling the notifications API with

{
    "text": "Something happens !",
    "title": "Home automation",
    "actions": [
        {
            "name" : "message someone",
            "url": "https://api.pushcut.io/_mysecret_/execute?shortcut=serverShortcut&input=my%20msg"
        }
    ]
}

works but when I click on the notification action, it opens the safari web page so it is not available on the watch.

for web requests you will need to add urlBackgroundOptions, like this:

“urlBackgroundOptions”: {“httpMethod”: “POST”}

also, I just noticed I have not updated the API documentation with the server action stuff - will be updated in a few days. you should then be able to add ‘server actions’ a lot easier in the JSON.

thanks for pointing this out.

1 Like

Ok it works perfectly.

But this means that to implement server actions I must pass my webhook secret. When triggering that kind of notification from Integromat for example, I would prefer to use only my Integromat token. Does my remark makes sense ?
If it does, we should have an additional field in urlBackgroundOptions: apiToken or httpHeader.

ok, docs are updated.

not only can you now set headers like this:

{"httpHeader": [{"key": "API-Key", "value": "your_key"}]}

but can also just set a server action as

{"name": "message", "shortcut": "serverShortcut", "runOnServer": true}
2 Likes

Ok all methods are working fine, the runOnServer is great to simplify !

One little glitch (I think):

{
    "text": "Something happens !",
    "title": "Home automation",
    "input" : "",
    "actions": [
        {
            "name" : "message someone",
            "shortcut": "serverShortcut",
            "runOnServer": true,
            "input": "action input"
        }
    ]
}

Then the serverShorcut does not receive any input. Notification input seems to have a higher priority than the Action input.
This is not important, and there is no reason to write a notification like this, but that was a leftover from previous debugging and it makes me search why I had no input…

thanks for the report.

I just real-life tested this again on my end and could not reproduce this problem. the action input always gets used as long as there is one.

the only topic I found: when the action’s input is set but empty (like ""), Pushcut falls back to the notification’s input. (ultimately showing how too much java script will poison your developer soul :weary: )

this is probably not the expected behavior, and I should fix this.

did you use an empty string for testing? if not, could you send me the exact data that causes this glitch for you?

Ok those are my steps to reproduce:
iMessageNat is a one action shortcut sending a message to someone.

When I send this notification from the pushcut api tryout it works.

{
    "text": "Garage ouvert depuis plus d'une heure",
    "title": "Jeedom",    "actions": [
        {
            "name": "Fermer le garage",
            "homekit": "Ferme Le Garage",
            "keepNotification": true
        },
        {
            "name" : "Envoyer Ă  Nathalie",
            "input": "Coucou",
            "shortcut": "iMessageNat",
            "runOnServer": true,
            "keepNotification": true
        }
    ]
}

If I had an empty input, it fails, I suppose it fails because it is not passing any input…
When I say it fails, I do receive the notication, but when choosing the Send To action, I do not receive the message and there is no failure on the Monitor Requests page.

{
    "text": "Garage ouvert depuis plus d'une heure",
    "title": "Jeedom",
    "input": "",
    "actions": [
        {
            "name": "Fermer le garage",
            "homekit": "Ferme Le Garage",
            "keepNotification": true
        },
        {
            "name" : "Envoyer Ă  Nathalie",
            "input": "Coucou",
            "shortcut": "iMessageNat",
            "runOnServer": true,
            "keepNotification": true
        }
    ]
}

ok, thanks, I will take a look.

Did I understand correctly that this is not blocking you at the moment, right?

Absolutely, no need to fix this for me