netboxlabs · bctiemann · Apr 20, 2026 · Apr 20, 2026 · Apr 20, 2026 · Apr 20, 2026
diff --git a/AGENTS.md b/AGENTS.md
@@ -37,7 +37,7 @@ Defer all version pins to `pyproject.toml` and `netbox_custom_objects/__init__.p
 │   ├── tables.py                   — django-tables2 tables for list views.
 │   ├── template_content.py         — PluginTemplateExtension registrations.
 │   ├── urls.py                     — Web UI URL routing (80+ routes).
-│   ├── utilities.py                — AppsProxy, generate_model(), get_viewname(), is_in_branch().
+│   ├── utilities.py                — AppsProxy, generate_model(), get_viewname().
 │   ├── views.py                    — All UI views.
 │   ├── api/
 │   │   ├── serializers.py          — get_serializer_class() + static serializers.
@@ -134,7 +134,7 @@ Multi-object fields create a separate through table (`custom_objects_<cot_id>_<f
 | `netbox_custom_objects/__init__.py` | PluginConfig, migration detection, ObjectSelectorView patch, dynamic model registration on startup |
 | `netbox_custom_objects/models.py` | `CustomObject` (abstract base), `CustomObjectType`, `CustomObjectTypeField`, signal handlers |
 | `netbox_custom_objects/field_types.py` | Pluggable field type system |
-| `netbox_custom_objects/utilities.py` | `generate_model()`, `AppsProxy`, `is_in_branch()` |
+| `netbox_custom_objects/utilities.py` | `generate_model()`, `AppsProxy` |
 | `netbox_custom_objects/jobs.py` | `ReindexCustomObjectTypeJob` |
 | `netbox_custom_objects/api/views.py` | Dynamic ViewSet generation, `LinkedObjectsView` |
 | `netbox_custom_objects/api/serializers.py` | `get_serializer_class()` for dynamic models |

diff --git a/COMPATIBILITY.md b/COMPATIBILITY.md
@@ -2,6 +2,7 @@
 
 | Release | Minimum NetBox Version | Maximum NetBox Version |
 |---------|------------------------|------------------------|
+| 0.6.x   | 4.5.2                  | 4.6.x                  |
 | 0.5.2   | 4.5.2                  | 4.6.x                  |
 | 0.5.1   | 4.5.2                  | 4.6.x                  |
 | 0.5.0   | 4.5.2                  | 4.6.x                  |

diff --git a/README.md b/README.md
@@ -32,20 +32,6 @@ $ ./manage.py migrate
 sudo systemctl restart netbox netbox-rq
 ```
 
-> [!NOTE]
-> If you are using NetBox Custom Objects with NetBox Branching, you need to insert the following into your `configuration.py`. See the docs for a full description of how NetBox Custom Objects currently works with NetBox Branching.  
-
-```
-PLUGINS_CONFIG = {
-    'netbox_branching': {
-        'exempt_models': [
-            'netbox_custom_objects.customobjecttype',
-            'netbox_custom_objects.customobjecttypefield',
-        ],
-    },
-}
-```
-
 ## Known Limitations
 
 NetBox Custom Objects is now Generally Available which means you can use it in production and migrations to future versions will work. There are many upcoming features including GraphQL support - the best place to see what's on the way is the [issues](https://github.com/netboxlabs/netbox-custom-objects/issues) list on the GitHub repository.
diff --git a/docs/branching.md b/docs/branching.md
@@ -1,5 +1,12 @@
 # Using NetBox Custom Objects with NetBox Branching
 
+When using Custom Objects together with NetBox Branching, the following minimum versions are required:
+
+- NetBox >= 4.6.2
+- netbox-branching >= 1.0.4
+
+These requirements are only enforced when `netbox_branching` is present in `PLUGINS`. If you do not use branching, the standard compatibility matrix in `COMPATIBILITY.md` applies. A Django system check (`netbox_custom_objects.E001` / `E002`) will fail at startup if the combination is misconfigured.
+
 As of version 0.4.0, Custom Objects is _compatible_ with [NetBox Branching](https://netboxlabs.com/docs/extensions/branching/), but not yet fully supported. Users can safely run both plugins together, but there are some caveats to be aware of. See below for how each Custom Objects model interacts with NetBox Branching.
 
 !!! note

diff --git a/docs/field-attributes.md b/docs/field-attributes.md
@@ -19,6 +19,7 @@ The following attributes are available when creating or editing a Custom Object
 | `multiselect` | Multiple selections from a choice set |
 | `object` | Reference to a single object (built-in NetBox object or Custom Object) |
 | `multiobject` | Reference to multiple objects of the same type |
+| `coordinates` | A geographic latitude/longitude pair (with a map link) |
 
 ## Common Attributes
 
@@ -85,3 +86,24 @@ Field types: `object`, `multiobject`
 
 !!! note
     To reference another Custom Object Type, choose `Custom Objects > <Custom Object Type name>` in the **Related object type** dropdown. To create a polymorphic field that may reference objects of multiple types, enable **Polymorphic** and select the allowed types under **Related object types**.
+
+## Coordinates Fields
+
+Field type: `coordinates`
+
+A single `coordinates` field stores a geographic latitude/longitude pair, mirroring NetBox's
+native Site/Device coordinates (plain decimal columns — PostGIS is not required). Adding one
+`coordinates` field named `location` creates two backing columns and two form inputs:
+
+- `location_latitude` — decimal, range −90 to 90, up to 6 decimal places
+- `location_longitude` — decimal, range −180 to 180, up to 6 decimal places
+
+Behaviour:
+
+- **Both-or-neither.** Latitude and longitude must either both be set or both be empty; setting
+  only one is rejected in forms and via the REST API.
+- **REST API.** The pair is exposed as two flat fields, `<name>_latitude` and `<name>_longitude`
+  (matching NetBox core's serializers), not as a nested object.
+- **Map link.** Detail views render the coordinates with a **Map** button that opens the location
+  using NetBox's `MAPS_URL` configuration parameter (Google Maps by default).
+- `Must be unique` and `Default` are not supported for `coordinates` fields.
diff --git a/docs/graphql.md b/docs/graphql.md
@@ -0,0 +1,173 @@
+# GraphQL API
+
+The NetBox Custom Objects plugin exposes custom objects through NetBox's GraphQL
+API at the standard `/graphql/` endpoint, alongside NetBox's built-in models. For
+each Custom Object Type you have defined, two root query fields are generated:
+
+- `<name>` — fetch a single custom object by `id`.
+- `<name>_list` — fetch a list of custom objects (paginated).
+
+The `<name>` is `custom_objects_<slug>`, where `<slug>` is the Custom Object
+Type's **slug** with any characters that are not valid in a GraphQL name replaced
+by underscores (for example a type with slug `dhcp-scope` becomes
+`custom_objects_dhcp_scope` and `custom_objects_dhcp_scope_list`).
+
+The `custom_objects_` prefix namespaces these fields so they can never collide
+with NetBox's own (or another plugin's) root query fields — every plugin's
+GraphQL query is merged into NetBox's single global `Query`, so a bare,
+slug-derived name like `site` or `group` would otherwise be shadowed by a core
+model's field.
+
+## Authentication
+
+GraphQL requests use the same authentication as the REST API. Pass a token in the
+`Authorization` header:
+
+```
+Authorization: Token <your-api-token>
+```
+
+Object-level permissions are enforced. The top-level `<name>` / `<name>_list`
+queries only return custom objects the authenticated user has permission to view,
+and objects reached through a relationship field are likewise filtered to those
+the user may view.
+
+## Using the GraphiQL explorer
+
+NetBox's built-in GraphiQL explorer (at `/graphql/`) loads the GraphQL schema
+**once when the page opens** and caches it for the life of the page. Because
+custom object types and their fields can change at runtime, the explorer's
+autocomplete suggestions and **Documentation** panel can go stale.
+
+If you **add, remove, or change a custom object type's fields**, or **add a new
+custom object type**, while GraphiQL is open, those changes will not appear in the
+field autocomplete or the Docs panel until GraphiQL re-reads the schema. (The
+change is already live on the server — a query using the new field works
+immediately — it is only GraphiQL's cached copy of the schema that lags.)
+
+To refresh it, click the **Re-fetch GraphQL schema** button — the circular-arrow
+icon in the GraphiQL toolbar (lower left). This re-reads the schema *without*
+reloading the page, so your current query is preserved:
+
+![The Re-fetch GraphQL schema button in the GraphiQL toolbar](media/graphql/graphiql-refresh-schema.png)
+
+Reloading the whole browser page has the same effect, but discards whatever you
+have typed in the editor.
+
+!!! note
+    This only affects the interactive explorer. Programmatic API clients fetch the
+    schema via introspection whenever they choose, and always query against the
+    current server-side schema.
+
+## Querying a list
+
+The fields you can select depend on how the Custom Object Type is defined. Every
+type exposes `id` and `display`; the examples below also assume the type defines
+custom fields named `name` and `description`.
+
+```graphql
+query {
+  custom_objects_dhcp_scope_list {
+    id
+    display
+    name
+    description
+  }
+}
+```
+
+> **Tip:** `display` is the only human-readable field guaranteed to exist on every
+> type — it is the value of the type's primary field. `name` exists only if the
+> type defines a custom field literally named `name`.
+
+## Querying a single object
+
+```graphql
+query {
+  custom_objects_dhcp_scope(id: 42) {
+    id
+    display
+  }
+}
+```
+
+## Available fields
+
+Each generated type exposes:
+
+| Field | Description |
+|-------|-------------|
+| `id` | The object's primary key. |
+| `display` | The object's display string (its primary field value). |
+| `created` / `last_updated` | Change-logging timestamps. |
+| `tags` | The object's tags. |
+| One field per custom field | Named exactly as the field's `name`. |
+
+### Scalar field types
+
+Scalar custom fields map to their natural GraphQL types:
+
+| Custom field type | GraphQL type |
+|-------------------|--------------|
+| text, long text, URL, select | `String` |
+| integer | `Int` |
+| decimal | `Decimal` |
+| boolean | `Boolean` |
+| date | `Date` |
+| datetime | `DateTime` |
+| JSON | `JSON` |
+| multi-select | `[String]` |
+
+### Relationship field types
+
+Object and multi-object fields resolve to the **native GraphQL type** of their
+target, so a related object is fully traversable exactly as it would be when
+queried directly. A field pointing at a Site resolves to NetBox's `SiteType`:
+
+```graphql
+query {
+  custom_objects_server_list {
+    name
+    primary_site {          # an object (single) field → SiteType
+      id
+      name
+      region { name }       # traverse into the related object's own fields
+    }
+    interfaces {            # a multi-object (list) field → [InterfaceType]
+      id
+      name
+    }
+  }
+}
+```
+
+#### Polymorphic fields
+
+A polymorphic relationship field may point at several different model types. It
+resolves to a GraphQL **union** of those types; select fields per type with inline
+fragments:
+
+```graphql
+query {
+  custom_objects_binding_list {
+    name
+    target {                # polymorphic object field
+      ... on SiteType { id name }
+      ... on DeviceType { id name }
+    }
+  }
+}
+```
+
+#### Fallback for targets without a GraphQL type
+
+A small number of NetBox models are not exposed in GraphQL. When a relationship
+field's target has no native GraphQL type, that field falls back to a uniform
+`CustomObjectRelatedObjectType` so it is never silently dropped:
+
+| Field | Description |
+|-------|-------------|
+| `id` | The referenced object's primary key. |
+| `object_type` | The referenced object's type, as `<app_label>.<model>`. |
+| `display` | The referenced object's display string. |
+| `url` | The referenced object's absolute URL, if resolvable. |
diff --git a/docs/index.md b/docs/index.md
@@ -41,6 +41,7 @@ This documentation covers:
     * Full-text search
     * Change logging
     * Bookmarks
+    * Contacts
     * Custom Links
     * Cloning
     * Import/Export
@@ -126,6 +127,39 @@ As with core NetBox objects, Custom Objects have their own list views. To see al
 
 You will see a standard NetBox list view for your new Custom Objects with the standard options including `Configure Table`, `+ Add`, `Import`, `Export`, and others.
 
+### Config Context
+
+A Custom Object Type can opt in to NetBox's [config context](https://netboxlabs.com/docs/netbox/models/extras/configcontext/) support by checking **Config context support** when the type is created. (This can only be set at creation time — it adds a `local_context_data` column to the type's table, so it cannot be toggled afterwards.)
+
+When enabled, every object of that type gains:
+
+- A **Local Context Data** field (arbitrary JSON), stored per object and exposed in the REST API — useful for building configurations (e.g. with Ansible).
+- A **Config Context** tab on the object's detail view, showing the rendered context, the local context, and any source contexts.
+
+#### Aggregating source config contexts
+
+Custom objects can also inherit the ConfigContexts that apply to NetBox objects they reference, exactly as a Device or VM would. This works **by field-naming convention** — no extra configuration:
+
+Give the Custom Object Type a single (non-polymorphic) **object** field named one of the following, pointing at the matching NetBox model:
+
+| Field name | Points at |
+|------------|-----------|
+| `site` | Site |
+| `tenant` | Tenant |
+| `role` | Device Role |
+| `platform` | Platform |
+| `location` | Location |
+| `device_type` | Device Type |
+| `cluster` | Cluster |
+
+Any active ConfigContext assigned to the referenced object (or to its region, site group, tenant group, cluster type/group, or matching tags) is then aggregated into the object's rendered context, ordered by weight, with the object's own **Local Context Data** applied last (it always wins). Assigning tags to the custom object also matches tag-scoped ConfigContexts automatically.
+
+Notes:
+
+- Field **names are unique per type**, so there is never ambiguity about which field feeds a dimension.
+- A field must be an object field with both the **name and target model** above; a mis-named or mis-pointed field is simply ignored.
+- If a type defines **none** of these fields, aggregation is skipped entirely and its rendered context is just its Local Context Data. This is a deliberate difference from Devices/VMs: **global (unassigned) ConfigContexts are not applied** to such a type — enabling config context support alone never silently pulls in every global context. Add at least one convention field (e.g. `site`) to opt the type into source aggregation; global contexts then apply too (as they do for any object with a dimension).
+
 ### Deletions
 
 #### Deleting Custom Object Types

diff --git a/docs/media/graphql/graphiql-refresh-schema.png b/docs/media/graphql/graphiql-refresh-schema.png
diff --git a/docs/releases.md b/docs/releases.md
@@ -1,5 +1,37 @@
 # Releases
 
+## 0.6.0
+
+### New Features
+
+**NetBox Branching Support**
+
+Custom Object Types and their instances now participate fully in NetBox branching workflows. COT schema changes (adding/removing fields, modifying field definitions) and instance creates/updates/deletes are all branch-aware. A version check ensures the minimum required NetBox and netbox-branching versions are present before enabling branching features.
+
+- [#404](https://github.com/netboxlabs/netbox-custom-objects/issues/404) - Full branching support for Custom Object Types and instances
+- [#569](https://github.com/netboxlabs/netbox-custom-objects/issues/569) - Add version check to gate branching features on required NetBox / netbox-branching versions
+
+**GraphQL Support**
+
+Custom Object Types and their instances are now queryable and mutable via the NetBox GraphQL API. Queries, mutations, and filtering are supported for all field types.
+
+- [#30](https://github.com/netboxlabs/netbox-custom-objects/issues/30) - GraphQL support for Custom Objects
+
+### Enhancements
+
+- [#98](https://github.com/netboxlabs/netbox-custom-objects/issues/98) - Config context support for Custom Objects
+- [#254](https://github.com/netboxlabs/netbox-custom-objects/issues/254) - Quick Add support for object/multiobject fields
+- [#286](https://github.com/netboxlabs/netbox-custom-objects/issues/286) - Contacts support for Custom Objects
+- [#376](https://github.com/netboxlabs/netbox-custom-objects/issues/376) - Ownership field for Custom Object instances
+- [#532](https://github.com/netboxlabs/netbox-custom-objects/issues/532) - Integer fields now use 64-bit `BigIntegerField` to support values exceeding the 32-bit range
+- [#551](https://github.com/netboxlabs/netbox-custom-objects/issues/551) - Add `location` field type for latitude/longitude coordinate pairs
+
+### Bug Fixes
+
+- [#572](https://github.com/netboxlabs/netbox-custom-objects/issues/572) - Crash on startup when netbox-branching is installed but not listed in `PLUGINS`
+
+---
+
 ## 0.5.3
 
 ### Bug Fixes

diff --git a/mkdocs.yml b/mkdocs.yml
@@ -42,5 +42,6 @@ nav:
     - Field Attributes: 'field-attributes.md'
     - Branching Support: 'branching.md'
     - REST API: 'rest-api.md'
+    - GraphQL API: 'graphql.md'
     - Portable Schema: 'portable-schema.md'
     - Releases: 'releases.md'