@epilot/customer-portal-client 0.49.0 → 0.50.0

package/dist/openapi.d.ts

@@ -20,15 +20,72 @@ declare namespace Components {
             reason: "invalid_token";
         }
         export type Conflict = Schemas.ErrorResp;
+        export interface ContactAmbiguousMatch {
+            /**
+             * The HTTP status code, repeated in the body.
+             * example:
+             * 409
+             */
+            status: number;
+            /**
+             * Human-readable error message. For support, not for display to end customers.
+             */
+            error: string;
+            reason: "AMBIGUOUS_MATCH";
+            /**
+             * Correlation id of the ERP sync that was waited on.
+             */
+            correlation_id?: string; // ^[A-Za-z0-9_-]+$
+        }
         export interface ContractAssignmentConflict {
             /**
              * Error message
              */
             message?: string;
             /**
-             * Reason why the contract is not assignable. If the reason is "MULTIPLE", the contract is not assignable because multiple contracts were found and the business logic does not allow it.
+             * Reason why the contract is not assignable.
+             * - `DRAFT`: the contract is still a draft.
+             * - `MULTIPLE`: multiple contracts were found and the business logic does not allow it.
+             * - `SELF_ASSIGNMENT_DISABLED`: the contract already has a contact assigned and
+             *   self-assignment is disabled.
+             * - `AMBIGUOUS_MATCH`: the portal waited on the Integration Toolkit and the ERP
+             *   delivered entities it cannot tell apart (several matching the selector, or
+             *   contracts naming different customers). Nothing was assigned, and retrying
+             *   will not help.
+             *
+             */
+            reason: "DRAFT" | "MULTIPLE" | "SELF_ASSIGNMENT_DISABLED" | "AMBIGUOUS_MATCH";
+            /**
+             * The HTTP status code, repeated in the body.
+             * example:
+             * 409
+             */
+            status?: number;
+            /**
+             * Human-readable error message. For support, not for display to end customers.
+             */
+            error?: string;
+            /**
+             * Correlation id of the ERP sync that was waited on. Present only with `AMBIGUOUS_MATCH`.
+             */
+            correlation_id?: string; // ^[A-Za-z0-9_-]+$
+        }
+        export interface ContractAssignmentNotFound {
+            /**
+             * The HTTP status code, repeated in the body.
+             * example:
+             * 404
+             */
+            status: number;
+            /**
+             * Human-readable error message. For support, not for display to end customers.
              */
-            reason: "DRAFT" | "MULTIPLE";
+            error: string;
+            reason?: "TIMEOUT" | "INCOMPLETE";
+            /**
+             * Correlation id of the ERP sync that was waited on. Present with `TIMEOUT` and `INCOMPLETE`.
+             */
+            correlation_id?: string; // ^[A-Za-z0-9_-]+$
         }
         export type Forbidden = Schemas.ErrorResp;
         export type ForbiddenByRule = Schemas.ErrorResp | Schemas.FailedRuleErrorResp;
@@ -1307,13 +1364,6 @@ declare namespace Components {
              * ]
              */
             contract_identifiers?: ContractIdentifier[];
-            /**
-             * What the built-in self-assignment (without a contractIdentification hook) assigns once the `contract_identifiers` match a Contract:
-             *   - `contracts`: the user's Contact is added as a customer of the Contract.
-             *   - `customer_to_portal_user`: the Contract's customers (Contacts and Accounts) are added to the Portal User's `represents`. The Portal User sees all their data, including Contracts, transitively. Mirrors the `contact_to_portal_user` assignment mode of the contractIdentification hook.
-             *
-             */
-            self_assignment_mode?: "contracts" | "customer_to_portal_user";
             /**
              * Configuration for contract selector in the portal
              */
@@ -1854,13 +1904,6 @@ declare namespace Components {
              * ]
              */
             contract_identifiers?: ContractIdentifier[];
-            /**
-             * What the built-in self-assignment (without a contractIdentification hook) assigns once the `contract_identifiers` match a Contract:
-             *   - `contracts`: the user's Contact is added as a customer of the Contract.
-             *   - `customer_to_portal_user`: the Contract's customers (Contacts and Accounts) are added to the Portal User's `represents`. The Portal User sees all their data, including Contracts, transitively. Mirrors the `contact_to_portal_user` assignment mode of the contractIdentification hook.
-             *
-             */
-            self_assignment_mode?: "contracts" | "customer_to_portal_user";
             /**
              * Configuration for contract selector in the portal
              */
@@ -2187,6 +2230,19 @@ declare namespace Components {
              *
              */
             trigger_identifiers_check?: boolean;
+            /**
+             * Correlation id of an already triggered ERP sync, as returned by a previous call that
+             * answered `reason: TIMEOUT`. Sent together with `trigger_identifiers_check: false` on a
+             * retry so the portal keeps waiting on the same correlation instead of starting over.
+             * Only used by portals configured with
+             * `extension_hooks.registrationIdentifiersCheck.wait_for_toolkit`; ignored otherwise.
+             * At most 255 letters, digits, hyphens and underscores: the toolkit's bound for a
+             * correlation id and the charset it enforces on its identifiers.
+             *
+             * example:
+             * 0199c0d5-6f1c-7a3b-9e21-9a9ce1d1b2c3
+             */
+            correlation_id?: string; // ^[A-Za-z0-9_-]+$
         }
         /**
          * ContactExistsRequest plus the surface the token is requested for. `registration_identifiers` carries the values of the surface's effective identifiers (keyed by schema, then attribute name): the surface's own `identifiers` when it configures any, otherwise the portal's `registration_identifiers`.
@@ -2225,6 +2281,19 @@ declare namespace Components {
              *
              */
             trigger_identifiers_check?: boolean;
+            /**
+             * Correlation id of an already triggered ERP sync, as returned by a previous call that
+             * answered `reason: TIMEOUT`. Sent together with `trigger_identifiers_check: false` on a
+             * retry so the portal keeps waiting on the same correlation instead of starting over.
+             * Only used by portals configured with
+             * `extension_hooks.registrationIdentifiersCheck.wait_for_toolkit`; ignored otherwise.
+             * At most 255 letters, digits, hyphens and underscores: the toolkit's bound for a
+             * correlation id and the charset it enforces on its identifiers.
+             *
+             * example:
+             * 0199c0d5-6f1c-7a3b-9e21-9a9ce1d1b2c3
+             */
+            correlation_id?: string; // ^[A-Za-z0-9_-]+$
             /**
              * Id of the portal surface (see `surfaces` on the portal config) this token is
              * for. The surface must exist and use `authentication: registration_identifiers`;
@@ -2308,6 +2377,13 @@ declare namespace Components {
              *
              */
             reason?: "TIMEOUT" | "NOT_FOUND";
+            /**
+             * Correlation id of the triggered ERP sync. Present only with `reason: TIMEOUT`, for
+             * portals waiting on the Integration Toolkit (`wait_for_toolkit`). Send it back with
+             * `trigger_identifiers_check: false` to keep waiting on the same correlation.
+             *
+             */
+            correlation_id?: string; // ^[A-Za-z0-9_-]+$
         }
         export interface ContentWidget {
             id: string;
@@ -4164,12 +4240,35 @@ declare namespace Components {
                  * Deprecated. Use `resolved.result` instead. Contact ID usually retrieved from the response body, e.g. `{{CallResponse.data.contact_id}}`. If no result is passed and the request suceeds, we attempt to resolve the Contact ID automatically. Supports variable interpolation.
                  */
                 result?: string;
+                /**
+                 * Correlation id to wait for inbound ERP events under, resolved from the third-party
+                 * response, e.g. `{{CallResponse.data.acknowledgeId}}`. Only read when the portal is
+                 * configured to wait on the Integration Toolkit
+                 * (`extension_hooks.<hook>.wait_for_toolkit`).
+                 *
+                 * There is no default: unless a hook declares this, the portal waits on the id it
+                 * minted and handed the hook as `{{CorrelationId}}`, whatever the response carries. A
+                 * partner that pushes under that id leaves this unset; only a partner that pushes
+                 * under an id of its own declares where the response carries it. A declared id that
+                 * is absent from the response falls back to the minted one; one that is not a valid
+                 * correlation id (at most 255 letters, digits, `-` and `_`) is not waited on, and
+                 * the portal polls entity search instead.
+                 *
+                 */
+                result_correlation_id?: string;
             };
             resolved?: {
                 /**
                  * Contract or Contact ID usually retrieved from the response body, e.g. `{{CallResponse.data.contact_id}}`. If no result is passed and the request suceeds, we attempt to resolve the Contact ID automatically. Supports variable interpolation. Supersedes the deprecated `call.result`.
                  */
                 result?: string;
+                /**
+                 * Correlation id to wait for inbound ERP events under, resolved from the third-party
+                 * response, e.g. `{{CallResponse.data.acknowledgeId}}`. Supersedes
+                 * `call.result_correlation_id`. No default; see `call.result_correlation_id`.
+                 *
+                 */
+                result_correlation_id?: string;
                 /**
                  * Optional path to a human-readable error message in the third-party response body, used when the call fails (non-2xx status).
                  * If specified and the path resolves to a string, that message is forwarded to the end user instead of a generic error.
@@ -4619,12 +4718,35 @@ declare namespace Components {
                  * Deprecated. Use `resolved.result` instead. Contact ID usually retrieved from the response body, e.g. `{{CallResponse.data.contact_id}}`. If no result is passed and the request suceeds, we attempt to resolve the Contact ID automatically. Supports variable interpolation.
                  */
                 result?: string;
+                /**
+                 * Correlation id to wait for inbound ERP events under, resolved from the third-party
+                 * response, e.g. `{{CallResponse.data.acknowledgeId}}`. Only read when the portal is
+                 * configured to wait on the Integration Toolkit
+                 * (`extension_hooks.<hook>.wait_for_toolkit`).
+                 *
+                 * There is no default: unless a hook declares this, the portal waits on the id it
+                 * minted and handed the hook as `{{CorrelationId}}`, whatever the response carries. A
+                 * partner that pushes under that id leaves this unset; only a partner that pushes
+                 * under an id of its own declares where the response carries it. A declared id that
+                 * is absent from the response falls back to the minted one; one that is not a valid
+                 * correlation id (at most 255 letters, digits, `-` and `_`) is not waited on, and
+                 * the portal polls entity search instead.
+                 *
+                 */
+                result_correlation_id?: string;
             };
             resolved?: {
                 /**
                  * Contact ID usually retrieved from the response body, e.g. `{{CallResponse.data.contact_id}}`. If no result is passed and the request suceeds, we attempt to resolve the Contact ID automatically. Supports variable interpolation. Supersedes the deprecated `call.result`.
                  */
                 result?: string;
+                /**
+                 * Correlation id to wait for inbound ERP events under, resolved from the third-party
+                 * response, e.g. `{{CallResponse.data.acknowledgeId}}`. Supersedes
+                 * `call.result_correlation_id`. No default; see `call.result_correlation_id`.
+                 *
+                 */
+                result_correlation_id?: string;
                 /**
                  * Optional path to a human-readable error message in the third-party response body, used when the call fails (non-2xx status).
                  * If specified and the path resolves to a string, that message is forwarded to the end user instead of a generic error.
@@ -4655,6 +4777,137 @@ declare namespace Components {
              * The ID of the selected hook.
              */
             hook_id: string;
+            /**
+             * Opt in to waiting on the Integration Toolkit instead of polling entity search for the
+             * data the ERP pushes after the hook returns. When true, the portal hands the hook a
+             * correlation id (`{{CorrelationId}}`) and then asks the toolkit whether the entities it
+             * needs have landed under that correlation. Off by default: a portal that does not set it
+             * keeps polling entity search exactly as before.
+             *
+             * Only effective for hooks whose partner pushes through the Integration Toolkit and
+             * echoes the correlation id. A hook that answers with an epilot contact id is fetched
+             * directly, as today, whatever this flag says.
+             *
+             */
+            wait_for_toolkit?: boolean;
+            /**
+             * The entities the portal waits for, keyed by entity slug. Configured explicitly per
+             * hook: nothing is derived from the hook type or from the portal's identifier
+             * configuration, and a hook that configures no requirement for the entity the portal
+             * links does not wait at all - it keeps polling entity search exactly as before.
+             *
+             * A selector may only name an attribute that is literally a member of that entity
+             * target's configured `unique_ids` in the inbound use case, because the toolkit reports
+             * exactly those and nothing else. A selector on any other attribute can never match. A
+             * toolkit that validates selectors rejects such a wait (400) with the slug, the key and
+             * the keys it accepts; the portal logs that at error level with the hook it came from
+             * and polls entity search for the request, so the customer is unaffected and never told.
+             *
+             * The slug the portal resolves its link target from is fixed by the hook, and a
+             * requirement for it must be configured for the wait to happen at all:
+             * `registrationIdentifiersCheck` resolves the contact, every `contractIdentification`
+             * assignment mode resolves the contract (in the contact modes the linked contact is the
+             * delivered contract's `customer`). Every other configured slug is evidence that the push
+             * carried what it promised, and is never linked.
+             *
+             * Ignored unless `wait_for_toolkit` is true.
+             *
+             * Worked examples, verified against the live integration configuration. Each block is the
+             * `wait_for_entities` of one hook selection, and each names the slug that hook links.
+             *
+             * Ratingen / Wilken add-contract hook (`contractIdentification`, `contact_to_portal_user`).
+             * No value the user types is a unique id anywhere in the org - every one is a Wilken
+             * surrogate `external_id` - so the contact cannot be selected by attribute at all. Wait on
+             * the contract and link its `customer`; the identity-keyed contact is evidence that the
+             * business partner landed, and is never linked.
+             *
+             * ```yaml
+             * contract: {}
+             * contact:
+             *   key: external_id            # the PROFILE contact's unique id is external_id
+             *   from_caller_contact: external_id
+             * ```
+             *
+             * WEMAG registration hook (`registrationIdentifiersCheck`). The contact's unique ids are
+             * `customer_pin` and `reenumber`; `meter.external_id` and `meter.meter_number` are both
+             * the `ZNR` the user types.
+             *
+             * ```yaml
+             * contact:
+             *   key: reenumber
+             *   from_identifier: contact.complete_customer_number
+             *   split_on: "-"               # "0002-<customer_pin>-<reenumber>"
+             *   part: 2
+             * meter:
+             *   key: external_id
+             *   from_identifier: meter.meter_number
+             * ```
+             *
+             * WEMAG add-contract hook (`contractIdentification`, `contact_to_portal_user`). The
+             * contract's unique ids are `billing_account_number` (the `reenumber`, the same third
+             * part of `complete_customer_number`) and `customer_number` (the PIN). Wait on the
+             * contract of the typed Rechnungseinheit and link its `customer`.
+             *
+             * ```yaml
+             * contract:
+             *   key: billing_account_number
+             *   from_identifier: contact.complete_customer_number
+             *   split_on: "-"               # "0002-<customer_pin>-<reenumber>"
+             *   part: 2
+             * meter:
+             *   key: external_id
+             *   from_identifier: meter.meter_number
+             * ```
+             *
+             * Never `complete_customer_number` or `customer_number` on a WEMAG contact - neither is a
+             * unique id there - and never `customer_pin` alone on a contact or `customer_number` alone
+             * on a contract, both of which are the PIN and ambiguous, because one person has one
+             * contact and one contract per Rechnungseinheit. Never a key-less `contract` either: WEMAG's
+             * `EKM Anlagedaten` writes contracts of its own, keyed on `contract_number`.
+             *
+             * example:
+             * {
+             *   "contract": {},
+             *   "contact": {
+             *     "key": "external_id",
+             *     "from_caller_contact": "external_id"
+             *   }
+             * }
+             */
+            wait_for_entities?: {
+                [name: string]: /**
+                 * One requirement of a hook's correlation wait, for the entity slug it is configured under.
+                 *
+                 * Without `key` the requirement is satisfied by any entity of that slug. That is safe for
+                 * evidence, and for a linked slug only where the inbound use case writes exactly one entity
+                 * of it per push - Wilken's `BusinessPartnerChanged` always writes two contacts, and WEMAG's
+                 * `DocumentChange` / `D3Metadata` write contacts under the same unique-id keys a registration
+                 * push uses - so a second match answers 409 rather than linking a guess.
+                 *
+                 * With `key`, the value comes from exactly one declared source, `from_identifier` or
+                 * `from_caller_contact`. A rule whose source has no value produces no wait at all, so the
+                 * hook keeps polling rather than waiting on a requirement that cannot be met.
+                 *
+                 */
+                WaitForEntityRule;
+            };
+            /**
+             * Inbound use case slugs the portal additionally waits for. A requirement is met once at
+             * least one event of that use case slug has finished processing, whether or not it
+             * produced an entity, so it covers pushes whose entity set varies and pushes whose
+             * outcome is a file or a relation rather than an entity.
+             *
+             * Entity requirements stay primary - the portal links by entity id, so it always waits
+             * for the entity it links. Use case slugs are an additional bar: when both are
+             * configured, both must be met. Empty by default. Ignored unless `wait_for_toolkit` is
+             * true.
+             *
+             * example:
+             * [
+             *   "wilken_contract_changed"
+             * ]
+             */
+            wait_for_use_cases?: string[];
         } | null;
         /**
          * Hook that returns runtime metadata describing how a visualization should be rendered for a given portal context. Invoked by the portal before fetching data, with the same context the data hook receives.
@@ -5278,12 +5531,6 @@ declare namespace Components {
              * Design of the portal, used to preload it from the served document
              */
             design_id?: string;
-            /**
-             * The portal design as returned by design-builder parse (theme=NEW), for the served document; absent when the design could not be read
-             */
-            design?: {
-                [name: string]: any;
-            } | null;
         }
         /**
          * The meter entity
@@ -6758,13 +7005,6 @@ declare namespace Components {
              * ]
              */
             contract_identifiers?: ContractIdentifier[];
-            /**
-             * What the built-in self-assignment (without a contractIdentification hook) assigns once the `contract_identifiers` match a Contract:
-             *   - `contracts`: the user's Contact is added as a customer of the Contract.
-             *   - `customer_to_portal_user`: the Contract's customers (Contacts and Accounts) are added to the Portal User's `represents`. The Portal User sees all their data, including Contracts, transitively. Mirrors the `contact_to_portal_user` assignment mode of the contractIdentification hook.
-             *
-             */
-            self_assignment_mode?: "contracts" | "customer_to_portal_user";
             /**
              * Configuration for contract selector in the portal
              */
@@ -7515,13 +7755,6 @@ declare namespace Components {
              * ]
              */
             contract_identifiers?: ContractIdentifier[];
-            /**
-             * What the built-in self-assignment (without a contractIdentification hook) assigns once the `contract_identifiers` match a Contract:
-             *   - `contracts`: the user's Contact is added as a customer of the Contract.
-             *   - `customer_to_portal_user`: the Contract's customers (Contacts and Accounts) are added to the Portal User's `represents`. The Portal User sees all their data, including Contracts, transitively. Mirrors the `contact_to_portal_user` assignment mode of the contractIdentification hook.
-             *
-             */
-            self_assignment_mode?: "contracts" | "customer_to_portal_user";
             /**
              * Configuration for contract selector in the portal
              */
@@ -8490,13 +8723,6 @@ declare namespace Components {
              * ]
              */
             contract_identifiers?: ContractIdentifier[];
-            /**
-             * What the built-in self-assignment (without a contractIdentification hook) assigns once the `contract_identifiers` match a Contract:
-             *   - `contracts`: the user's Contact is added as a customer of the Contract.
-             *   - `customer_to_portal_user`: the Contract's customers (Contacts and Accounts) are added to the Portal User's `represents`. The Portal User sees all their data, including Contracts, transitively. Mirrors the `contact_to_portal_user` assignment mode of the contractIdentification hook.
-             *
-             */
-            self_assignment_mode?: "contracts" | "customer_to_portal_user";
             /**
              * Configuration for contract selector in the portal
              */
@@ -8960,28 +9186,6 @@ declare namespace Components {
             _schema: "portal_user";
         }
         export type PortalUserRegistrationStatus = "Registration Pending" | "Confirmation Email Sent" | "Registered" | "Email Update In Progress";
-        /**
-         * A portal whose design_id is the design asked about.
-         */
-        export interface PortalUsingDesign {
-            portal_id: /**
-             * ID of the portal
-             * example:
-             * 453ad7bf-86d5-46c8-8252-bcc868df5e3c
-             */
-            PortalId;
-            /**
-             * example:
-             * Kundenportal
-             */
-            name?: string;
-            origin?: /* Origin of the portal */ Origin;
-            /**
-             * example:
-             * 9ba94f20-b872-11ed-b30a-b3e3bf2dc8ab
-             */
-            design_id?: string;
-        }
         export type PortalWidget = EntityWidget | ContentWidget | ActionWidget | TeaserWidget | DocumentWidget | PaymentWidget | MeterReadingWidget | MeterChartWidget | CampaignWidget | ProductRecommendationsWidget;
         /**
          * A portal-facing projection of a workflow execution (V1 or V2), with the execution
@@ -10771,13 +10975,6 @@ declare namespace Components {
              * ]
              */
             contract_identifiers?: ContractIdentifier[];
-            /**
-             * What the built-in self-assignment (without a contractIdentification hook) assigns once the `contract_identifiers` match a Contract:
-             *   - `contracts`: the user's Contact is added as a customer of the Contract.
-             *   - `customer_to_portal_user`: the Contract's customers (Contacts and Accounts) are added to the Portal User's `represents`. The Portal User sees all their data, including Contracts, transitively. Mirrors the `contact_to_portal_user` assignment mode of the contractIdentification hook.
-             *
-             */
-            self_assignment_mode?: "contracts" | "customer_to_portal_user";
             /**
              * Configuration for contract selector in the portal
              */
@@ -11379,13 +11576,6 @@ declare namespace Components {
              * ]
              */
             contract_identifiers?: ContractIdentifier[];
-            /**
-             * What the built-in self-assignment (without a contractIdentification hook) assigns once the `contract_identifiers` match a Contract:
-             *   - `contracts`: the user's Contact is added as a customer of the Contract.
-             *   - `customer_to_portal_user`: the Contract's customers (Contacts and Accounts) are added to the Portal User's `represents`. The Portal User sees all their data, including Contracts, transitively. Mirrors the `contact_to_portal_user` assignment mode of the contractIdentification hook.
-             *
-             */
-            self_assignment_mode?: "contracts" | "customer_to_portal_user";
             /**
              * Configuration for contract selector in the portal
              */
@@ -11709,6 +11899,64 @@ declare namespace Components {
              */
             precision?: number;
         }
+        /**
+         * One requirement of a hook's correlation wait, for the entity slug it is configured under.
+         *
+         * Without `key` the requirement is satisfied by any entity of that slug. That is safe for
+         * evidence, and for a linked slug only where the inbound use case writes exactly one entity
+         * of it per push - Wilken's `BusinessPartnerChanged` always writes two contacts, and WEMAG's
+         * `DocumentChange` / `D3Metadata` write contacts under the same unique-id keys a registration
+         * push uses - so a second match answers 409 rather than linking a guess.
+         *
+         * With `key`, the value comes from exactly one declared source, `from_identifier` or
+         * `from_caller_contact`. A rule whose source has no value produces no wait at all, so the
+         * hook keeps polling rather than waiting on a requirement that cannot be met.
+         *
+         */
+        export interface WaitForEntityRule {
+            /**
+             * Unique-id attribute the selector matches on. Must be a member of that entity target's
+             * configured `unique_ids` in the inbound use case; the toolkit reports nothing else.
+             *
+             * example:
+             * reenumber
+             */
+            key?: string;
+            /**
+             * Identifier the user submitted to take the value from, as `<schema>.<name>` - the same
+             * schema and name the portal's `registration_identifiers` / `contract_identifiers` use.
+             * Mutually exclusive with `from_caller_contact`.
+             *
+             * example:
+             * contact.complete_customer_number
+             */
+            from_identifier?: string;
+            /**
+             * Attribute of the calling portal user's own contact to take the value from. Only
+             * available to hooks called by a signed-in user. Mutually exclusive with
+             * `from_identifier`.
+             *
+             * example:
+             * external_id
+             */
+            from_caller_contact?: string;
+            /**
+             * Separator the source value is split on before `part` is taken, for identifiers that
+             * carry a unique id inside a larger value the user types. WEMAG's
+             * `complete_customer_number` is `"0002-<customer_pin>-<reenumber>"`, so splitting on `-`
+             * and taking part 2 yields the contact's `reenumber` unique id.
+             *
+             * example:
+             * -
+             */
+            split_on?: string;
+            /**
+             * Zero-based index of the part to use after splitting on `split_on`.
+             * example:
+             * 2
+             */
+            part?: number;
+        }
         export interface WidgetAction {
             _id: string;
             type: "link" | "journey";
@@ -11830,6 +12078,12 @@ declare namespace Components {
 }
 declare namespace Paths {
     namespace AddContractByIdentifiers {
+        namespace Parameters {
+            export type CorrelationId = string; // ^[A-Za-z0-9_-]+$
+        }
+        export interface QueryParameters {
+            correlation_id?: Parameters.CorrelationId /* ^[A-Za-z0-9_-]+$ */;
+        }
         /**
          * Identifier-value pairs per schema to identify the contract
          * example:
@@ -11855,6 +12109,7 @@ declare namespace Paths {
             export type $400 = Components.Responses.InvalidRequest;
             export type $401 = Components.Responses.Unauthorized;
             export type $403 = Components.Responses.Forbidden;
+            export type $404 = Components.Responses.ContractAssignmentNotFound;
             export type $409 = Components.Responses.ContractAssignmentConflict;
             export type $500 = Components.Responses.InternalServerError;
         }
@@ -12038,9 +12293,25 @@ declare namespace Paths {
                  *
                  */
                 reason?: "TIMEOUT" | "NOT_FOUND";
+                /**
+                 * Correlation id of the triggered ERP sync. Present only for portals waiting on
+                 * the Integration Toolkit (`wait_for_toolkit`). Send it back with
+                 * `trigger_identifiers_check: false` to keep waiting on the same correlation.
+                 *
+                 */
+                correlation_id?: string; // ^[A-Za-z0-9_-]+$
+                /**
+                 * Human-readable reason the identifiers did not resolve, when the portal knows
+                 * one. Set when the ERP finished sending for this correlation without the
+                 * entities the portal needs (e.g. "account data arrived, no contract"), so
+                 * support can tell a silent timeout from an incomplete delivery.
+                 *
+                 */
+                message?: string;
             }
             export type $400 = Components.Responses.InvalidRequest;
             export type $404 = Components.Responses.NotFound;
+            export type $409 = Components.Responses.ContactAmbiguousMatch;
             export type $429 = Components.Responses.TooManyRequests;
             export type $500 = Components.Responses.InternalServerError;
         }
@@ -15442,13 +15713,6 @@ declare namespace Paths {
                  * ]
                  */
                 contract_identifiers?: Components.Schemas.ContractIdentifier[];
-                /**
-                 * What the built-in self-assignment (without a contractIdentification hook) assigns once the `contract_identifiers` match a Contract:
-                 *   - `contracts`: the user's Contact is added as a customer of the Contract.
-                 *   - `customer_to_portal_user`: the Contract's customers (Contacts and Accounts) are added to the Portal User's `represents`. The Portal User sees all their data, including Contracts, transitively. Mirrors the `contact_to_portal_user` assignment mode of the contractIdentification hook.
-                 *
-                 */
-                self_assignment_mode?: "contracts" | "customer_to_portal_user";
                 /**
                  * Configuration for contract selector in the portal
                  */
@@ -16080,13 +16344,6 @@ declare namespace Paths {
                  * ]
                  */
                 contract_identifiers?: Components.Schemas.ContractIdentifier[];
-                /**
-                 * What the built-in self-assignment (without a contractIdentification hook) assigns once the `contract_identifiers` match a Contract:
-                 *   - `contracts`: the user's Contact is added as a customer of the Contract.
-                 *   - `customer_to_portal_user`: the Contract's customers (Contacts and Accounts) are added to the Portal User's `represents`. The Portal User sees all their data, including Contracts, transitively. Mirrors the `contact_to_portal_user` assignment mode of the contractIdentification hook.
-                 *
-                 */
-                self_assignment_mode?: "contracts" | "customer_to_portal_user";
                 /**
                  * Configuration for contract selector in the portal
                  */
@@ -17272,13 +17529,6 @@ declare namespace Paths {
                  * ]
                  */
                 contract_identifiers?: Components.Schemas.ContractIdentifier[];
-                /**
-                 * What the built-in self-assignment (without a contractIdentification hook) assigns once the `contract_identifiers` match a Contract:
-                 *   - `contracts`: the user's Contact is added as a customer of the Contract.
-                 *   - `customer_to_portal_user`: the Contract's customers (Contacts and Accounts) are added to the Portal User's `represents`. The Portal User sees all their data, including Contracts, transitively. Mirrors the `contact_to_portal_user` assignment mode of the contractIdentification hook.
-                 *
-                 */
-                self_assignment_mode?: "contracts" | "customer_to_portal_user";
                 /**
                  * Configuration for contract selector in the portal
                  */
@@ -21133,9 +21383,16 @@ export interface OperationMethods {
    * addContractByIdentifiers - addContractByIdentifiers
    * 
    * Self-assign contract(s) by pre-configured identifiers.
+   * 
+   * When the portal is configured to wait on the Integration Toolkit
+   * (`extension_hooks.contractIdentification.wait_for_toolkit`) and the ERP has not finished
+   * sending within the request budget, the call fails with 404 and `reason: TIMEOUT`, carrying
+   * the `correlation_id` of the triggered sync. Repeating the call with that `correlation_id`
+   * keeps waiting on the same correlation without calling the third party again.
+   * 
    */
   'addContractByIdentifiers'(
-    parameters?: Parameters<UnknownParamsObject> | null,
+    parameters?: Parameters<Paths.AddContractByIdentifiers.QueryParameters> | null,
     data?: Paths.AddContractByIdentifiers.RequestBody,
     config?: AxiosRequestConfig  
   ): OperationResponse<Paths.AddContractByIdentifiers.Responses.$200>
@@ -23234,9 +23491,16 @@ export interface PathsDictionary {
      * addContractByIdentifiers - addContractByIdentifiers
      * 
      * Self-assign contract(s) by pre-configured identifiers.
+     * 
+     * When the portal is configured to wait on the Integration Toolkit
+     * (`extension_hooks.contractIdentification.wait_for_toolkit`) and the ERP has not finished
+     * sending within the request budget, the call fails with 404 and `reason: TIMEOUT`, carrying
+     * the `correlation_id` of the triggered sync. Repeating the call with that `correlation_id`
+     * keeps waiting on the same correlation without calling the third party again.
+     * 
      */
     'post'(
-      parameters?: Parameters<UnknownParamsObject> | null,
+      parameters?: Parameters<Paths.AddContractByIdentifiers.QueryParameters> | null,
       data?: Paths.AddContractByIdentifiers.RequestBody,
       config?: AxiosRequestConfig  
     ): OperationResponse<Paths.AddContractByIdentifiers.Responses.$200>
@@ -24541,7 +24805,6 @@ export type PortalSurfaceEntityAccess = Components.Schemas.PortalSurfaceEntityAc
 export type PortalTaskConfig = Components.Schemas.PortalTaskConfig;
 export type PortalUser = Components.Schemas.PortalUser;
 export type PortalUserRegistrationStatus = Components.Schemas.PortalUserRegistrationStatus;
-export type PortalUsingDesign = Components.Schemas.PortalUsingDesign;
 export type PortalWidget = Components.Schemas.PortalWidget;
 export type PortalWorkflow = Components.Schemas.PortalWorkflow;
 export type PortalWorkflowStage = Components.Schemas.PortalWorkflowStage;
@@ -24605,6 +24868,7 @@ export type UserRequest = Components.Schemas.UserRequest;
 export type VisualizationDataRange = Components.Schemas.VisualizationDataRange;
 export type VisualizationMetadata = Components.Schemas.VisualizationMetadata;
 export type VisualizationTypeOption = Components.Schemas.VisualizationTypeOption;
+export type WaitForEntityRule = Components.Schemas.WaitForEntityRule;
 export type WidgetAction = Components.Schemas.WidgetAction;
 export type WidgetBase = Components.Schemas.WidgetBase;
 export type WorfklowIdentifier = Components.Schemas.WorfklowIdentifier;