hookdeck · alexbouchardd · Apr 15, 2026 · Apr 15, 2026 · Apr 15, 2026 · Apr 15, 2026
diff --git a/docs/apis/openapi.yaml b/docs/apis/openapi.yaml
@@ -2433,7 +2433,7 @@ paths:
                     status: healthy
                   retrymq-consumer:
                     status: failed
-  /config:
+  /configs:
     get:
       tags: [Configuration]
       summary: Get Managed Configuration

diff --git a/docs/content/concepts.mdoc b/docs/content/concepts.mdoc
@@ -84,7 +84,7 @@ Configure portal behavior with `PORTAL_*` environment variables.
 {% /tab %}
 {% /tabs %}
 
-Read more about [the tenant portal](/docs/outpost/features/tenant-portal) for setup and configuration details.
+Read more about [the tenant portal](/docs/outpost/features/tenant-user-portal) for setup and configuration details.
 
 ## Event Destinations
 
@@ -113,4 +113,4 @@ For a diagram of how the API, delivery, and log services connect in **self-hoste
 
 Outpost provides observability metrics via OpenTelemetry and the Metrics API. Those metrics can be used to monitor your Outpost deployment and provide metrics to your end-users such as events failure rates by destination or events per topic.
 
-Read more about [Opentelemetry](/docs/outpost/features/opentelemetry) and [Metrics](/docs/outpost/api/metrics).
+Read more about [Opentelemetry](/docs/outpost/features/opentelemetry) and [Metrics](/docs/outpost/features/metrics).
diff --git a/docs/content/features/topics.mdoc b/docs/content/features/topics.mdoc
@@ -86,6 +86,6 @@ curl '{% $OUTPOST_API_BASE_URL %}/tenants/<TENANT_ID>' \
 }
 ```
 
-You can also subscribe to the `tenant.subscriptions.updated` [Operator Events](/operator-events) topic to receive an event when the tenant's subscribed topics change.
+You can also subscribe to the `tenant.subscriptions.updated` [Operator Events](/docs/outpost/features/operator-events) topic to receive an event when the tenant's subscribed topics change.
 
 
diff --git a/docs/content/guides/building-your-own-ui.mdoc b/docs/content/guides/building-your-own-ui.mdoc
@@ -5,7 +5,7 @@ description: "Build your own UI for users to manage their destinations and view
 
 While Outpost offers a Tenant User Portal, you may want to build your own UI so your customers can manage their destinations and view delivery activity.
 
-This page is for **teams building that destination management experience** — usually product engineers and anyone designing settings, integrations, or support tooling around webhooks and other destination types. It is framework-agnostic, covering screens, flows, and how they map to Outpost. If you use an **AI coding assistant** with Hookdeck’s optional [integration prompt](/docs/outpost/quickstarts/hookdeck-outpost-agent-prompt), that document carries workflow-specific instructions; this guide stays focused on what your **customers** should see and what your **backend** should enforce.
+This page is for **teams building that destination management experience** — usually product engineers and anyone designing settings, integrations, or support tooling around webhooks and other destination types. It is framework-agnostic, covering screens, flows, and how they map to Outpost. If you use an **AI coding assistant** you can provide it with workflow-specific instructions; this guide stays focused on what your **customers** should see and what your **backend** should enforce.
 
 The portal uses the same Outpost API you can call from your product. Its source is a useful reference ([`internal/portal`](https://github.com/hookdeck/outpost/tree/main/internal/portal), React); you are not required to match its stack.
 
@@ -62,7 +62,7 @@ For the conceptual model, see [Outpost Concepts](/docs/outpost/concepts), especi
 
 | Goal | OpenAPI entry point | In the UI |
 | ---- | ------------------- | --------- |
-| Types, labels, icons, dynamic form defs | [Destination types / schema](/docs/outpost/api/schemas) — `GET /destination-types` | Type picker; join list rows on `destination.type` (the type id is `type`, not a separate `id` on the type object). |
+| Types, labels, icons, dynamic form defs | [Destination types / schema](/docs/outpost/api#destination-types) — `GET /destination-types` | Type picker; join list rows on `destination.type` (the type id is `type`, not a separate `id` on the type object). |
 | Topics for subscriptions | [Topics](/docs/outpost/api/topics#list-topics) — `GET /topics` | Checkboxes or multi-select on create/update. |
 | List destinations | [List destinations](/docs/outpost/api/destinations#list-destinations) | Main table; show `target` / `target_url` per schema. |
 | Create destination | [Create destination](/docs/outpost/api/destinations#create-destination) | Body: `type`, `topics`, type-specific `config` / credentials per spec. |
@@ -105,7 +105,7 @@ curl --request GET "$OUTPOST_API_BASE_URL/tenants/$TENANT_ID/token" \
 
 ## Destination type metadata and dynamic config
 
-`GET /destination-types` returns everything needed to render type pickers and config forms. See the [Destination Types Schema API](/docs/outpost/api/schemas).
+`GET /destination-types` returns everything needed to render type pickers and config forms. See the [Destination Types Schema API](/docs/outpost/api#destination-types).
 
 Each entry typically includes (confirm names and optionality in OpenAPI):
 
@@ -157,7 +157,7 @@ The product flow is three steps; the API is typically one [create destination](/
 
 ### Step 1 — Choose destination type
 
-- Data: `GET /destination-types` ([schemas](/docs/outpost/api/schemas)).
+- Data: `GET /destination-types` ([schemas](/docs/outpost/api#destination-types)).
 - Show each type’s `label`, `description`, and `icon`; store the chosen `type` string.
 
 **Reference:** [CreateDestination.tsx](https://github.com/hookdeck/outpost/blob/main/internal/portal/src/scenes/CreateDestination/CreateDestination.tsx)

diff --git a/docs/content/guides/migrate-to-outpost.mdoc b/docs/content/guides/migrate-to-outpost.mdoc
@@ -60,7 +60,7 @@ Webhooks are delivered via HTTP `POST` requests.
 ### Webhook Event HTTP Headers
 
 - `x-outpost-event-id`: A unique identifier for the event within the Outpost installation
-- `x-outpost-signature`: HMAC of the raw body (default `v0=<hex>`; operators may customize templates — see [Webhook destination](/docs/destinations/webhook#signature)).
+- `x-outpost-signature`: HMAC of the raw body (default `v0=<hex>`; operators may customize templates — see [Webhook destination](/docs/outpost/destinations/webhook#signature)).
 - `x-outpost-timestamp`: A Unix timestamp representing the time the event was generated
 - `x-outpost-topic`: The topic of the event. For example, `user.created`.
 
@@ -134,7 +134,7 @@ The Outpost schema contains two tables related to events:
 
 The following diagram shows the Outpost schema. You can connect to the database instance within your Outpost installation to inspect the schema further.
 
-![Event Destination Request List](../../public/images/outpost-schema.png)
+![Event Destination Request List](/outpost-images/outpost-schema.png)
 
 #### Example Migration Script
 

diff --git a/docs/content/nav.json b/docs/content/nav.json
@@ -125,6 +125,7 @@
   ],
   "/docs/outpost/quickstarts": {
     "title": "Quickstarts",
+    "icon": "quickstart-icon",
     "structure": [
       {
         "label": "Quickstarts",
@@ -154,6 +155,7 @@
   },
   "/docs/outpost/self-hosting": {
     "title": "Self-Hosting",
+    "icon": "self-hosting-icon",
     "structure": [
       {
         "label": "Overview",

diff --git a/docs/content/publishing/events.mdoc b/docs/content/publishing/events.mdoc
@@ -14,9 +14,9 @@ Events can be published in two ways:
 **2. Via a message queue** — Publish events directly to the message queue that Outpost consumes. Higher durability since there's no additional dependency beyond the queue itself.
 
 If you already publish events to a supported message queue, refer to the relevant guide:
-- [Publish from RabbitMQ](/docs/outpost/guides/publish-from-rabbitmq)
-- [Publish from SQS](/docs/outpost/guides/publish-from-sqs)
-- [Publish from GCP Pub/Sub](/docs/outpost/guides/publish-from-gcp-pubsub)
+- [Publish from RabbitMQ](/docs/outpost/publishing/publish-from-rabbitmq)
+- [Publish from SQS](/docs/outpost/publishing/publish-from-sqs)
+- [Publish from GCP Pub/Sub](/docs/outpost/publishing/publish-from-gcp-pubsub)
 
 ## Event Structure
 
@@ -94,7 +94,7 @@ When an event is published, Outpost evaluates it against all tenant destinations
 
 Each call to `GET /api/v1/tenants/:tenant_id` returns a `topics` array listing all topics currently in use across that tenant's destinations. You can cache this value in your application and use it to skip the publish call entirely when no destination would match a given topic.
 
-You can also subscribe to the `tenant.subscriptions.updated` [Operator Events](/operator-events) topic to receive an event when the tenant's subscribed topics change.
+You can also subscribe to the `tenant.subscriptions.updated` [Operator Events](/docs/outpost/features/operator-events) topic to receive an event when the tenant's subscribed topics change.
 
 While this is optional, it is strongly recommended to perform pre-filtering on topics. This limits the network calls from your application (reducing operation latency) and reduces resource consumption on Outpost services.
 

diff --git a/docs/content/publishing/publish-from-gcp-pubsub.mdoc b/docs/content/publishing/publish-from-gcp-pubsub.mdoc
@@ -7,7 +7,7 @@ This guide provides information on using GCP Pub/Sub to publish events to Outpos
 
 ## Message Structure
 
-GCP Pub/Sub messages should have the same payload structure as the [Publish API endpoint](/docs/api/publish).
+GCP Pub/Sub messages should have the same payload structure as the [Publish API endpoint](/docs/outpost/publishing/events).
 
 ```json
 {

diff --git a/docs/content/publishing/publish-from-hookdeck-event-gateway.mdoc b/docs/content/publishing/publish-from-hookdeck-event-gateway.mdoc
@@ -7,7 +7,7 @@ This guide provides information on using GCP Pub/Sub to publish events to Outpos
 
 ## Message Structure
 
-GCP Pub/Sub messages should have the same payload structure as the [Publish API endpoint](/docs/api/publish).
+GCP Pub/Sub messages should have the same payload structure as the [Publish API endpoint](/docs/outpost/publishing/events).
 
 ```json
 {

diff --git a/docs/content/publishing/publish-from-rabbitmq.mdoc b/docs/content/publishing/publish-from-rabbitmq.mdoc
@@ -7,7 +7,7 @@ This guide provides information on using RabbitMQ to publish events to Outpost.
 
 ## Message Structure
 
-RabbitMQ messages should have the same payload structure as the [Publish API endpoint](/docs/api/publish).
+RabbitMQ messages should have the same payload structure as the [Publish API endpoint](/docs/outpost/publishing/events).
 
 ```json
 {

diff --git a/docs/content/publishing/publish-from-sqs.mdoc b/docs/content/publishing/publish-from-sqs.mdoc
@@ -7,7 +7,7 @@ This guide provides information on using SQS to publish events to Outpost.
 
 ## Message Structure
 
-SQS messages should have the same payload structure as the [Publish API endpoint](/docs/api/publish).
+SQS messages should have the same payload structure as the [Publish API endpoint](/docs/outpost/publishing/events).
 
 ```json
 {

diff --git a/docs/content/quickstarts/overview.mdoc b/docs/content/quickstarts/overview.mdoc
@@ -11,7 +11,6 @@ Use Hookdeck’s hosted Outpost API with your dashboard API key and preconfigure
 - [TypeScript](/docs/outpost/quickstarts/hookdeck-outpost-typescript)
 - [Python](/docs/outpost/quickstarts/hookdeck-outpost-python)
 - [Go](/docs/outpost/quickstarts/hookdeck-outpost-go)
-- [Agent prompt template](/docs/outpost/quickstarts/hookdeck-outpost-agent-prompt) (for AI-assisted integration)
 
 ## Self-hosted
 

diff --git a/docs/content/self-hosting/architecture.mdoc b/docs/content/self-hosting/architecture.mdoc
@@ -5,7 +5,7 @@ description: "The architecture of Outpost for self-hosted deployments."
 
 ## Architecture
 
-![Outpost Architecture](../../public/images/architecture.png)
+![Outpost Architecture](/outpost-images/architecture.png)
 
 Outpost consists of three services that can be run as a single process or as separate deployments for independent scaling.
 

diff --git a/docs/content/self-hosting/changelog/upgrade-v0.12.mdoc b/docs/content/self-hosting/changelog/upgrade-v0.12.mdoc
@@ -231,7 +231,7 @@ v0.12 introduces a new `GET /api/v1/tenants` endpoint for listing all tenants wi
 This endpoint requires Redis with the RediSearch module (e.g., `redis/redis-stack-server`). If RediSearch is not available, the endpoint returns `501 Not Implemented`.
 :::
 
-See the [API Reference](/docs/api/tenants#list-tenants) for details.
+See the [API Reference](/docs/outpost/api/tenants#list-tenants) for details.
 
 ### Migrations Included
 
@@ -243,7 +243,7 @@ See the [API Reference](/docs/api/tenants#list-tenants) for details.
 These migrations require a maintenance window and must be run manually before starting Outpost v0.12.
 
 :::note
-These commands require environment variables for Redis connection (`REDIS_HOST`, `REDIS_PORT`, `REDIS_PASSWORD`, etc.). You can also use `--config` to pass a config file. See the [Schema Migration Guide](/guides/migration#configuration) for details.
+These commands require environment variables for Redis connection (`REDIS_HOST`, `REDIS_PORT`, `REDIS_PASSWORD`, etc.). You can also use `--config` to pass a config file. See the [Schema Migration Guide](/docs/outpost/self-hosting/guides/migration#configuration) for details.
 :::
 
 ```bash
@@ -261,7 +261,7 @@ docker run --rm -e REDIS_HOST=... -e REDIS_PASSWORD=... hookdeck/outpost:v0.12.0
 ```
 
 :::tip[Migration Tool Reference]
-For detailed information on the migration workflow, safety features, and troubleshooting, see the [Schema Migration Guide](/guides/migration).
+For detailed information on the migration workflow, safety features, and troubleshooting, see the [Schema Migration Guide](/docs/outpost/self-hosting/guides/migration).
 :::
 
 ## Upgrade Checklist

diff --git a/docs/content/self-hosting/deployment.mdoc b/docs/content/self-hosting/deployment.mdoc
@@ -29,7 +29,7 @@ You can omit the `service` entry point to start all 3 services within the same p
 
 Since each service has different usage and performance profiles, it's recommended that each service be operated and scaled independently.
 
-![Outpost Architecture](../../public/images/architecture.png)
+![Outpost Architecture](/outpost-images/architecture.png)
 
 :::info
 

diff --git a/docs/content/self-hosting/guides/byo-mqs.mdoc b/docs/content/self-hosting/guides/byo-mqs.mdoc
@@ -34,7 +34,7 @@ Outpost requires **two separate internal message queue systems**:
 Each system must be provisioned independently with its own queues, topics, or subscriptions depending on your message queue provider.
 
 :::note
-Outpost also supports an optional **Publish MQ** for ingesting events from external message queues. This is separate from the internal queues discussed here and is not managed by the `MQS_AUTO_PROVISION` setting. See the [publish from message queue guides](/guides) for more information.
+Outpost also supports an optional **Publish MQ** for ingesting events from external message queues. This is separate from the internal queues discussed here and is not managed by the `MQS_AUTO_PROVISION` setting. See the [publish from message queue guides](/docs/outpost/overview) for more information.
 :::
 
 ## Message Queue Characteristics

diff --git a/docs/content/self-hosting/guides/migration.mdoc b/docs/content/self-hosting/guides/migration.mdoc
@@ -20,7 +20,7 @@ docker run --rm hookdeck/outpost --version
 
 ## Migration Workflow
 
-The recommended approach is to run `outpost migrate apply --yes` before every `outpost serve`. This is safe to run on every startup — if there are no pending migrations, the command exits immediately. See the [Upgrade to v0.17](/self-hosting/changelog/upgrade-v0.17) guide for more details on this change.
+The recommended approach is to run `outpost migrate apply --yes` before every `outpost serve`. This is safe to run on every startup — if there are no pending migrations, the command exits immediately. See the [Upgrade to v0.17](/docs/outpost/self-hosting/changelog/upgrade-v0.17) guide for more details on this change.
 
 How you integrate this depends on your deployment setup. Below are some common patterns.
 
@@ -212,7 +212,7 @@ redis:
   cluster_enabled: false
 ```
 
-For a complete list of configuration options, see the [Configuration Reference](/references/configuration).
+For a complete list of configuration options, see the [Configuration Reference](/docs/outpost/self-hosting/configuration).
 
 ## Troubleshooting
 

diff --git a/docs/content/self-hosting/upgrade-v0.16.mdoc b/docs/content/self-hosting/upgrade-v0.16.mdoc
@@ -114,7 +114,7 @@ The `attempts.response_data` column is migrated from JSONB to TEXT (migration `0
 
 ## Alert Callbacks Replaced by Operator Events
 
-The `ALERT_CALLBACK_URL` config has been removed. Alert notifications are now handled by the new [operator events](/features/operator-events) system, which supports multiple sink types and additional event topics.
+The `ALERT_CALLBACK_URL` config has been removed. Alert notifications are now handled by the new [operator events](/docs/outpost/features/operator-events) system, which supports multiple sink types and additional event topics.
 
 ### Migration
-Original file line number
+Diff line change
@@ Expand Up / @@ -86,6 +86,6 @@ curl '{% $OUTPOST_API_BASE_URL %}/tenants/<TENANT_ID>' \ @@
     }
     ```
-    You can also subscribe to the `tenant.subscriptions.updated` [Operator Events](/operator-events) topic to receive an event when the tenant's subscribed topics change.
+    You can also subscribe to the `tenant.subscriptions.updated` [Operator Events](/docs/outpost/features/operator-events) topic to receive an event when the tenant's subscribed topics change.