Provide a mechanism for plugins to attach arbitrary context to outgoing webhooks #11438

New Issue

adam · 2025-12-29T21:45:14+01:00

adam commented

2025-12-29 21:45:14 +01:00

Originally created by @jeremystretch on GitHub (Aug 1, 2025).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v4.3.5

Feature type

New functionality

Proposed functionality

Implement a mechanism by which plugins can contribute additional data to outbound webhooks generated in response to an event rule. This mechanism would enable a plugin to register a callback function to be called whenever a webhook is being generated. The callback would accept the object and current request, and return any data to be included in the webhook's payload.

Something like this:

@webhook_data(models=(Site, Location))
def my_plugins_callback(instance, request):
    if instance.tenant is not None:
        return {
            'billing_id': Customer.objects.get(tenant=instance.tenant)
        }

Any data returned by the callback will be attached to the webhook payload, e.g. within a context key on the JSON object root. (An empty response will be ignored.)

This should be implemented in a way so as not to break the current format of a webhook payload.

Use case

One example where this would be useful is in the netbox-branching plugin, where it would be helpful to attach the branch in which a change is being made as context. (See netboxlabs/netbox-branching#132 for some discussion around this use case.) However, it's not difficult to image other scenarios where this would be convenient.

Database changes

N/A

External dependencies

N/A

Originally created by @jeremystretch on GitHub (Aug 1, 2025). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v4.3.5 ### Feature type New functionality ### Proposed functionality Implement a mechanism by which plugins can contribute additional data to outbound webhooks generated in response to an event rule. This mechanism would enable a plugin to register a callback function to be called whenever a webhook is being generated. The callback would accept the object and current request, and return any data to be included in the webhook's payload. Something like this: ```python @webhook_data(models=(Site, Location)) def my_plugins_callback(instance, request): if instance.tenant is not None: return { 'billing_id': Customer.objects.get(tenant=instance.tenant) } ``` Any data returned by the callback will be attached to the webhook payload, e.g. within a `context` key on the JSON object root. (An empty response will be ignored.) This should be implemented in a way so as not to break the current format of a webhook payload. ### Use case One example where this would be useful is in the netbox-branching plugin, where it would be helpful to attach the branch in which a change is being made as context. (See netboxlabs/netbox-branching#132 for some discussion around this use case.) However, it's not difficult to image other scenarios where this would be convenient. ### Database changes N/A ### External dependencies N/A

adam added the status: accepted type: feature topic: plugins complexity: medium labels 2025-12-29 21:45:14 +01:00

adam closed this issue

2025-12-29 21:45:15 +01:00

adam commented

2025-12-29 21:45:15 +01:00

@jnovinger commented on GitHub (Aug 4, 2025):

My only concerns here are about making sure we don't allow this to disrupt normal core behavior:

Should we set a timeout, in case the plugin does something really ugly, like call really slow, outside APIs? At a minimum, we should definitely wrap this in a try-except.
How do we/can we even ensure there's not data leakage? Or is that something we shouldn't ensure, given it would be part of the plugin API?
How do we make sure this doesn't break existing webhook payloads? Use some sort of namespacing to insert it?

@jnovinger commented on GitHub (Aug 4, 2025): My only concerns here are about making sure we don't allow this to disrupt normal core behavior: - Should we set a timeout, in case the plugin does something really ugly, like call really slow, outside APIs? At a minimum, we should definitely wrap this in a try-except. - How do we/can we even ensure there's not data leakage? Or is that something we shouldn't ensure, given it would be part of the plugin API? - How do we make sure this doesn't break existing webhook payloads? Use some sort of namespacing to insert it?

adam referenced this issue

2025-12-29 23:20:49 +01:00

[PR #11439] [MERGED] Fixes #11438 - Get the queue from QUEUE_MAPPINGS when deleting JobResults #13790

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#11438