starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Extend webhook payload body to include related objects. #10862

New Issue
Open
opened 2025-12-29 21:36:53 +01:00 by adam · 4 comments
adam commented 2025-12-29 21:36:53 +01:00
Owner
Copy Link

Originally created by @sol1-matt on GitHub (Mar 10, 2025).

NetBox version

v4.2.4

Feature type

Change to existing functionality

Proposed functionality

The webhook object data payload sent is currently "equivalent to the model's representation in NetBox's REST API". The Netbox API for related objects is a stub usually containing id, name, display, slug, etc...

The proposed functionality is to extend the data available to the payload to include everything in the linked objects.

This feature is useful as it removes the need to, potentially, make multiple api calls, or a graphQL call, by an external system once it receives a webhook event to gather linked data.

Note: I say multiple api calls here because Netbox objects, in particular device and vm, have multiple linked objects

This is different from #16549 in that #16549 aims to create a condition for the webhook event being triggered based on the linked objects where as this feature request aims to make the linked object available as part of the data to send in the payload after the webhook event is triggered.

Use case

Use case 1
Sending shipping information when a device is ready for deployment.

A webhook is created that feeds into a automatic ticketing system when a device status changes alerting another team they need to deploy said device to a specific location. Adding the address details for device to the ticket would remove the need for a person to look up this info.

Note: When we did this the receiver of these tickets didn't have access to our Netbox so a human looking it up wasn't a option, the address details had to be included at ticket creation.

Use case 2
Synchronizing multiple Netbox objects with an external system.

  • Netbox is a source of truth for another external system
  • Multiple Netbox objects are synchronized to the external system so the external system can create have it's own internal objects.
  • The external system identifies the data using it's own unique ID's not existing Netbox data.
  • These external ID's are stored in Netbox as custom fields so the external system knows which Netbox object matches its own internal object.

If a device modifies its site the webhook for device is triggered sending a payload that includes the device and stub of site. The site could already exist in the external system but it wouldn't know because the site.custom_fields for the unique ID the external system isn't passed across with the device. The external system requires an api call each webhook to make sure the site exists.

If the payload did include the full site details then the external system would be able to verify the site exists because the site.custom_fields for the unique ID does exist or create it if it doesn't exist.

Database changes

None

External dependencies

None

Originally created by @sol1-matt on GitHub (Mar 10, 2025). ### NetBox version v4.2.4 ### Feature type Change to existing functionality ### Proposed functionality The webhook object data payload sent is currently ["equivalent to the model's representation in NetBox's REST API"](https://netboxlabs.com/docs/netbox/en/stable/integrations/webhooks/). The Netbox API for related objects is a stub usually containing id, name, display, slug, etc... The proposed functionality is to extend the data available to the payload to include everything in the linked objects. This feature is useful as it removes the need to, potentially, make multiple api calls, or a graphQL call, by an external system once it receives a webhook event to gather linked data. _Note: I say multiple api calls here because Netbox objects, in particular device and vm, have multiple linked objects_ This is different from #16549 in that #16549 aims to create a condition for the webhook event being triggered based on the linked objects where as this feature request aims to make the linked object available as part of the data to send in the payload after the webhook event is triggered. ### Use case **Use case 1** Sending shipping information when a device is ready for deployment. A webhook is created that feeds into a automatic ticketing system when a device status changes alerting another team they need to deploy said device to a specific location. Adding the address details for device to the ticket would remove the need for a person to look up this info. _Note: When we did this the receiver of these tickets didn't have access to our Netbox so a human looking it up wasn't a option, the address details had to be included at ticket creation._ **Use case 2** Synchronizing multiple Netbox objects with an external system. * Netbox is a source of truth for another external system * Multiple Netbox objects are synchronized to the external system so the external system can create have it's own internal objects. * The external system identifies the data using it's own unique ID's not existing Netbox data. * These external ID's are stored in Netbox as custom fields so the external system knows which Netbox object matches its own internal object. If a device modifies its site the webhook for device is triggered sending a payload that includes the device and stub of site. The site could already exist in the external system but it wouldn't know because the `site.custom_fields` for the unique ID the external system isn't passed across with the device. The external system requires an api call each webhook to make sure the site exists. If the payload did include the full site details then the external system would be able to verify the site exists because the `site.custom_fields` for the unique ID does exist or create it if it doesn't exist. ### Database changes None ### External dependencies None
adam added the type: featurenetboxstatus: backlogcomplexity: high labels 2025-12-29 21:36:53 +01:00
adam commented 2025-12-29 21:36:53 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 13, 2025):

The proposed functionality is to extend the data available to the payload to include everything in the linked objects.

To clarify, the proposal is to extend the serialized representation of the primary object to include a complete (rather than partial) representation of each related object? For example, a site is currently serialized in the webhook payload as:

Example 
"data": {
    "id": 24,
    "url": "/api/dcim/sites/24/",
    "display_url": "/dcim/sites/24/",
    "display": "Butler Communications",
    "name": "Butler Communications",
    "slug": "ncsu-128",
    "status": {
        "value": "active",
        "label": "Active"
    },
    "region": {
        "id": 40,
        "url": "/api/dcim/regions/40/",
        "display": "North Carolina",
        "name": "North Carolina",
        "slug": "us-nc",
        "description": "",
        "site_count": 0,
        "_depth": 2
    },
    "group": null,
    "tenant": {
        "id": 13,
        "url": "/api/tenancy/tenants/13/",
        "display": "NC State University",
        "name": "NC State University",
        "slug": "nc-state",
        "description": ""
    },
    "facility": "BUT",
    "time_zone": null,
    "description": "",
    "physical_address": "3210 Faucette Dr., Raleigh, NC 27607",
    "shipping_address": "",
    "latitude": null,
    "longitude": null,
    "comments": "asdads",
    "asns": [],
    "tags": [
        {
            "id": 24,
            "url": "/api/extras/tags/24/",
            "display_url": "/extras/tags/24/",
            "display": "X-ray",
            "name": "X-ray",
            "slug": "x-ray",
            "color": "9e9e9e"
        },
        {
            "id": 12,
            "url": "/api/extras/tags/12/",
            "display_url": "/extras/tags/12/",
            "display": "Lima",
            "name": "Lima",
            "slug": "lima",
            "color": "009688"
        },
        {
            "id": 7,
            "url": "/api/extras/tags/7/",
            "display_url": "/extras/tags/7/",
            "display": "Golf",
            "name": "Golf",
            "slug": "golf",
            "color": "673ab7"
        }
    ],
    "custom_fields": {},
    "created": "2021-04-02T00:00:00Z",
    "last_updated": "2025-03-13T18:47:05.811629Z"
}

The proposal here would extend tenant to its complete representation, e.g.

Example 

{
    "id": 13,
    "url": "http://netbox:8000/api/tenancy/tenants/13/",
    "display_url": "http://netbox:8000/tenancy/tenants/13/",
    "display": "NC State University",
    "name": "NC State University",
    "slug": "nc-state",
    "group": {
        "id": 1,
        "url": "http://netbox:8000/api/tenancy/tenant-groups/1/",
        "display": "Customers",
        "name": "Customers",
        "slug": "customers",
        "description": "",
        "tenant_count": 0,
        "_depth": 0
    },
    "description": "",
    "comments": "",
    "tags": [],
    "custom_fields": {
        "cust_id": ""
    },
    "created": "2021-04-02T00:00:00Z",
    "last_updated": "2021-04-02T16:46:50.851000Z",
    "circuit_count": 3,
    "device_count": 19,
    "ipaddress_count": 0,
    "prefix_count": 0,
    "rack_count": 29,
    "site_count": 4,
    "virtualmachine_count": 0,
    "vlan_count": 0,
    "vrf_count": 0,
    "cluster_count": 0
}

This may be feasible now that we have flexible nested serializers in place (as of v4.0, IIRC). However, we'll need to consider the performance impact of querying for the related objects beyond the first degree of relations.

@jeremystretch commented on GitHub (Mar 13, 2025): > The proposed functionality is to extend the data available to the payload to include everything in the linked objects. To clarify, the proposal is to extend the serialized representation of the primary object to include a complete (rather than partial) representation of each related object? For example, a site is currently serialized in the webhook payload as: <details><summary>Example</summary> ```json "data": { "id": 24, "url": "/api/dcim/sites/24/", "display_url": "/dcim/sites/24/", "display": "Butler Communications", "name": "Butler Communications", "slug": "ncsu-128", "status": { "value": "active", "label": "Active" }, "region": { "id": 40, "url": "/api/dcim/regions/40/", "display": "North Carolina", "name": "North Carolina", "slug": "us-nc", "description": "", "site_count": 0, "_depth": 2 }, "group": null, "tenant": { "id": 13, "url": "/api/tenancy/tenants/13/", "display": "NC State University", "name": "NC State University", "slug": "nc-state", "description": "" }, "facility": "BUT", "time_zone": null, "description": "", "physical_address": "3210 Faucette Dr., Raleigh, NC 27607", "shipping_address": "", "latitude": null, "longitude": null, "comments": "asdads", "asns": [], "tags": [ { "id": 24, "url": "/api/extras/tags/24/", "display_url": "/extras/tags/24/", "display": "X-ray", "name": "X-ray", "slug": "x-ray", "color": "9e9e9e" }, { "id": 12, "url": "/api/extras/tags/12/", "display_url": "/extras/tags/12/", "display": "Lima", "name": "Lima", "slug": "lima", "color": "009688" }, { "id": 7, "url": "/api/extras/tags/7/", "display_url": "/extras/tags/7/", "display": "Golf", "name": "Golf", "slug": "golf", "color": "673ab7" } ], "custom_fields": {}, "created": "2021-04-02T00:00:00Z", "last_updated": "2025-03-13T18:47:05.811629Z" } ``` </details> The proposal here would extend `tenant` to its complete representation, e.g. <details><summary>Example</summary> ```json { "id": 13, "url": "http://netbox:8000/api/tenancy/tenants/13/", "display_url": "http://netbox:8000/tenancy/tenants/13/", "display": "NC State University", "name": "NC State University", "slug": "nc-state", "group": { "id": 1, "url": "http://netbox:8000/api/tenancy/tenant-groups/1/", "display": "Customers", "name": "Customers", "slug": "customers", "description": "", "tenant_count": 0, "_depth": 0 }, "description": "", "comments": "", "tags": [], "custom_fields": { "cust_id": "" }, "created": "2021-04-02T00:00:00Z", "last_updated": "2021-04-02T16:46:50.851000Z", "circuit_count": 3, "device_count": 19, "ipaddress_count": 0, "prefix_count": 0, "rack_count": 29, "site_count": 4, "virtualmachine_count": 0, "vlan_count": 0, "vrf_count": 0, "cluster_count": 0 } ``` </details> This may be feasible now that we have flexible nested serializers in place (as of v4.0, IIRC). However, we'll need to consider the performance impact of querying for the related objects beyond the first degree of relations.
adam commented 2025-12-29 21:36:53 +01:00
Author
Owner
Copy Link

@sol1-matt commented on GitHub (Mar 14, 2025):

To clarify, the proposal is to extend the serialized representation of the primary object to include a complete (rather than partial) representation of each related object? For example, a site is currently serialized in the webhook payload as:

Correct @jeremystretch. Our specific use case is use case 2, to get the custom fields from a site when a device is updated.

However, we'll need to consider the performance impact of querying for the related objects beyond the first degree of relations.

I agree it needs thought.

If you just did first child then you aren't going have the children of children, but is that a problem?

eg: In the first child example below we don't have the full tenant.group and I can't see an argument for needing it because groups don't really have many fields.

If the nested groups are followed what is the cost and could we get into the situation where we create a loop.

First child example 
"data": {
    "id": 24,
    "url": "/api/dcim/sites/24/",
    "display_url": "/dcim/sites/24/",
    "display": "Butler Communications",
    "name": "Butler Communications",
    "slug": "ncsu-128",
    "status": {
        "value": "active",
        "label": "Active"
    },
    "region": {
        "id": 40,
        "url": "/api/dcim/regions/40/",
        "display": "North Carolina",
        "name": "North Carolina",
        "slug": "us-nc",
        "description": "",
        "site_count": 0,
        "_depth": 2
    },
    "group": null,
    "tenant": {
        "id": 13,
        "url": "http://netbox:8000/api/tenancy/tenants/13/",
        "display_url": "http://netbox:8000/tenancy/tenants/13/",
        "display": "NC State University",
        "name": "NC State University",
        "slug": "nc-state",
        "group": {
            "id": 1,
            "url": "http://netbox:8000/api/tenancy/tenant-groups/1/",
            "display": "Customers",
            "name": "Customers",
            "slug": "customers",
            "description": "",
            "tenant_count": 0,
            "_depth": 0
        },
        "description": "",
        "comments": "",
        "tags": [],
        "custom_fields": {
            "cust_id": ""
        },
        "created": "2021-04-02T00:00:00Z",
        "last_updated": "2021-04-02T16:46:50.851000Z",
        "circuit_count": 3,
        "device_count": 19,
        "ipaddress_count": 0,
        "prefix_count": 0,
        "rack_count": 29,
        "site_count": 4,
        "virtualmachine_count": 0,
        "vlan_count": 0,
        "vrf_count": 0,
        "cluster_count": 0
    },
    "facility": "BUT",
    "time_zone": null,
    "description": "",
    "physical_address": "3210 Faucette Dr., Raleigh, NC 27607",
    "shipping_address": "",
    "latitude": null,
    "longitude": null,
    "comments": "asdads",
    "asns": [],
    "tags": [
        {
            "id": 24,
            "url": "/api/extras/tags/24/",
            "display_url": "/extras/tags/24/",
            "display": "X-ray",
            "name": "X-ray",
            "slug": "x-ray",
            "color": "9e9e9e"
        },
        {
            "id": 12,
            "url": "/api/extras/tags/12/",
            "display_url": "/extras/tags/12/",
            "display": "Lima",
            "name": "Lima",
            "slug": "lima",
            "color": "009688"
        },
        {
            "id": 7,
            "url": "/api/extras/tags/7/",
            "display_url": "/extras/tags/7/",
            "display": "Golf",
            "name": "Golf",
            "slug": "golf",
            "color": "673ab7"
        }
    ],
    "custom_fields": {},
    "created": "2021-04-02T00:00:00Z",
    "last_updated": "2025-03-13T18:47:05.811629Z"
}

I'll put some time in to see if I can find example where children beyond the first child provide more information.

One thought I had when looking at this problem originally was "it would be nice if we could specify the object we send using something like graphQL".

@sol1-matt commented on GitHub (Mar 14, 2025): > To clarify, the proposal is to extend the serialized representation of the primary object to include a complete (rather than partial) representation of each related object? For example, a site is currently serialized in the webhook payload as: Correct @jeremystretch. Our specific use case is use case 2, to get the custom fields from a site when a device is updated. > However, we'll need to consider the performance impact of querying for the related objects beyond the first degree of relations. I agree it needs thought. If you just did first child then you aren't going have the children of children, but is that a problem? eg: In the first child example below we don't have the full `tenant.group` and I can't see an argument for needing it because groups don't really have many fields. If the nested groups are followed what is the cost and could we get into the situation where we create a loop. <details> <summary>First child example</summary> ``` "data": { "id": 24, "url": "/api/dcim/sites/24/", "display_url": "/dcim/sites/24/", "display": "Butler Communications", "name": "Butler Communications", "slug": "ncsu-128", "status": { "value": "active", "label": "Active" }, "region": { "id": 40, "url": "/api/dcim/regions/40/", "display": "North Carolina", "name": "North Carolina", "slug": "us-nc", "description": "", "site_count": 0, "_depth": 2 }, "group": null, "tenant": { "id": 13, "url": "http://netbox:8000/api/tenancy/tenants/13/", "display_url": "http://netbox:8000/tenancy/tenants/13/", "display": "NC State University", "name": "NC State University", "slug": "nc-state", "group": { "id": 1, "url": "http://netbox:8000/api/tenancy/tenant-groups/1/", "display": "Customers", "name": "Customers", "slug": "customers", "description": "", "tenant_count": 0, "_depth": 0 }, "description": "", "comments": "", "tags": [], "custom_fields": { "cust_id": "" }, "created": "2021-04-02T00:00:00Z", "last_updated": "2021-04-02T16:46:50.851000Z", "circuit_count": 3, "device_count": 19, "ipaddress_count": 0, "prefix_count": 0, "rack_count": 29, "site_count": 4, "virtualmachine_count": 0, "vlan_count": 0, "vrf_count": 0, "cluster_count": 0 }, "facility": "BUT", "time_zone": null, "description": "", "physical_address": "3210 Faucette Dr., Raleigh, NC 27607", "shipping_address": "", "latitude": null, "longitude": null, "comments": "asdads", "asns": [], "tags": [ { "id": 24, "url": "/api/extras/tags/24/", "display_url": "/extras/tags/24/", "display": "X-ray", "name": "X-ray", "slug": "x-ray", "color": "9e9e9e" }, { "id": 12, "url": "/api/extras/tags/12/", "display_url": "/extras/tags/12/", "display": "Lima", "name": "Lima", "slug": "lima", "color": "009688" }, { "id": 7, "url": "/api/extras/tags/7/", "display_url": "/extras/tags/7/", "display": "Golf", "name": "Golf", "slug": "golf", "color": "673ab7" } ], "custom_fields": {}, "created": "2021-04-02T00:00:00Z", "last_updated": "2025-03-13T18:47:05.811629Z" } ``` </details> I'll put some time in to see if I can find example where children beyond the first child provide more information. One thought I had when looking at this problem originally was _"it would be nice if we could specify the object we send using something like graphQL"_.
adam commented 2025-12-29 21:36:54 +01:00
Author
Owner
Copy Link

@sol1-matt commented on GitHub (Mar 20, 2025):

Cable terminations have nested results related to the termination itself. The termination object contains both a device and cable.

Cable Termination example 
        {
            "id": 1,
            "url": "https://netbox.example/api/dcim/cable-terminations/1/",
            "display": "Cable 1 to Port 49",
            "cable": 3,
            "cable_end": "A",
            "termination_type": "dcim.interface",
            "termination_id": 701,
            "termination": {
                "id": 701,
                "url": "https://netbox.example/api/dcim/interfaces/701/",
                "display": "Port 49",
                "device": {
                    "id": 195,
                    "url": "https://netbox.example/api/dcim/devices/195/",
                    "display": "RightSwitch1",
                    "name": "RightSwitch1",
                    "description": ""
                },
                "name": "Port 49",
                "description": "",
                "cable": {
                    "id": 3,
                    "url": "https://netbox.example/api/dcim/cables/3/",
                    "display": "1",
                    "label": "1",
                    "description": ""
                },
                "_occupied": true
            },
            "created": "2023-06-30T04:18:08.166610Z",
            "last_updated": "2023-06-30T04:18:08.362391Z"
        },

Cables also have deeply nested objects. A termination has a linked object.

Cable example 
 {
            "id": 3,
            "url": "https://netbox.sol1.net/api/dcim/cables/3/",
            "display_url": "https://netbox.sol1.net/dcim/cables/3/",
            "display": "1",
            "type": "smf",
            "a_terminations": [
                {
                    "object_type": "dcim.interface",
                    "object_id": 701,
                    "object": {
                        "id": 701,
                        "url": "https://netbox.example/api/dcim/interfaces/701/",
                        "display": "Port 49",
                        "device": {
                            "id": 195,
                            "url": "https://netbox.example/api/dcim/devices/195/",
                            "display": "RightSwitch1",
                            "name": "RightSwitch1",
                            "description": ""
                        },
                        "name": "Port 49",
                        "description": "",
                        "cable": {
                            "id": 3,
                            "url": "https://netbox.example/api/dcim/cables/3/",
                            "display": "1",
                            "label": "1",
                            "description": ""
                        },
                        "_occupied": true
                    }
                }
            ],
            "b_terminations": [
                {
                    "object_type": "dcim.interface",
                    "object_id": 637,
                    "object": {
                        "id": 637,
                        "url": "https://netbox.sol1.net/api/dcim/interfaces/637/",
                        "display": "Port 1",
                        "device": {
                            "id": 194,
                            "url": "https://netbox.example/api/dcim/devices/194/",
                            "display": "Right Switch",
                            "name": "Right Switch",
                            "description": ""
                        },
                        "name": "Port 1",
                        "description": "",
                        "cable": {
                            "id": 3,
                            "url": "https://netbox.example/api/dcim/cables/3/",
                            "display": "1",
                            "label": "1",
                            "description": ""
                        },
                        "_occupied": true
                    }
                }
            ],
            "status": {
                "value": "connected",
                "label": "Connected"
            },
            "tenant": null,
            "label": "1",
            "color": "00ffff",
            "length": 1.0,
            "length_unit": {
                "value": "m",
                "label": "Meters"
            },
            "description": "",
            "comments": "",
            "tags": [],
            "custom_fields": {},
            "created": "2019-03-11T00:00:00Z",
            "last_updated": "2019-03-11T03:22:46.127163Z"
        },

If the option to improve webhooks is to load first level objects only then perhaps a good definition of first level would be

any object that is referenced in the original objects "equivalent to the model's representation in NetBox's REST API"

@sol1-matt commented on GitHub (Mar 20, 2025): Cable terminations have nested results related to the termination itself. The termination object contains both a device and cable. <details> <summary>Cable Termination example</summary> ``` { "id": 1, "url": "https://netbox.example/api/dcim/cable-terminations/1/", "display": "Cable 1 to Port 49", "cable": 3, "cable_end": "A", "termination_type": "dcim.interface", "termination_id": 701, "termination": { "id": 701, "url": "https://netbox.example/api/dcim/interfaces/701/", "display": "Port 49", "device": { "id": 195, "url": "https://netbox.example/api/dcim/devices/195/", "display": "RightSwitch1", "name": "RightSwitch1", "description": "" }, "name": "Port 49", "description": "", "cable": { "id": 3, "url": "https://netbox.example/api/dcim/cables/3/", "display": "1", "label": "1", "description": "" }, "_occupied": true }, "created": "2023-06-30T04:18:08.166610Z", "last_updated": "2023-06-30T04:18:08.362391Z" }, ``` </details> Cables also have deeply nested objects. A termination has a linked object. <details> <summary>Cable example</summary> ``` { "id": 3, "url": "https://netbox.sol1.net/api/dcim/cables/3/", "display_url": "https://netbox.sol1.net/dcim/cables/3/", "display": "1", "type": "smf", "a_terminations": [ { "object_type": "dcim.interface", "object_id": 701, "object": { "id": 701, "url": "https://netbox.example/api/dcim/interfaces/701/", "display": "Port 49", "device": { "id": 195, "url": "https://netbox.example/api/dcim/devices/195/", "display": "RightSwitch1", "name": "RightSwitch1", "description": "" }, "name": "Port 49", "description": "", "cable": { "id": 3, "url": "https://netbox.example/api/dcim/cables/3/", "display": "1", "label": "1", "description": "" }, "_occupied": true } } ], "b_terminations": [ { "object_type": "dcim.interface", "object_id": 637, "object": { "id": 637, "url": "https://netbox.sol1.net/api/dcim/interfaces/637/", "display": "Port 1", "device": { "id": 194, "url": "https://netbox.example/api/dcim/devices/194/", "display": "Right Switch", "name": "Right Switch", "description": "" }, "name": "Port 1", "description": "", "cable": { "id": 3, "url": "https://netbox.example/api/dcim/cables/3/", "display": "1", "label": "1", "description": "" }, "_occupied": true } } ], "status": { "value": "connected", "label": "Connected" }, "tenant": null, "label": "1", "color": "00ffff", "length": 1.0, "length_unit": { "value": "m", "label": "Meters" }, "description": "", "comments": "", "tags": [], "custom_fields": {}, "created": "2019-03-11T00:00:00Z", "last_updated": "2019-03-11T03:22:46.127163Z" }, ``` </details> If the option to improve webhooks is to load first level objects only then perhaps a good definition of first level would be _any object that is referenced in the original objects ["equivalent to the model's representation in NetBox's REST API"](https://netboxlabs.com/docs/netbox/en/stable/integrations/webhooks/)_
adam commented 2025-12-29 21:36:54 +01:00
Author
Owner
Copy Link

@ravenrs commented on GitHub (Jul 4, 2025):

@jeremystretch could you please assign this issue to me, I think it's very usefull for everyone as for me, because now I want to send updates to external system only when device's tenant of interface equals to specific one, it will drop huge amount of unnecessary data. I want to try make it by "field" attribute of nasted dict, I don't think that we a relly need to get all serialized data of child object, but if we have path in condition, for example for my case it will be - device.tenant.name it can add only needed info for device serializer and brief for tenant or exactly value by path - device.tenant.name ( need to think about it). So I think it will be used the same approach, to add additional information to webhook by body template extend.

@ravenrs commented on GitHub (Jul 4, 2025): @jeremystretch could you please assign this issue to me, I think it's very usefull for everyone as for me, because now I want to send updates to external system only when device's tenant of interface equals to specific one, it will drop huge amount of unnecessary data. I want to try make it by "field" attribute of nasted dict, I don't think that we a relly need to get all serialized data of child object, but if we have path in condition, for example for my case it will be - device.tenant.name it can add only needed info for device serializer and brief for tenant or exactly value by path - device.tenant.name ( need to think about it). So I think it will be used the same approach, to add additional information to webhook by body template extend.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label complexity: high netbox status: backlog type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#10862
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?