From dbf3044c01dcff6be98e10f8128c92fd635f6b3c Mon Sep 17 00:00:00 2001 From: Karl Rankla Date: Wed, 11 Nov 2026 17:10:37 +0200 Subject: [PATCH] docs(integration-toolkit): rename Interactive Registration to Interactive Inbound The feature is called Interactive Inbound and covers more than registration: contract addition and customer identification in journeys use it too. Renames the page, its URL and every link to it, and redirects the old URL. --- docs/integrations/integration-toolkit/configuration.md | 8 ++++---- .../integration-toolkit/inbound/getting-started.md | 4 ++-- ...eractive-registration.md => interactive-inbound.md} | 10 +++++----- .../integration-toolkit/monitoring/codes.md | 2 +- docs/integrations/integration-toolkit/overview.md | 4 ++-- docs/integrations/integration-toolkit/use-cases.md | 6 +++--- docusaurus.config.js | 5 +++++ scripts/update-monitoring-codes.js | 2 +- 8 files changed, 23 insertions(+), 18 deletions(-) rename docs/integrations/integration-toolkit/{interactive-registration.md => interactive-inbound.md} (99%) diff --git a/docs/integrations/integration-toolkit/configuration.md b/docs/integrations/integration-toolkit/configuration.md index 197c7060..8ea79beb 100644 --- a/docs/integrations/integration-toolkit/configuration.md +++ b/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 diff --git a/docs/integrations/integration-toolkit/inbound/getting-started.md b/docs/integrations/integration-toolkit/inbound/getting-started.md index 766ddd02..9cc747c1 100644 --- a/docs/integrations/integration-toolkit/inbound/getting-started.md +++ b/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 diff --git a/docs/integrations/integration-toolkit/interactive-registration.md b/docs/integrations/integration-toolkit/interactive-inbound.md similarity index 99% rename from docs/integrations/integration-toolkit/interactive-registration.md rename to docs/integrations/integration-toolkit/interactive-inbound.md index 45906170..b5551e01 100644 --- a/docs/integrations/integration-toolkit/interactive-registration.md +++ b/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). diff --git a/docs/integrations/integration-toolkit/monitoring/codes.md b/docs/integrations/integration-toolkit/monitoring/codes.md index 7826bc3e..cfa0f7dd 100644 --- a/docs/integrations/integration-toolkit/monitoring/codes.md +++ b/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 diff --git a/docs/integrations/integration-toolkit/overview.md b/docs/integrations/integration-toolkit/overview.md index 14b56256..4705e3dc 100644 --- a/docs/integrations/integration-toolkit/overview.md +++ b/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) diff --git a/docs/integrations/integration-toolkit/use-cases.md b/docs/integrations/integration-toolkit/use-cases.md index d792c44c..28d25d57 100644 --- a/docs/integrations/integration-toolkit/use-cases.md +++ b/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. ::: --- diff --git a/docusaurus.config.js b/docusaurus.config.js index 0205563e..a6ee081c 100644 --- a/docusaurus.config.js +++ b/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/* diff --git a/scripts/update-monitoring-codes.js b/scripts/update-monitoring-codes.js index f4228f9e..77d8ace7 100644 --- a/scripts/update-monitoring-codes.js +++ b/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}`; }