starred/ntfy

Fork 0

mirror of https://github.com/binwiederhier/ntfy.git synced 2026-05-09 16:35:53 +02:00

[GH-ISSUE #827] Allow sending custom properties in POSTed JSON #585

New issue

Open

opened 2026-05-07 00:25:36 +02:00 by BreizhHardware · 10 comments

BreizhHardware commented

2026-05-07 00:25:36 +02:00

Owner

Originally created by @tka85 on GitHub (Aug 1, 2023).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/827

💡 Idea
When publishing a notification using JSON, it would be useful to allow sending additional custom properties which will be forwarded verbatim to the mobile front end (assuming one uses a self-hosted ntfy server and builds their own mobile app). These additional properties could be nested under the toplevel "extras" property in the POSTed JSON.

💻 Target components
This is a feature request for the ntfy server.

Example:

{
  "topic": "1234", 
  // existing properties
  "message": "foo",
  "title": "bar",
  // additional custom properties
  "extras": {
    "customField": "baz"
  }
}

Originally created by @tka85 on GitHub (Aug 1, 2023). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/827 :bulb: **Idea** When publishing a notification using JSON, it would be useful to allow sending additional custom properties which will be forwarded verbatim to the mobile front end (assuming one uses a self-hosted ntfy server and builds their own mobile app). These additional properties could be nested under the toplevel `"extras"` property in the POSTed JSON. :computer: **Target components** This is a feature request for the ntfy server. Example: ``` { "topic": "1234", // existing properties "message": "foo", "title": "bar", // additional custom properties "extras": { "customField": "baz" } } ```

BreizhHardware added the

server

enhancement

android-app

labels

2026-05-07 00:25:36 +02:00

BreizhHardware commented

2026-05-07 00:25:37 +02:00

Author

Owner

@wunter8 commented on GitHub (Aug 1, 2023):

What would be the goal of this? Why not just send a custom JSON string as the body of the notification?

@wunter8 commented on GitHub (Aug 1, 2023): What would be the goal of this? Why not just send a custom JSON string as the body of the notification?

BreizhHardware commented

2026-05-07 00:25:37 +02:00

Author

Owner

@tka85 commented on GitHub (Aug 2, 2023):

The ntfy server currently only understands predefined properties in the POSTed JSON. Added custom properties do not get forwarded to the frontend. Use case is for self-hosted nfty servers with a custom frontend that needs fields beyond the known message, title etc.

This is the relevant discussion with @binwiederhier .

@tka85 commented on GitHub (Aug 2, 2023): The ntfy server currently only understands predefined properties in the POSTed JSON. Added custom properties do not get forwarded to the frontend. Use case is for self-hosted nfty servers with a custom frontend that needs fields beyond the known `message`, `title` etc. [This](https://lemm.ee/post/2159284) is the relevant discussion with @binwiederhier .

BreizhHardware commented

2026-05-07 00:25:37 +02:00

Author

Owner

@wunter8 commented on GitHub (Aug 2, 2023):

I understand what you're asking for (and I agree with binwiederhier that it'd probably be easy to implement), but I don't understand why sending an (escaped) JSON string as the body of the message doesn't work. If you're already building a custom frontend, then you don't need to use any of ntfy's existing fields (except to get your JSON string out).

The current ntfy response looks like this:

{ 
   "id":"fajyTv5FQ0iM",
   "time":1690985276,
   "expires":1691028476,
   "event":"message",
   "topic":"test",
   "message":"testing"
}

You want to change it to this:

{ 
   "id":"fajyTv5FQ0iM",
   "time":1690985276,
   "expires":1691028476,
   "event":"message",
   "topic":"test",
   "message":"testing"
    "extras": {
        "customField": "value"
    }
}

Then, after data = resp.json(), you could access the custom value at data.extras.customField

Why not do this?

{ 
   "id":"fajyTv5FQ0iM",
   "time":1690985276,
   "expires":1691028476,
   "event":"message",
   "topic":"test",
   "message":"\"{\"message\": \"testing\", \"customField\": \"value\"}\""
}

Then, after data = resp.json().message.json(), you could access the custom value at data.customField, right?

@wunter8 commented on GitHub (Aug 2, 2023): I understand what you're asking for (and I agree with binwiederhier that it'd probably be easy to implement), but I don't understand why sending an (escaped) JSON string as the body of the message doesn't work. If you're already building a custom frontend, then you don't need to use any of ntfy's existing fields (except to get your JSON string out). The current ntfy response looks like this: ``` { "id":"fajyTv5FQ0iM", "time":1690985276, "expires":1691028476, "event":"message", "topic":"test", "message":"testing" } ``` You want to change it to this: ``` { "id":"fajyTv5FQ0iM", "time":1690985276, "expires":1691028476, "event":"message", "topic":"test", "message":"testing" "extras": { "customField": "value" } } ``` Then, after `data = resp.json()`, you could access the custom value at `data.extras.customField` Why not do this? ``` { "id":"fajyTv5FQ0iM", "time":1690985276, "expires":1691028476, "event":"message", "topic":"test", "message":"\"{\"message\": \"testing\", \"customField\": \"value\"}\"" } ``` Then, after `data = resp.json().message.json()`, you could access the custom value at `data.customField`, right?

BreizhHardware commented

2026-05-07 00:25:37 +02:00

Author

Owner

@tka85 commented on GitHub (Aug 3, 2023):

Just opened the issue because as @binwiederhier suggested
(a) this was something he had already considered doing before and
(b) the implementation is easy

Yes, what you propose would work. I'm not saying it wouldn't.
But cannibalizing the preexisting message that has very specific semantics, is a hackey workaround.

@tka85 commented on GitHub (Aug 3, 2023): Just opened the issue because as @binwiederhier suggested (a) this was something he had already considered doing before and (b) the implementation is easy Yes, what you propose would work. I'm not saying it wouldn't. But cannibalizing the preexisting `message` that has very specific semantics, is a hackey workaround.

BreizhHardware commented

2026-05-07 00:25:37 +02:00

Author

Owner

@wunter8 commented on GitHub (Aug 5, 2023):

Got it. I hope you don't feel like I am dismissing the value of your proposal. I know other people have already been sending JSON strings with custom fields as the message, so I wanted to make sure you weren't having problems with that.

And I'm sure they will also be happy to have a convenient extras field where they can put additional information instead.

I will see if I can implement this sometime this week.

@wunter8 commented on GitHub (Aug 5, 2023): Got it. I hope you don't feel like I am dismissing the value of your proposal. I know other people have already been sending JSON strings with custom fields as the `message`, so I wanted to make sure you weren't having problems with that. And I'm sure they will also be happy to have a convenient `extras` field where they can put additional information instead. I will see if I can implement this sometime this week.

BreizhHardware commented

2026-05-07 00:25:37 +02:00

Author

Owner

@tka85 commented on GitHub (Aug 6, 2023):

I don't feel like that at all. I completely understand you asking for justification esp. when it comes to feature requests. After all it is I who makes a request for your time and effort.

Much appreciated regardless of whether you go ahead with its implementation or not.

@tka85 commented on GitHub (Aug 6, 2023): I don't feel like that at all. I completely understand you asking for justification esp. when it comes to feature requests. After all it is I who makes a request for your time and effort. Much appreciated regardless of whether you go ahead with its implementation or not.

BreizhHardware commented

2026-05-07 00:25:37 +02:00

Author

Owner

@tka85 commented on GitHub (Aug 20, 2023):

@wunter8 I see the fix. Would it be possible to also get arrays to be allowed values inside the extras object?

@tka85 commented on GitHub (Aug 20, 2023): @wunter8 I see [the fix](https://github.com/wunter8/ntfy/commit/e14f3e361ff2005b84a0222e5aae31618a4c33d1). Would it be possible to also get arrays to be allowed values inside the `extras` object?

BreizhHardware commented

2026-05-07 00:25:37 +02:00

Author

Owner

@tka85 commented on GitHub (Oct 25, 2023):

Any update on this?

@tka85 commented on GitHub (Oct 25, 2023): Any update on this?

BreizhHardware commented

2026-05-07 00:25:38 +02:00

Author

Owner

@wunter8 commented on GitHub (Oct 25, 2023):

Nope. Sorry. I've been busy with work and haven't been able to finish the Android side of things yet

@wunter8 commented on GitHub (Oct 25, 2023): Nope. Sorry. I've been busy with work and haven't been able to finish the Android side of things yet

BreizhHardware commented

2026-05-07 00:25:38 +02:00

Author

Owner

@grexe commented on GitHub (Jun 9, 2025):

I would also love to see this. I need to keep track of changes on my server and send additional information to the client.
Usually the fields are called userdata which seems more specific than extras, but it's just a name.

In the meantime, I guess I'll have to abuse tags for my needs 😉

@grexe commented on GitHub (Jun 9, 2025): I would also love to see this. I need to keep track of changes on my server and send additional information to the client. Usually the fields are called `userdata` which seems more specific than `extras`, but it's just a name. In the meantime, I guess I'll have to abuse tags for my needs 😉