Disable notifications when using API

[ecomsilio]

Hi,

I am using the API route PUT /api/v1/tickets/[ticket-id] to update some objects in a ticket. This works as intended. The only issue is that every colleague gets a notification of the change, which is not needed in this special case.

I don’t get any notifications for these changes since the API is using my personal API token. My colleagues get the notifications since they own the ticket but it is my user/my token that is used for the API calls.

It is impossible to have a separate API token that gets used depending on the ticket owner.

Disabling notifications is not a solution since it my colleagues would then not get notified of any changes in the ticket.

So I am looking for the following:

1. Have a setting at “User Profile > Notifications” where you can exclude notifications for changes/updates etc. made by the API. So each user can decide if they wish notifications for these type of changes or not.

2. Have some kind of parameter that I can add to my API calls to disable the notifications.

I have tested what happens when I add something like this to the payload but that doesn’t work:

{
"object A ": “blabla”,
“object B”: “blabla”,
“disable_notification”: true
}

Is there already a way to add some parameter to the API?
If not, what do you think? Worth to add a feature request?

Thanks,
Gijs

[MrGeneration]

I asked internally for you to make sure to not put you down some bumpy road.
It seems Zammad doesn’t yet support this kind of payload-addition.

Personally I would see this as a useful addition. Possibly within a preferences: {} attribute scope. Other wise you might collide with existing attributes of a ticket.

[ecomsilio]

@MrGeneration

Possibly within a preferences: {} attribute scope. Other wise you might collide with existing attributes of a ticket.

Yes, that I think is the best option. Do I need to create a feature request on Github or is this already implemented in the next release

[MrGeneration]

Apart from us generally not communicating ETA’s or roadmaps - I think a FR would be the best approach if you need it like now.

[ecomsilio]

No worries. It is not urgent, just nice to have. I will create a FR on Github.
Thanks a lot!

[ecomsilio]

Hmm, not as easy as I thought it would be. I can’t create a FR on Github, only Bugreports. The template for bugs doesn’t make sense for a feature request. If I need some “special role”, please let me know.

[MrGeneration]

Oh sorry I thought you’d create a pull request.
Feature requests should be posted on this forum: Feature requests - Zammad - Community

My bad sorry.

[ecomsilio]

Hi @MrGeneration

could you move this topic to the #stuff-you-like-zammad-to-have-feel-free-to-discuss-and-add-proposals categoy? I guess, it doens’t make sense to open a duplicate topic.

Thanks a lot,
Gijs

[MrGeneration]

I’m not the biggest fan of technical question flavored feature requests. Especially because those kind of threads tend to be messy in terms of overview.

Anyway. I switched it.

[YetAnotherGerrit]

1. What is your original issue/pain point you want to solve?
   I want to make calculations in a ticket with a 3rd-party-solution via webhook/API.

2. Which are one or two concrete situations where this problem hurts the most?
   In this case, calculate costs based of accounted time and a hourly rate from an external database. And the PUT /api/v1/tickets/<id>-call is firing agent notifications, even though this “change” is just a calculation result of a previous ticket update.

3. Why is it not solvable with the Zammad standard?
   There is no way to surpress agent notification on API-updates:
   Update Ticket using rest api while suppressing notifications - Technical assistance - Zammad - Community

4. What is your expectation/what do you want to achieve?
   Preventing double notifications.

[bolemo]

I have the exact same need.

I have created a custom boolean object/attribute for tickets in Zammad to know if some tickets have been processed by an external process using API (the API is basically putting the custom attribute to true once the ticket has been processed, to keep track of what have been processed and to not reprocess it again and again).

As I understand it, changing the state of an attribute/object using API (or even from GUI) is considered as an update to the ticket (Exclude item in ticket notification - #5 by Christian.Wenzl) and triggers all registered agent notifications for updates (update:XXX)

So the ability to…

• make a silent update via API,
• or exclude a specific custom (or not) object state change to trigger an update,

… is really needed and missing here!

Thank you.

[bolemo]

BTW, for info there is a similar Feature Request: Disable notifications when using API

[jsuchal]

@bolemo

or exclude a specific custom (or not) object state change to trigger an update,

Disclaimer: I am not a Zammad developer, but getting my hands dirty with zammad source code lately.

I’ve looked into this, since we need this and probably found a way to do this.

The path to do this is

1. This calculates changes for a notification - if there are none, notification is discarded. zammad/app/models/transaction/notification.rb at develop · zammad/zammad · GitHub
2. It’s calculated using allowed_attributes here zammad/app/models/concerns/checks_human_changes.rb at develop · zammad/zammad · GitHub
3. Getting data from ObjectManager::Attribute - this contains attribute configuration from admin. zammad/app/models/concerns/checks_human_changes.rb at develop · zammad/zammad · GitHub

So my idea would be to extend custom core objects attribute settings with something like skip_notification boolean flag and the rest is quite easy.

I can look into this if anybody from Core team confirms this sounds good and there is not a caveat ahead I don’t see yet.

[r-weigelt_ramicro]

We absolutely need this feature!

We use a direct GitHub integration that automatically updates ticket statuses based on repository activity – for example, when branches are merged or pull requests are closed. These updates trigger notifications to agents, even though they are fully automated and don’t require manual attention.

What we need:

• A way to suppress notifications when ticket updates are made via the API – without disabling important notifications for manual changes made by team members.
• This could be achieved either through a payload flag like "disable_notification": true or
• a user-level setting such as “Don’t notify me of API-based changes” that can be toggled individually.

Why this is critical:

• Currently, the API uses a personal token (e.g., mine), so I don’t receive notifications – but the actual ticket owners do.
• It’s not possible to dynamically switch the API token depending on the ticket owner.
• As a result, our support agents are flooded with irrelevant system updates, which harms productivity and makes it harder to spot meaningful changes.

Bottom line: Please consider implementing this feature. It’s essential for any DevOps or CI/CD environment where automated processes interact with tickets. Without it, notifications quickly become noise.