diff --git a/docs/docs.json b/docs/docs.json
index 42895f7e..3562ed67 100644
--- a/docs/docs.json
+++ b/docs/docs.json
@@ -115,6 +115,7 @@
"group": "OpenGraph",
"pages": [
"opengraph/overview",
+ "opengraph/quickstart",
"opengraph/requirements",
"opengraph/graph-theory",
"opengraph/schema",
diff --git a/docs/get-started/introduction.mdx b/docs/get-started/introduction.mdx
index aa86585a..ad52298c 100644
--- a/docs/get-started/introduction.mdx
+++ b/docs/get-started/introduction.mdx
@@ -4,7 +4,12 @@ title: Introduction to BloodHound
-BloodHound uses graph theory to reveal hidden and often unintended relationships within Active Directory, Entra ID (formerly Azure AD), and Microsoft Azure IaaS. Defenders (blue teams) and attackers (red teams) use BloodHound for a deeper understanding of privileged relationships in an environment.
+BloodHound uses graph theory to reveal hidden and often unintended relationships within Active Directory and Entra ID (formerly Azure Active Directory). Defenders (blue teams) and attackers (red teams) use BloodHound for a deeper understanding of privileged relationships in an environment.
+
+With the introduction of [OpenGraph](/opengraph/overview) in BloodHound v8.0, you can extend BloodHound's capabilities beyond Active Directory and Entra ID to visualize attack paths across hybrid environments. OpenGraph is a powerful framework that enables you to:
+
+- **Extend coverage** to identity services across other platforms (for example, GitHub, Okta, Jamf, and more)
+- **Build custom collectors** that ingest data using a standardized JSON schema
There are two BloodHound products: BloodHound Enterprise and BloodHound Community Edition (BloodHound CE). This site documents both products.
diff --git a/docs/home.mdx b/docs/home.mdx
index 4ef9183f..152db209 100644
--- a/docs/home.mdx
+++ b/docs/home.mdx
@@ -119,7 +119,7 @@ export function openSearch() {
diff --git a/docs/images/opengraph/bob-and-alice.png b/docs/images/opengraph/bob-and-alice.png
new file mode 100644
index 00000000..02274fdf
Binary files /dev/null and b/docs/images/opengraph/bob-and-alice.png differ
diff --git a/docs/images/opengraph/bob-knows-alice.png b/docs/images/opengraph/bob-knows-alice.png
new file mode 100644
index 00000000..3c532bef
Binary files /dev/null and b/docs/images/opengraph/bob-knows-alice.png differ
diff --git a/docs/images/opengraph/bob.png b/docs/images/opengraph/bob.png
new file mode 100644
index 00000000..f5f9feed
Binary files /dev/null and b/docs/images/opengraph/bob.png differ
diff --git a/docs/opengraph/faq.mdx b/docs/opengraph/faq.mdx
index 0faaf1bf..2c01f5b2 100644
--- a/docs/opengraph/faq.mdx
+++ b/docs/opengraph/faq.mdx
@@ -31,9 +31,9 @@ You can remove generic data by using one of the following three (3) options:
-No, not yet.
+**Search:** Yes! As of v8.50, OpenGraph nodes are partially supported in the search functionality on the **Explore** page. You can search for OpenGraph nodes by display name or object ID, and visualize them in the graph with custom icons and colors. However, you cannot yet prepend search queries by OpenGraph node types.
-In the initial BloodHound 8.0 release, OpenGraph nodes and edges are not supported in the Search or Pathfinding tab, so the Cypher tab **must** be used to query the data manually.
+**Pathfinding:** Not yet. OpenGraph edges are not currently supported in the **Pathfinding** tab on the **Explore** page. For pathfinding queries involving OpenGraph data, you must use the Cypher tab to query the data manually.
Have you built a cool project using OpenGraph and want it featured here? Already got your project in the list and need to update something? Open a ["Library Change" issue](https://github.com/SpecterOps/bloodhound-docs/issues) on the BloodHound Docs repo and we'll get it added for you!
diff --git a/docs/opengraph/overview.mdx b/docs/opengraph/overview.mdx
index 80294cf5..2625b967 100644
--- a/docs/opengraph/overview.mdx
+++ b/docs/opengraph/overview.mdx
@@ -4,14 +4,24 @@ sidebarTitle: Overview
description: "Learn about OpenGraph in BloodHound."
---
-## The BloodHound OpenGraph
+## The BloodHound OpenGraph
+
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/opengraph/quickstart.mdx b/docs/opengraph/quickstart.mdx
new file mode 100644
index 00000000..4ba1995a
--- /dev/null
+++ b/docs/opengraph/quickstart.mdx
@@ -0,0 +1,315 @@
+---
+title: OpenGraph Quickstart
+description: Learn how to create and test OpenGraph data in BloodHound.
+sidebarTitle: Quickstart
+---
+
+
+
+This guide walks you through creating and testing OpenGraph data using a simple example JSON file. By following these steps, you'll learn how to:
+
+- Create a properly structured OpenGraph JSON file and upload it to BloodHound
+- Define custom icons and colors for your node types to enhance visualization
+- Validate the data using search and Cypher queries in the **Explore** page
+- Remove the example data in the **Administration** > **Database Management** page when finished
+
+Use this guide to get hands-on experience with the OpenGraph structure and validate custom nodes and edges in BloodHound.
+
+## Create example data
+
+This example defines two `Person` nodes connected by a `Knows` edge to demonstrate the structure of an OpenGraph payload.
+
+You can expand on this example to create more complex graphs with additional nodes, edges, and properties as needed.
+
+
+
+
+ First, you need to define your OpenGraph payload in a JSON file.
+
+ 1. Create a new file called `opengraph-example.json` using a plain text editor (UTF-8 encoding).
+
+ 1. Copy and paste the following example, which includes two nodes (`bob` and `alice`) connected by an edge (`Knows`).
+
+ ```json
+ {
+ "metadata": {
+ "source_kind": "Person"
+ },
+ "graph": {
+ "nodes": [
+ {
+ "id": "123",
+ "kinds": [
+ "Person",
+ "Base"
+ ],
+ "properties": {
+ "displayname": "bob",
+ "property1": "property1",
+ "objectid": "123",
+ "name": "BOB"
+ }
+ },
+ {
+ "id": "234",
+ "kinds": [
+ "Person",
+ "Base"
+ ],
+ "properties": {
+ "displayname": "alice",
+ "property1": "property1",
+ "objectid": "234",
+ "name": "ALICE"
+ }
+ }
+ ],
+ "edges": [
+ {
+ "kind": "Knows",
+ "start": {
+ "value": "123",
+ "match_by": "id"
+ },
+ "end": {
+ "value": "234",
+ "match_by": "id"
+ }
+ }
+ ]
+ }
+ }
+ ```
+
+ The following table describes the structure and properties of the example JSON file:
+
+ | Section | Property | Description |
+ |---------|----------|-------------|
+ | **metadata** | `source_kind` | Optional property that identifies the type of data (e.g., "Person") in the **Database Management** page for easy clean up later |
+ | **graph.nodes** | `id` | Unique identifier for the node |
+ | | `kinds` | Array of node types (first is your custom type, "Base" is required) |
+ | | `properties` | Object containing node properties (e.g., `name`, `displayname`, `objectid`, and custom properties) |
+ | **graph.edges** | `kind` | The edge type name (e.g., "Knows") |
+ | | `start` | Source node reference that must match a node ID in the nodes section |
+ | | `end` | Target node reference that must match a node ID in the nodes section |
+
+ **DELETE ME: `Base` kind is required for simple search to work; is that expected?**
+
+
+ Save the `opengraph-example.json` file to a location you can easily access for uploading in the next step.
+
+
+ Use the BloodHound web interface to upload the `opengraph-example.json` file directly through the browser.
+
+ 1. Log in to your BloodHound instance.
+ 1. In the left menu, click **Quick Upload**.
+ 1. Click the **Upload Files** screen to open a file system dialog or drag and drop the `opengraph-example.json` file.
+ 1. Click **Upload** and wait for the upload to complete.
+
+ You should see a confirmation message indicating the file was successfully ingested.
+
+ If you receive an error, validate your JSON file using a [linter](https://jsonlint.com/) and ensure all [required properties](/opengraph/requirements) are present.
+
+
+
+## Customize nodes
+
+To enhance the visualization of the node types on the graph and in the **Entity** panel, you can define custom icons and colors.
+
+This is done separately from the OpenGraph data payload and must be uploaded through the [BloodHound API](/integrations/bloodhound-api/working-with-api).
+
+
+
+ This example creates a custom definition for the `Person` node type defined in the example JSON file. It specifies that the `Person` node type should display with a user icon and red color.
+
+ The custom type definition is a JSON object with the following structure:
+
+ ```json
+ {
+ "custom_types": {
+ "Person": {
+ "icon": {
+ "type": "font-awesome",
+ "name": "user",
+ "color": "#FF0000"
+ }
+ },
+ ... other custom type definitions ...
+ }
+ }
+ ```
+
+ The following table describes the properties in the custom type definition:
+
+ | Property | Description |
+ |----------|-------------|
+ | `custom_types` | Object containing custom type definitions, where each key is a node type and the value defines the visualization properties for that type |
+ | `icon.type` | Font Awesome is the icon library used for custom icons |
+ | `icon.name` | Font Awesome [icon name]((https://fontawesome.com/search?s=solid)) (without "fa-" prefix) |
+ | `icon.color` | Hex color code (#RGB or #RRGGBB format) |
+
+
+ Use a `POST` request to the BloodHound API to upload your custom type definition.
+
+ Here's an example request body for a `Person` node type with a user icon and red color:
+
+ ```bash
+ curl -X POST \
+ https://your-bloodhound-instance/api/v2/graphs/custom_nodes \
+ -H "Authorization: Bearer YOUR_TOKEN" \
+ -H "Content-Type: application/json" \
+ -d '{
+ "custom_types": {
+ "Person": {
+ "icon": {
+ "type": "font-awesome",
+ "name": "user",
+ "color": "#FF0000"
+ }
+ }
+ }
+ }'
+ ```
+
+ After running this request, any nodes of type `Person` in your graph display with the specified icon and color.
+
+
+
+## Validate example data
+
+After uploading the OpenGraph example data and custom node icons/colors, it's important to validate that BloodHound ingested everything correctly and displays it as expected.
+
+
+
+ Log in to your BloodHound instance and navigate to the **Explore** page.
+
+
+
+ Use the **Search** features to find the example nodes and edges, and verify that properties and custom icons/colors are displayed correctly.
+
+
+
+ To find nodes by display name or object ID:
+
+ 1. Click the **Search** tab.
+ 1. In the search field, enter `bob` or `alice`.
+ 1. Select the node from the suggested search results.
+ 1. Click the node on the graph to view its properties in the **Entity** panel.
+
+ **Expected results:**
+
+ - Suggested search results include the Bob and Alice `Person` nodes
+ - Node properties and custom icons/colors display in the **Entity** panel
+ - Custom node icons and colors **do not** display on the graph for Bob and Alice nodes
+
+ Custom icons/colors render on the graph for Cypher search only.
+
+ 
+
+
+ To find nodes and edges by type:
+
+ 1. Click the **Cypher** tab
+ 1. Copy and paste one of the following queries and click **Run**:
+
+ - To find all `Person` nodes:
+
+ ```cypher
+ MATCH (n:Person)
+ RETURN n
+ ```
+ **Expected results:**
+
+ - Nodes BOB and ALICE display on the graph (not connected by an edge)
+ - Node properties and custom icons/colors display in the **Entity** panel after clicking a node on the graph
+ - Custom node icons and colors display on the graph
+
+ 
+
+ - To find the `Knows` edge between nodes:
+
+ ```cypher
+ MATCH p=()-[:Knows]-()
+ RETURN p
+ ```
+ **Expected results:**
+
+ - Nodes BOB and ALICE nodes display on the graph and are connected by the `Knows` edge
+ - Node properties and custom icons/colors display in the **Entity** panel after clicking a node on the graph
+ - Custom node icons and colors display on the graph
+
+ 
+
+
+
+
+
+## Delete example data
+
+After you've finished testing, you should clean up your example data by deleting the example OpenGraph payload.
+
+
+
+ Use the BloodHound web interface to delete nodes by `source_kind`.
+
+ 1. Log in to your BloodHound instance.
+ 1. In the left menu, click **Administration** > **Database Management**.
+ 1. Under **All graph data**, check the **Person data** checkbox.
+
+ The name of the checkbox is based on the value of the `source_kind` property in the metadata section of the example JSON file.
+
+ 1. Click **Delete** and confirm the deletion.
+
+ This action permanently deletes all nodes with the `Person` source kind, including any edges connected to those nodes.
+
+
+ Run the following Cypher query to confirm the example OpenGraph data is gone:
+
+ ```cypher
+ MATCH (n:Person)
+ RETURN n
+ ```
+
+ You should see a `No results match your criteria` message confirming that the nodes have been deleted.
+
+
+
+## Troubleshooting
+
+This section provides solutions to common issues you may encounter when testing your OpenGraph data.
+
+
+
+ - Validate your JSON using [JSONLint](https://jsonlint.com/)
+ - Ensure all required sections are present
+ - Verify all node IDs are unique
+ - Check that node IDs referenced in edges match the node IDs in the nodes section exactly
+
+
+
+ - Ensure you correctly used the node ID values in search
+ - Verify the upload completed successfully without errors
+ - Check the BloodHound logs for any ingest errors
+
+
+
+ - Verify the icon name is correct and does not include a prefix, such as `fa-` (see [FontAwesome](https://fontawesome.com/search?o=r&ic=free&s=solid) to confirm available icons)
+ - Ensure the color is in valid HEX format (#RGB or #RRGGBB)
+ - Run a `GET` request to `api/v2/graphs/custom_nodes` to confirm your BloodHound instance contains the custom type definition you want to use
+
+
+
+ - Verify the edge `kind` name is spelled correctly and matches your JSON file
+ - Ensure the node IDs in the `start` and `end` references match your node IDs exactly
+ - Check that both referenced nodes were created successfully
+
+
+
+## Next steps
+
+After you're comfortable with this process, consider:
+
+- Creating more complex node types with additional properties
+- Testing multiple edge types between different node kinds
+- Reading the [OpenGraph Schema](/opengraph/schema) documentation for advanced configurations
+- Reviewing [OpenGraph Best Practices](/opengraph/best-practices) before deploying production data