docs(integration-toolkit): rename Interactive Registration to Interactive Inbound

docs/integrations/integration-toolkit/configuration.md

@@ -136,7 +136,7 @@ Beyond the mapping itself, an inbound use case's `configuration` accepts the fol
 | Option | Values | Default | Description |
 |--------|--------|---------|-------------|
 | `direct` | boolean | `false` | Skip the mapping engine and accept entity-shaped payloads. See [Direct Mode](./inbound/direct-mode.md). |
-| `interactive` | `disabled`, `on_request`, `always` | `disabled` | Whether events of this use case may be processed on the interactive lane, so that an end customer can wait for them. See [Interactive Registration](./interactive-registration.md#allow-interactive-processing). |
+| `interactive` | `disabled`, `on_request`, `always` | `disabled` | Whether events of this use case may be processed on the interactive lane, so that an end customer can wait for them. See [Interactive Inbound](./interactive-inbound.md#allow-interactive-processing). |
 
 ```json title="Allow the request to decide"
 {
@@ -151,7 +151,7 @@ Beyond the mapping itself, an inbound use case's `configuration` accepts the fol
 
 In the Integration Hub, the option is the **Interactive processing** mode on the use case's **General** card.
 
-If a caller is going to wait on your use cases by slug (`wait_for_use_cases`), model one inbound use case per partner event type and give every use case a slug. See [Use Case Requirements](./interactive-registration.md#use-case-requirements).
+If a caller is going to wait on your use cases by slug (`wait_for_use_cases`), model one inbound use case per partner event type and give every use case a slug. See [Use Case Requirements](./interactive-inbound.md#use-case-requirements).
 
 ### Enabling/Disabling a Use Case
 
@@ -578,7 +578,7 @@ For each event, include `use_case_slug` whenever possible. `event_name` is suppo
 v3 takes `correlation_id` at request level and has no `event_type`. The deprecated v1 and v2 endpoints take
 `event_type` and, on v1, a `meta` object; v3 drops both without an error, so a `meta.correlation_id` sent to v3 is
 lost. `interactive` and `correlation_complete` are for pushes an end customer is waiting for — see
-[Interactive Registration](./interactive-registration.md#request-fields).
+[Interactive Inbound](./interactive-inbound.md#request-fields).
 
 `use_case_slug` format: `^[a-z0-9][a-z0-9_-]*$` with length `1..255` (must start with a lowercase letter or digit; then lowercase letters, digits, `_`, `-`).
 
@@ -661,7 +661,7 @@ Include a correlation ID at request level to track related events:
 ```
 
 When you omit it, epilot generates one and returns it in the response. For a correlation id an end customer is
-waiting on, see [Interactive Registration](./interactive-registration.md#correlation-ids).
+waiting on, see [Interactive Inbound](./interactive-inbound.md#correlation-ids).
 
 ### Using Correlation IDs
 

docs/integrations/integration-toolkit/inbound/getting-started.md

@@ -131,12 +131,12 @@ Events flow through the following pipeline:
 Ingestion is asynchronous: the response means "accepted and queued", not "written". When an end
 customer is waiting for the push to land — portal self-registration, adding a contract — send the
 portal's correlation id and `interactive: true` with the request, and let the portal wait on it. See
-[Interactive Registration](../interactive-registration.md).
+[Interactive Inbound](../interactive-inbound.md).
 
 ## Next Steps
 
 - [Entity Mapping](./mapping.md) - Learn about field mappings and transformations
 - [Unique Identifiers](./unique-identifiers.md) - Configure entity lookup strategies
 - [Relations](./relations.md) - Link entities together
-- [Interactive Registration](../interactive-registration.md) - Push data an end customer is waiting for
+- [Interactive Inbound](../interactive-inbound.md) - Push data an end customer is waiting for
 - [Examples](./examples.md) - See complete integration examples

docs/integrations/integration-toolkit/interactive-registration.md → docs/integrations/integration-toolkit/interactive-inbound.md

@@ -1,13 +1,13 @@
 ---
 sidebar_position: 5
-title: Interactive Registration
+title: Interactive Inbound
 description: Push ERP data an end customer is waiting for with the portal's correlation id, so the portal can wait for exactly that data
-slug: /integrations/integration-toolkit/interactive-registration
+slug: /integrations/integration-toolkit/interactive-inbound
 ---
 
-# Interactive Registration
+# Interactive Inbound
 
-Interactive registration is a mode of the [inbound API](./inbound/getting-started.md) for the flows where an end customer is waiting on screen: self-registration in the [End Customer Portal](/docs/portals/customer-portal), adding a contract or a customer account to an existing login, and public journeys that identify a customer.
+Interactive inbound is a mode of the [inbound API](./inbound/getting-started.md) for the flows where an end customer is waiting on screen: self-registration in the [End Customer Portal](/docs/portals/customer-portal), adding a contract or a customer account to an existing login, and public journeys that identify a customer.
 
 Your push stays asynchronous. Each push carries the **correlation id** the portal passed to your extension hook, its events are processed on a dedicated, rate-limited **interactive lane**, and the portal **waits on that correlation** until the entities it needs have been written.
 
@@ -93,7 +93,7 @@ The portal calls your hook with the identifiers the end customer entered and a c
 1. **`correlation_id`** — the id the portal passed to your hook, at request level.
 2. **`interactive: true`**.
 
-Both are needed. Only events processed as interactive are recorded for the wait, so a push that carries the correlation id without `interactive: true` leaves the portal nothing to wait on: it falls back to searching for the customer, as it does without interactive registration.
+Both are needed. Only events processed as interactive are recorded for the wait, so a push that carries the correlation id without `interactive: true` leaves the portal nothing to wait on: it falls back to searching for the customer, as it does without interactive inbound.
 
 Use the id the hook passed, for that customer only. A fixed, hard-coded or reused correlation id puts every registration into one correlation and breaks the wait for all of them — see [Correlation IDs](#correlation-ids).
 

docs/integrations/integration-toolkit/monitoring/codes.md

@@ -24,7 +24,7 @@ A code's level is fixed. That is what makes alert rules scoped to `_error_` or
 :::
 
 The interactive lane codes (`INTERACTIVE_*` and `CORRELATION_*`) are explained in
-context, with when each is raised, in [Interactive Registration](../interactive-registration.md#monitoring).
+context, with when each is raised, in [Interactive Inbound](../interactive-inbound.md#monitoring).
 
 ## Error
 

docs/integrations/integration-toolkit/overview.md

@@ -28,7 +28,7 @@ The Integration Toolkit is composed of the following components. Each plays a sp
 | **[ERP Integration API](#erp-integration-api)** | CRUD API to manage integrations, use cases, and mappings | Stable |
 | **[ERP Inbound API](#inbound-api)** | Dedicated API to receive and simulate inbound ERP events | Stable |
 | **[Use Cases](./use-cases.md)** | Documented integration flows with testing support | Stable |
-| **[Interactive Registration](./interactive-registration.md)** | Correlation-id contract and a dedicated lane for inbound pushes an end customer is waiting for | Stable |
+| **[Interactive Inbound](./interactive-inbound.md)** | Correlation-id contract and a dedicated lane for inbound pushes an end customer is waiting for | Stable |
 | **[Core Entities](/docs/entities/core-entities)** | Standardized entity schemas for mapping targets | Stable |
 | **[Changesets](/docs/entities/changesets)** | Pending attribute updates that wait for ERP confirmation or human approval | Stable |
 | **[Core Events](/docs/integrations/core-events)** | Standardized event payloads for outbound notifications | Stable |
@@ -161,7 +161,7 @@ Push data from your ERP into epilot. Typical flows:
 
 [Inbound Integration Guide](./inbound/getting-started.md)
 
-Inbound ingestion is asynchronous. For the flows where an end customer is waiting for the push to land — portal self-registration, adding a contract — use [Interactive Registration](./interactive-registration.md): your middleware sends the portal's correlation id with the push, the events run on a dedicated lane, and the portal waits until exactly that data has been written.
+Inbound ingestion is asynchronous. For the flows where an end customer is waiting for the push to land — portal self-registration, adding a contract — use [Interactive Inbound](./interactive-inbound.md): your middleware sends the portal's correlation id with the push, the events run on a dedicated lane, and the portal waits until exactly that data has been written.
 
 ### Outbound (epilot to ERP)
 

docs/integrations/integration-toolkit/use-cases.md

@@ -27,7 +27,7 @@ Most integrations start with inbound use cases (syncing master data into epilot)
 | [Sync Billing Events](#sync-billing-events) | [`billing_event`](/docs/entities/core-entities#billing_event), [`billing_account`](/docs/entities/core-entities#billing_account) | Invoices/payments posted in ERP |
 | [Sync Installment Schedule](#sync-installment-schedule) | [`billing_event`](/docs/entities/core-entities#billing_event), [`billing_account`](/docs/entities/core-entities#billing_account) | Installment plan (Abschlagsplan) created/changed in ERP |
 | [Sync Portal User](#sync-portal-user) | [`portal_user`](/docs/entities/core-entities#portal_user), [`contact`](/docs/entities/core-entities#contact) | Portal user registered or mapped |
-| [Interactive Registration](#interactive-registration) | [`contact`](/docs/entities/core-entities#contact), [`contract`](/docs/entities/core-entities#contract), [`billing_account`](/docs/entities/core-entities#billing_account) | Portal self-registration or contract addition, while the end customer waits |
+| [Interactive Inbound](#interactive-inbound) | [`contact`](/docs/entities/core-entities#contact), [`contract`](/docs/entities/core-entities#contract), [`billing_account`](/docs/entities/core-entities#billing_account) | Portal self-registration or contract addition, while the end customer waits |
 
 ### Outbound (epilot to ERP)
 
@@ -342,7 +342,7 @@ This use case is typically combined with [Keep Customer In Sync](#keep-customer-
 
 ---
 
-### Interactive Registration
+### Interactive Inbound
 
 Deliver a customer's data while the end customer waits for it: portal self-registration, adding a contract or a customer account to an existing login, and public journeys that identify a customer.
 
@@ -372,7 +372,7 @@ flowchart LR
 **Typical unique identifier:** `customer_number` or `contract_number` — the portal can select an entity only by one of its target's configured `unique_ids`
 
 :::tip
-The request and response contract, the failure cases, the `interactive` use case option, rate limits and the event-stream variant are on the [Interactive Registration](./interactive-registration.md) page.
+The request and response contract, the failure cases, the `interactive` use case option, rate limits and the event-stream variant are on the [Interactive Inbound](./interactive-inbound.md) page.
 :::
 
 ---

docusaurus.config.js

@@ -111,6 +111,11 @@ const DOCS_URL = process.env.DOCS_URL || 'https://docs.epilot.io'
               ],
               to: '/docs/apps/app-options',
             },
+            {
+              // The page was renamed to match the feature name
+              from: '/docs/integrations/integration-toolkit/interactive-registration',
+              to: '/docs/integrations/integration-toolkit/interactive-inbound',
+            },
           ],
           createRedirects(existingPath) {
             // Redirect old /apps/* paths to /docs/apps/*

scripts/update-monitoring-codes.js

@@ -119,7 +119,7 @@ A code's level is fixed. That is what makes alert rules scoped to \`_error_\` or
 :::
 
 The interactive lane codes (\`INTERACTIVE_*\` and \`CORRELATION_*\`) are explained in
-context, with when each is raised, in [Interactive Registration](../interactive-registration.md#monitoring).
+context, with when each is raised, in [Interactive Inbound](../interactive-inbound.md#monitoring).
 
 ${sections.join('\n')}${familySection}`;
 }