Allow authenticated access to image attachments via the NetBox API #571

New Issue

MrUnknownDE · 2026-04-05T16:45:03+02:00

MrUnknownDE commented

2026-04-05 16:45:03 +02:00

Originally created by @le-renard-12 on 1/15/2026

NetBox version

v4.4.9

Feature type

Change to existing functionality

Proposed functionality

Description

NetBox currently exposes image attachments (e.g. floor plans attached to locations) via the REST API at:

GET /api/extras/image-attachments/

The API correctly returns metadata, including a direct image URL pointing to the media file:

{
  "id": 12,
  "name": "Floor Plan Latest",
  "image": "http://netbox.example.com/media/image-attachments/location_79_floor_plan.png",
  "object_type": "dcim.location",
  "object_id": 79
}

However, while the metadata endpoint is accessible using API token authentication, the referenced image URL itself is not accessible using the same token.

When attempting to retrieve the image via HTTP with:

Authorization: Token <API_TOKEN>

the response is HTML (typically a login page) instead of the image binary. This suggests that media file serving does not honor API token authentication, even though the API advertises these URLs as "retrievable" resources.

Problem Statement

This makes it difficult or impossible to build API-driven or frontend-only integrations that rely on image attachments, such as:

Indoor mapping or floor plan visualization
Infrastructure visualization dashboards
External tooling that consumes NetBox purely via API

Because browsers cannot attach custom headers to <img> tags, and because /media/ endpoints do not accept token authentication, consumers are effectively forced to:

Expose media publicly, or
Rely on session cookies, or
Implement a backend proxy purely to fetch images

All of these add complexity or security trade-offs that could be avoided if image attachments were accessible through an authenticated API mechanism.

Expected Behavior

One of the following (or similar) would enable clean API-based consumption:

Provide an API endpoint to retrieve the image binary itself, for example:
```
GET /api/extras/image-attachments/<id>/image/
```
authenticated via API token.
Allow API token authentication to be honored when accessing protected media URLs under /media/image-attachments/.

Current Behavior

Image attachment metadata is accessible via the API using a token.
The image URL returned by the API cannot be fetched using the same token.
Fetching the URL returns HTML (login page) instead of image data.
This prevents direct usage of attachments in API-driven clients.

Closing

Would the NetBox maintainers be open to supporting authenticated access to image attachments via the API, or to recommending a best-practice approach for API-only consumers who need to retrieve protected media?

Thank you for considering this request.

I would also be interested to make a plugin-based solution.

Use case

I am prototyping an indoor device mapping application that:

Retrieves buildings and floors from NetBox (location with: building, floor, room tags)
Loads floor plan images stored as image attachments
Places devices visually on the floor plan
Stores normalized coordinates back into NetBox custom fields (map_location -> type:json)

This workflow relies entirely on API access and does not require or expect users to log into the NetBox UI.

I wanted to build a plugin at first but im not abble to do so see issue

Database changes

None I believe

External dependencies

None I believe

*Originally created by @le-renard-12 on 1/15/2026* ### NetBox version v4.4.9 ### Feature type Change to existing functionality ### Proposed functionality ## Description NetBox currently exposes image attachments (e.g. floor plans attached to locations) via the REST API at: ``` GET /api/extras/image-attachments/ ``` The API correctly returns metadata, including a direct `image` URL pointing to the media file: ```json { "id": 12, "name": "Floor Plan Latest", "image": "http://netbox.example.com/media/image-attachments/location_79_floor_plan.png", "object_type": "dcim.location", "object_id": 79 } ``` However, while the metadata endpoint is accessible using API token authentication, the referenced image URL itself is not accessible using the same token. When attempting to retrieve the image via HTTP with: ``` Authorization: Token <API_TOKEN> ``` the response is HTML (typically a login page) instead of the image binary. This suggests that media file serving does not honor API token authentication, even though the API advertises these URLs as "retrievable" resources. --- ## Problem Statement This makes it difficult or impossible to build API-driven or frontend-only integrations that rely on image attachments, such as: * Indoor mapping or floor plan visualization * Infrastructure visualization dashboards * External tooling that consumes NetBox purely via API Because browsers cannot attach custom headers to `<img>` tags, and because `/media/` endpoints do not accept token authentication, consumers are effectively forced to: * Expose media publicly, or * Rely on session cookies, or * Implement a backend proxy purely to fetch images All of these add complexity or security trade-offs that could be avoided if image attachments were accessible through an authenticated API mechanism. --- ## Expected Behavior One of the following (or similar) would enable clean API-based consumption: 1. Provide an API endpoint to retrieve the image binary itself, for example: ``` GET /api/extras/image-attachments/<id>/image/ ``` authenticated via API token. 2. Allow API token authentication to be honored when accessing protected media URLs under `/media/image-attachments/`. --- ## Current Behavior * Image attachment metadata is accessible via the API using a token. * The `image` URL returned by the API cannot be fetched using the same token. * Fetching the URL returns HTML (login page) instead of image data. * This prevents direct usage of attachments in API-driven clients. --- ## Closing Would the NetBox maintainers be open to supporting authenticated access to image attachments via the API, or to recommending a best-practice approach for API-only consumers who need to retrieve protected media? Thank you for considering this request. I would also be interested to make a plugin-based solution. ### Use case I am prototyping an indoor device mapping application that: * Retrieves buildings and floors from NetBox (location with: building, floor, room tags) * Loads floor plan images stored as image attachments * Places devices visually on the floor plan * Stores normalized coordinates back into NetBox custom fields (map_location -> type:json) This workflow relies entirely on API access and does not require or expect users to log into the NetBox UI. I wanted to build a plugin at first but im not abble to do so see [issue](https://github.com/netbox-community/netbox-plugin-tutorial/issues/43#issuecomment-3712089347) ### Database changes None I believe ### External dependencies None I believe

MrUnknownDE closed this issue

2026-04-05 16:45:03 +02:00

Sign in to join this conversation.

Branches Tags

main

21455-sql-indexes-audit

21357-register-model-actions

feature

20924-plugin-ui-components

21766-improve-test-coverage-for-sortable-table-columns

21157-export-template-public-models

21025-pre-render-config-contexts

21364-swagger

feature-ip-prefix-link

20911-dropdown-3

fix_module_substitution

21160-filterset

20911-dropdown-2

20044-elevation-stuck-lightmode

7604-filter-modifiers-v3

20660-script-load

19724-graphql

14884-script

19720-macaddress-interface-generic-relation

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

No Label netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/netbox#571