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

Return the "request ID" change number when we do an API call #5983

New Issue
Closed
opened 2025-12-29 19:35:10 +01:00 by adam · 8 comments
adam commented 2025-12-29 19:35:10 +01:00
Owner
Copy Link

Originally created by @apo51 on GitHub (Jan 21, 2022).

NetBox version

v3.0.7

Feature type

Change to existing functionality

Proposed functionality

Hello

When a change is done (PUT POST or DELETE) in Netbox via API, we would like to get the "request ID" change number in return.

Using it, it would be possible to do a rollback of a specific API call, especially when a change implies several changes logs :
image
image

Today we didn't find a way to associate an API call with a specific request ID (we only have the "time" but if we have 2 API calls really close, we don't know which one to pick in our pipelines)
I didn't see any changes on this behavior in Netbox 3.1 in the datasheets (correct me if I'm wrong).

Thank you

Use case

When we do a change using the API, it would be very simple to retrieve all the changes done via the "request ID" and rollback them if necessary.

Database changes

No response

External dependencies

No response

Originally created by @apo51 on GitHub (Jan 21, 2022). ### NetBox version v3.0.7 ### Feature type Change to existing functionality ### Proposed functionality Hello When a change is done (PUT POST or DELETE) in Netbox via API, we would like to get the "request ID" change number in return. Using it, it would be possible to do a rollback of a specific API call, especially when a change implies several changes logs : ![image](https://user-images.githubusercontent.com/31479564/150507313-5bc0718c-b698-4ca5-ba59-a5649a599f76.png) ![image](https://user-images.githubusercontent.com/31479564/150507564-c1d05356-d52b-4644-a744-45c9d0fa6355.png) Today we didn't find a way to associate an API call with a specific request ID (we only have the "time" but if we have 2 API calls really close, we don't know which one to pick in our pipelines) I didn't see any changes on this behavior in Netbox 3.1 in the datasheets (correct me if I'm wrong). Thank you ### Use case When we do a change using the API, it would be very simple to retrieve all the changes done via the "request ID" and rollback them if necessary. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurepending closurestatus: under review labels 2025-12-29 19:35:10 +01:00
adam closed this issue 2025-12-29 19:35:10 +01:00
adam commented 2025-12-29 19:35:12 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 21, 2022):

Disregarding for the moment the feasibility of securing the request ID for the response, how would you return the request ID? We probably want to avoid injecting into the actual API data to avoid a breaking change; would an HTTP header suffice?

@jeremystretch commented on GitHub (Jan 21, 2022): Disregarding for the moment the feasibility of securing the request ID for the response, how would you return the request ID? We probably want to avoid injecting into the actual API data to avoid a breaking change; would an HTTP header suffice?
adam commented 2025-12-29 19:35:19 +01:00
Author
Owner
Copy Link

@apo51 commented on GitHub (Jan 24, 2022):

Ideally, it would be better to retrieve it from the API datas. But if it's an issue for you, we can extract it from the HTTP header.

Maybe it could be added in the API in the future.

@apo51 commented on GitHub (Jan 24, 2022): Ideally, it would be better to retrieve it from the API datas. But if it's an issue for you, we can extract it from the HTTP header. Maybe it could be added in the API in the future.
adam commented 2025-12-29 19:35:20 +01:00
Author
Owner
Copy Link

@kerryb48 commented on GitHub (Feb 23, 2022):

I was just researching if it was possible to get the request ID via the API response when I stumbled on this issue. We have interest in this, or similar feature as well, with the goal of being able to rollback/unwind requests associated with an overall user workflow/automation. I think returning it via HTTP header would be fine.

I thought of a potential alternate approach as well. Possibly slightly more complicated, but would serve my scenario well :)

Rather than returning the request ID via each individual API call - perhaps the API could be extended to allow the requestor to (optionally) include a unique ID in the X-Request-ID HTTP header when calling the Netbox API, and that X-Request-ID could then be associated/related to the netbox request ID. (ideally - would allow 1-to-Many)

A new API endpoint could be added to allow querying for all netbox request IDs associated with said X-Request-ID. This would give us a way to identify any/all changes made as part of a particular user request (even if that workflow invoked multiple CRUD actions on the netbox API).

I am pretty new to Netbox, so I wont pretend to know whether or not this would be more difficult than securing the request ID for the API response, but thought I'd at least throw it out there!

@kerryb48 commented on GitHub (Feb 23, 2022): I was just researching if it was possible to get the request ID via the API response when I stumbled on this issue. We have interest in this, or similar feature as well, with the goal of being able to rollback/unwind requests associated with an overall user workflow/automation. I think returning it via HTTP header would be fine. I thought of a potential alternate approach as well. Possibly slightly more complicated, but would serve my scenario well :) Rather than returning the request ID via each individual API call - perhaps the API could be extended to allow the requestor to (optionally) include a unique ID in the X-Request-ID HTTP header when calling the Netbox API, and that X-Request-ID could then be associated/related to the netbox request ID. (ideally - would allow 1-to-Many) A new API endpoint could be added to allow querying for all netbox request IDs associated with said X-Request-ID. This would give us a way to identify any/all changes made as part of a particular user request (even if that workflow invoked multiple CRUD actions on the netbox API). I am pretty new to Netbox, so I wont pretend to know whether or not this would be more difficult than securing the request ID for the API response, but thought I'd at least throw it out there!
adam commented 2025-12-29 19:35:21 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 6, 2022):

I suppose it would be necessary to return the change record ID inline with the data to support multi-object operations (e.g. bulk creation).

However, I don't think this is feasible given that the creation of the change record is queued for processing after the response has been generated.

@jeremystretch commented on GitHub (Apr 6, 2022): I suppose it would be necessary to return the change record ID inline with the data to support multi-object operations (e.g. bulk creation). However, I don't think this is feasible given that the creation of the change record is queued for processing _after_ the response has been generated.
adam commented 2025-12-29 19:35:21 +01:00
Author
Owner
Copy Link

@baldgeek commented on GitHub (Apr 6, 2022):

Is there a way to get creative? Can it return a unique value for in the
queue that a second API call could use to get the change record ID(or
something along the lines it isn't processed yet)

On 4/6/22 16:27, Jeremy Stretch wrote:

I suppose it would be necessary to return the change record ID inline
with the data to support multi-object operations (e.g. bulk creation).

However, I don't think this is feasible given that the creation of the
change record is queued for processing /after/ the response has been
generated.

—
Reply to this email directly, view it on GitHub
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnetbox-community%2Fnetbox%2Fissues%2F8422%23issuecomment-1090753788&data=04%7C01%7Cjos100%40psu.edu%7C3c45fccd8a4549573f7408da180bdb88%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637848736445591691%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=c2Xbn%2Bww79XgfTa60Lo0x0P9GmubAwmj3AHzZ8Yhs7g%3D&reserved=0,
or unsubscribe
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FANYW3MID2CLGSCS5TRE2HADVDXXSVANCNFSM5MPE6JZQ&data=04%7C01%7Cjos100%40psu.edu%7C3c45fccd8a4549573f7408da180bdb88%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637848736445591691%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ziggin8T6yPOAIfDV9sh1vbEc2o2yutQKlGNBTDciAM%3D&reserved=0.
You are receiving this because you are subscribed to this
thread.Message ID:
@.***>

@baldgeek commented on GitHub (Apr 6, 2022): Is there a way to get creative? Can it return a unique value for in the queue that a second API call could use to get the change record ID(or something along the lines it isn't processed yet) On 4/6/22 16:27, Jeremy Stretch wrote: > > I suppose it would be necessary to return the change record ID inline > with the data to support multi-object operations (e.g. bulk creation). > > However, I don't think this is feasible given that the creation of the > change record is queued for processing /after/ the response has been > generated. > > — > Reply to this email directly, view it on GitHub > <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnetbox-community%2Fnetbox%2Fissues%2F8422%23issuecomment-1090753788&data=04%7C01%7Cjos100%40psu.edu%7C3c45fccd8a4549573f7408da180bdb88%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637848736445591691%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=c2Xbn%2Bww79XgfTa60Lo0x0P9GmubAwmj3AHzZ8Yhs7g%3D&reserved=0>, > or unsubscribe > <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FANYW3MID2CLGSCS5TRE2HADVDXXSVANCNFSM5MPE6JZQ&data=04%7C01%7Cjos100%40psu.edu%7C3c45fccd8a4549573f7408da180bdb88%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637848736445591691%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ziggin8T6yPOAIfDV9sh1vbEc2o2yutQKlGNBTDciAM%3D&reserved=0>. > You are receiving this because you are subscribed to this > thread.Message ID: > ***@***.***> >
adam commented 2025-12-29 19:35:21 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 6, 2022):

You're certainly welcome to experiment with potential solutions, but I'd expect that any such workarounds are going to be a bigger headache than simply querying for most recent change log for the object.

@jeremystretch commented on GitHub (Apr 6, 2022): You're certainly welcome to experiment with potential solutions, but I'd expect that any such workarounds are going to be a bigger headache than simply querying for most recent change log for the object.
adam commented 2025-12-29 19:35:22 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jun 6, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jun 6, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:35:22 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 6, 2022):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Jul 6, 2022): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 pending closure status: under review 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#5983
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?