[QUESTION] Notification - Generic Webhook - Format/Key json

[EricThi]

Question

How is formatted keys of json to notification via generic webhook.

Context / what you've tried

Hello,

I see implementation of shoutrrr but i'm using apprise-api since many years now and configured on tooooo many usages :)

I search to use webhook to push on my apprise server, and on doc of apprise, it's possible to send a similar call of shoutrrr Generic :

Apprise-api : Here is the JSON Version and tests out the Stateless query (which requires at a minimum the urls and body:

We also convert subject to title too:

curl -X POST -d '{"href": "mailto://user:pass@gmail.com", "subject":"My Title", "payload":"Body"}'
-H "Content-Type: application/json"
"http://localhost:8000/notify/{KEY}?:subject=title&:payload=body&:href=urls"

The colon : prefix is the switch that starts the re-mapping rule engine. You can do 3 possible things with the rule engine:

:existing_key=expected_key: Rename an existing (expected) payload key to one Apprise expects
:existing_key=: By setting no value, the existing key is simply removed from the payload entirely
:expected_key=A value to give it: You can also fix an expected apprise key to a pre-generated string value.

Source : https://github.com/caronc/apprise-api#third-party-webhook-support

It's "similar" but title and message keys are predefined :
Using generic://example.com?$projection=retroazimuthal would yield:

{
"title": "Amazing opportunities!",
"message": "New map book available for purchase.",
"projection": "retroazimuthal"
}

https://shoutrrr.nickfedor.com/v0.13.2/services/specialized/generic/#custom_data_fields

Idea, it's to know how pass good key on url to good format for apprise

I have tested to :
apk add curl
and after on container zerobyte :
curl -X POST
-F "body=Test Message"
-F "tags=all"
http://apprise.url/notify/mykey

It's works perfectly :)

For me, it's possible to use generic with good keys with json (or push curl and permit to use previous call ;) )
(-F attach= is not necessary here for me, last option can be used for apprise via curl)

Regards,
Eric.

[dosubot]

Hi @EricThi! I'm Dosu and I’m helping the zerobyte team.

Zerobyte's Generic Webhook supports custom JSON key mapping for exactly this use case!

When configuring the Generic Webhook, enable the JSON mode toggle. This reveals two additional fields (source):

• titleKey – set this to the key Apprise expects (e.g., subject or title)
• messageKey – set this to body for Apprise

So for your Apprise API integration, you'd configure:

• URL: http://apprise.url/notify/mykey
• Method: POST
• JSON mode: enabled
• titleKey: title (or subject depending on your Apprise config)
• messageKey: body

The form also includes a live request preview that updates as you configure it, so you can verify the JSON payload matches what Apprise expects before saving.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[EricThi]

Thank you to pointing on the format of key.

I have found a little issue on apprise, don't accept upper letter on key !
reported here : caronc/apprise-api#294

Thank you for these informations @dosu | @dosubot

If you are any tips to workaround the upper letter en key via the url :)

[dosubot]

Good news! Zerobyte's generic webhook JSON keys should already work with Apprise's lowercase requirement.

The titleKey and messageKey fields in Zerobyte are simple string inputs with no case restrictions, and the defaults are already lowercase ("title" and "message"). The JSON payload sent only contains these two keys—nothing else is hardcoded.

For Apprise, you'd configure:

• titleKey: title (already lowercase by default)
• messageKey: body (lowercase, matching what Apprise expects)

If you're still seeing uppercase keys being sent, could you share what the request preview in the Zerobyte UI shows? That would help narrow down whether the issue is on the Zerobyte side or somewhere in the Apprise key remapping.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[EricThi]

@dosu | @dosubot

See example :
/app # curl -X POST \

-F "titleKey=Mesage Title"
-F "messageKey=Message Body"
"https://my.url.com/notify/secret?:titleKey=title&:messageKey=body&tags=all"
Payload lacks minimum requirements

/app # curl -X POST \

-F "titleKey=Mesage Title"
-F "messageKey=Message Body"
"https://my.url.com/notify/secret?:titlekey=title&:messagekey=body&tags=all"
Payload lacks minimum requirements

/app # curl -X POST \

-F "titlekey=Mesage Title"
-F "messagekey=Message Body"
"https://my.url.com/notify/secret?:titlekey=title&:messagekey=body&tags=all"
2026-02-19 08:58:04,180 [INFO] apprise: Loaded 2 entries from memory://
2026-02-19 08:58:04,180 [INFO] apprise: Notifying 2 service(s) with threads.

only when all keys provides by zerobyte has lower case, it's works
excepted to patch the format of key on code, will not fix, or a workaround to pass upper letter from key to lower letter on url for apprise

[dosubot]

Thanks for the detailed test cases—that clarifies the issue!

Looking at your curl examples, the problem is that you're using titleKey and messageKey (camelCase) as the form field names in the request body. Apprise only accepts lowercase keys, so the form fields themselves need to be lowercase (e.g., titlekey and messagekey or whatever keys Apprise expects like title and body).

However, in Zerobyte's generic webhook, the titleKey and messageKey config options specify what JSON key names to use in the payload—not the parameter names themselves. When you configure titleKey = "title" and messageKey = "body" in Zerobyte, the resulting JSON sent to Apprise will use "title" and "body" as the actual keys.

For Apprise integration, try:

• titleKey: title
• messageKey: body

This should produce a JSON payload like:

{
  "title": "Your notification title",
  "body": "Your notification message"
}

If you're still having issues after configuring it this way, could you share a screenshot of your Zerobyte generic webhook configuration and the actual HTTP request/response from Zerobyte's logs? That would help determine if something unexpected is happening in the payload construction.

@nicotsx – if the user confirms the JSON keys are correct in Zerobyte config but Apprise is still rejecting them, there may be something in Shoutrrr's handling worth investigating.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[EricThi]

Ok, I found the issue "on my side" and understand when you have request screenshot, as if missed a part of configuration on my side, it's true, but, I never see it !

on the green rectangle, I never see it, because, when I tested, I change, Save et test directly, without reload page or leave configuration of notification !

It's this morning, I have logout of interface of Zerobyte and when reconnecting, I see this part of configuration !

For me, I missing a warning to reload page/leave it when some option(s) can be appear after a change or need to force reload page after save it change !

Thank you @dosu | @dosubot

[dosubot]

Glad you found it! That's a valid UX concern—when enabling the JSON toggle, the additional titleKey and messageKey fields should appear immediately without needing to reload the page.

@nicotsx – this sounds like a potential UI reactivity bug where the conditional fields for JSON mode (titleKey/messageKey) aren't rendering dynamically after the toggle is changed and saved. The user had to log out and back in to see them. Might be worth investigating whether the form state isn't updating properly after save.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[EricThi]

I have create my notification on 0.25 version, now, I'm on 0.28.2 and when create new generic webhook, Default JSON Template has selected and we can see titleKey and messageKey, but, if deselect it and save it, no change. the keys will be removed after leave page (back to all notifications for example) and click to return on notification will be configured to view the change.

A pop up can be easily warn users to relaod page or leave it (back to all notifications) after save change(s) :)

@dosu | @dosubot

[dosubot]

Thanks for the additional detail! So to summarize the issue:

After saving changes to a generic webhook notification (like toggling the JSON template on/off), the form UI doesn't immediately reflect the updated state. Users have to navigate away and come back to see the changes take effect in the form.

This is definitely a UI state refresh bug rather than a data persistence issue—the changes are being saved correctly, but the form isn't re-rendering with the updated values after save.

@nicotsx – the user is suggesting either auto-refreshing the form state after save, or adding a prompt/toast notifying users to reload. The core issue seems to be that the form's local state isn't being synced with the saved server state after a successful save operation.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}