> For the complete documentation index, see [llms.txt](https://docs.concurrence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.concurrence.com/api-reference/change-logs/web-platform/web-platform-history-04.md).

# Web Platform History: Archive 4

Retained Web Platform history, archive 4, with original entry headings and links back to current integration guidance.

Historical entries retain their original release/source context. Use [Current Upgrade Guidance](/api-reference/change-logs/upgrade-guide.md) for current integration boundaries and [Web Platform](/api-reference/change-logs/web-platform.md) for the recent history and archive index. An older entry does not establish current availability.

<details>

<summary>v2.149.0 - Developer Console: Surface Analytics Time Window, Review Search, and Data Export (July 2026)</summary>

#### Surface Analytics Time Window, Review Search, and Data Export <a href="#surface-analytics-time-window-review-search-and-data-export" id="surface-analytics-time-window-review-search-and-data-export"></a>

The Surfaces section in the Developer Console now includes a configurable analytics time window, a search bar on the review queue, and CSV/JSON export for surface data.

**What changed:**

* **Analytics time window.** The Surface Analytics tab now includes a time window selector with options for the last 7, 30, or 90 days. Completion rates, channel effectiveness, and field abandonment cards all respect the selected window. The default is 30 days.
* **Analytics CSV export.** An **Export CSV** button on the Analytics tab downloads a CSV file containing completion-by-source, channel effectiveness, and field abandonment data for the selected time window.
* **Review queue search.** The Surface Review tab now includes a search bar that filters the review queue by title, entity, or source. A count shows how many surfaces match out of the total. When no surfaces match the search, an empty state is displayed with guidance to adjust the query.
* **Submission data export.** The Surface detail page now shows **Export JSON** and **Export CSV** buttons on the Submission card for completed surfaces. Export JSON downloads the raw submitted data as a JSON file. Export CSV converts the submitted key-value pairs into a CSV file.

**What you need to do:**

* **No action required.** These are UI enhancements to existing surfaces functionality.

</details>

<details>

<summary>v2.148.0 - Developer Console: Surface Detail - Edit, Reshape, Progress, and Archive (July 2026)</summary>

#### Surface Detail - Edit, Reshape, Progress, and Archive <a href="#surface-detail-edit-reshape-progress-and-archive" id="surface-detail-edit-reshape-progress-and-archive"></a>

The Surface detail page in the Developer Console now supports editing, reshaping, archiving, and real-time progress tracking for surfaces. The surface creation flow has also been updated with corrected channel options and email service binding.

**What changed:**

* **Edit surface.** Surfaces in `created` or `delivered` status can be edited inline. Clicking **Edit** opens the surface sheet pre-populated with the current title, description, and fields. Channel, entity, and expiry are immutable after creation and are not shown in edit mode. Saving calls the update endpoint and refreshes the detail view.
* **Reshape surface.** Surfaces in `delivered`, `opened`, or `partial` status can be reshaped. Clicking **Reshape** clones the surface's unfilled fields into a new surface and navigates to the new surface's detail page.
* **Archive surface.** Surfaces that are not already in a terminal state (`archived`, `expired`, or `completed`) can be archived. Clicking **Archive** opens a confirmation dialog. Archiving soft-deletes the surface - it no longer appears in the active list and cannot be delivered.
* **Progress tracking.** Surfaces in `delivered`, `opened`, or `partial` status now display a Progress card in the sidebar showing total fields, filled count, empty count, and a list of required fields that are still empty.
* **Channel options corrected.** The create surface sheet now offers only **Web** (generates a shareable link) and **Email** (delivers through a bound email service) channels. SMS, WhatsApp, and iMessage options have been removed - these channels were not supported by the surfaces backend and would fail silently.
* **Email service binding.** When creating a surface with the email channel, the sheet now requires selecting an email service (use case). The workspace's email services are loaded dynamically. If no email services are configured, a hint directs you to the Channels configuration.
* **Web surface link copied on create.** When a web-channel surface is created, the shareable link is automatically copied to your clipboard.
* **Deliver dialog updated.** The deliver dialog now requests an email address instead of a phone number, matching the supported email delivery channel.

**What you need to do:**

* **No action required.** These are UI enhancements. If you previously attempted to create surfaces with SMS, WhatsApp, or iMessage channels and received errors, use the Web or Email channel instead.

</details>

<details>

<summary>v2.147.0 - Developer Console: Reverted Channel Catalog and Request Access (July 2026)</summary>

#### Reverted Channel Catalog and Request Access <a href="#reverted-channel-catalog-and-request-access" id="reverted-channel-catalog-and-request-access"></a>

The Channel Catalog page and Request Access flow introduced in v2.147.0 have been reverted. The top-level Channels page, channel catalog cards, and the "Request access" dialog have been removed from the Developer Console.

**What changed:**

* **Channels catalog page removed.** The top-level Channels page that listed internal-preview channels (Email, SMS, iMessage, WhatsApp) with "Request access" buttons has been removed.
* **Request access dialog removed.** The dialog for submitting channel enablement requests to the Amigo team is no longer available in the console.
* **Navigation restored.** The sidebar "Channels" link now points to the channel provisioning pages (use cases) as a private preview feature, matching the navigation structure prior to v2.147.0. The channel provisioning pages (use cases, SES setup) remain available under their existing paths.

**What you need to do:**

* **Use the API for channel access requests.** If you need to request access to internal-preview channels, use the `POST /channels/access-requests` API endpoint directly. The console UI for this flow has been removed.

</details>

<details>

<summary>v2.146.0 - Developer Console: SQL Editor Examples Updated to Current World Model Tables (July 2026)</summary>

#### SQL Editor Examples Updated to Current World Model Tables <a href="#sql-editor-examples-updated-to-current-world-model-tables" id="sql-editor-examples-updated-to-current-world-model-tables"></a>

The SQL Editor page and agent readiness scenario sources now reference the current world model serving tables. Previously, example queries and tooltips pointed to retired table names that could cause errors when executed.

**What changed:**

* **SQL Editor description updated.** The page description now states that SELECT queries run against the current workspace-scoped world model tables rather than the retired table names.
* **SQL Editor placeholder query updated.** The example query in the SQL input field now demonstrates a workspace-scoped query against the current world model tables, including a workspace filter and specific column selection.
* **Agent readiness tooltips updated.** The world model scenario source tooltip now references the current serving tables for person projections and cohort statistics.

**What you need to do:**

* **No action required.** This is a UI correction. If you previously copied example queries from the SQL Editor placeholder, update them to use the table names now shown in the editor.

</details>

<details>

<summary>v2.145.0 - Developer Console: Workspace Selector IDs Now Copyable (July 2026)</summary>

#### Workspace Selector IDs Now Copyable <a href="#workspace-selector-ids-now-copyable" id="workspace-selector-ids-now-copyable"></a>

The workspace selection screen now displays the workspace ID for each workspace and provides a copy button, making it easier to grab workspace IDs without navigating into the workspace first.

**What changed:**

* **Workspace ID visible on each card.** Each workspace card in the selection list now shows the workspace ID below the workspace name, role, and region.
* **Copy button.** A copy button next to each workspace ID copies the ID to your clipboard. A success toast confirms the copy; if the copy fails, an error toast prompts you to copy it manually.
* **Metadata row simplified.** The workspace ID has been moved from the inline metadata line (which previously showed role, region, and ID together) to its own dedicated row. The metadata line now shows only the role and region.

**What you need to do:**

* **No action required.** This is a UI enhancement. Workspace IDs are now easier to find and copy from the workspace selection screen.

</details>

<details>

<summary>v2.144.0 - Developer Console: Removed Desktop, Prompt Logs, and Tasks Pages (July 2026)</summary>

#### Removed Desktop, Prompt Logs, and Tasks Pages <a href="#removed-desktop-prompt-logs-and-tasks-pages" id="removed-desktop-prompt-logs-and-tasks-pages"></a>

Three pages that were no longer functional have been removed from the Developer Console. These pages previously returned errors because their backing platform services were retired in earlier releases.

**What changed:**

* **Desktop page removed.** The Desktop page, which allowed connecting to and interacting with a remote desktop session (viewing screenshots, sending clicks, typing, scrolling, and disconnecting), has been removed. The Desktop entry has been removed from the sidebar command palette.
* **Prompt Logs page removed.** The Prompt Logs page, which displayed per-turn LLM input and output (system prompts, history, tool catalogs, model, and response) with filtering by conversation ID, call SID, prompt type, and state name, has been removed.
* **Tasks page removed.** The Tasks page, which allowed searching tasks by call SID and viewing task status, skill, tier, duration, and dispatch time, has been removed. The Tasks entry has been removed from the sidebar command palette.
* **Dead routes cleaned up.** Several route definitions that referenced removed pages have been cleaned up internally.

**What you need to do:**

* **No action required.** These pages were already non-functional. If you had bookmarks or links to the Desktop, Prompt Logs, or Tasks pages, those URLs will no longer resolve.

</details>

<details>

<summary>v2.143.0 - Developer Console: Agent Memory UI Removed (July 2026)</summary>

#### Agent Memory UI Removed <a href="#agent-memory-ui-removed" id="agent-memory-ui-removed"></a>

The Agent Memory section has been removed from the Developer Console. Memory inspection and management are no longer available through the console UI.

**What changed:**

* **Patient Memory page removed.** The dedicated Patient Memory page, which displayed per-patient memory facts, memory tiers (safety-critical, clinically significant, supporting context), derivation pipelines, evidence sources, and agent usage details, has been removed from the console.
* **Functional Memory configuration page removed.** The Functional Memory page, which allowed configuring memory dimensions (toggling active state, adjusting weights, adding custom dimensions) and viewing memory analytics (coverage, facts, data sources), has been removed.
* **Patient detail memory tab removed.** The memory section on individual patient detail pages, which showed memory facts and formatting, has been removed. Patient detail pages continue to display other patient information.
* **Sidebar navigation updated.** The Functional Memory link has been removed from the console sidebar. The example mode walkthrough no longer references memory inspection.

**What you need to do:**

* **No action required.** If you previously used the console to inspect or configure agent memory, note that these capabilities are no longer available in the Developer Console UI. Memory functionality at the API and agent runtime level is unaffected by this console change.

</details>

<details>

<summary>v2.142.0 - Developer Console: Conversation Detail Turn Count Alignment (July 2026)</summary>

#### Conversation Detail Turn Count Alignment <a href="#conversation-detail-turn-count-alignment" id="conversation-detail-turn-count-alignment"></a>

The conversation detail page now counts turns the same way as the conversations list, so the turn count displayed on a conversation's detail view matches the count shown in the list.

**What changed:**

* **Consistent turn counting.** The Turns metric on the conversation detail page now counts exchanges (inbound user messages) rather than all message rows. Previously, the detail page could show a turn count roughly double the list value because it counted user, agent, and system messages as individual turns. The detail page now uses the same unit as the conversations list and the API's `turn_count` field.
* **Stale-zero protection preserved.** The detail page still compares the locally computed count against the persisted `turn_count` on the conversation record and displays whichever is higher. This guards against a stale zero in the persisted count without inflating the displayed value.

**What you need to do:**

* **No action required.** This is a display correction. If you previously noticed the detail page showing a higher turn count than the conversations list for the same conversation, the values now match.

</details>

<details>

<summary>v2.141.0 - Developer Console: Channel Use Cases, Conversation Channel Filter, and SES Navigation (July 2026)</summary>

#### Channel Use Cases, Conversation Channel Filter, and SES Navigation <a href="#channel-use-cases-conversation-channel-filter-and-ses-navigation" id="channel-use-cases-conversation-channel-filter-and-ses-navigation"></a>

The Developer Console now includes a use case management page for creating, viewing, binding, and deleting channel use cases, plus a channel filter on the conversations table and sidebar navigation for SES setups.

**What changed:**

* **Channel use cases page.** A new Channels section in the sidebar (private preview) provides a use cases list page showing all channel use cases in the workspace. Each row displays the channel type, name, sender address (for email), inbox posture badges (unsubscribable, accepts cold inbound), and the currently bound service. The table supports search by name or sender address.
* **Create email use case form.** A dedicated creation form lets you define an email use case by selecting a verified SES setup (sending domain), entering a name, entity name (the display name recipients see), sender email address, optional sender display-name alias (4-40 characters, rendered in the From header), email type (transactional or marketing), and two inbox posture toggles. Marketing email automatically requires unsubscribe support. The form validates all fields before submission, matching the platform API constraints.
* **Service binding management.** Each use case row has actions to bind to a service, change the current binding, or unbind. Binding is the act that enables the channel for the workspace - inbound traffic for the use case resolves to the bound service, and outbound dispatch from the service routes through the use case. Rebinding replaces the current binding immediately. Unbinding turns the channel off.
* **Use case deletion.** Use cases can be deleted from the row actions menu. The platform API refuses deletion while a service is still bound - you must unbind first.
* **Conversation channel filter.** The conversations table now includes a Channel filter dropdown matching the calls table convention. Selecting a single channel pushes the filter to the API for server-side filtering. Selecting zero or multiple channels filters the loaded rows client-side. Available channels include voice, SMS, WhatsApp, email, web, and iMessage.
* **SES setups navigation.** The SES Setups page, previously reachable only by direct URL, now has a dedicated sidebar link under the Channels section (private preview). A shortcut button on the use cases page also links to SES setups for quick access.

**What you need to do:**

* **No action required.** These are new UI features. The Channels section is available in private preview - workspaces must be enrolled to see the sidebar links. The conversation channel filter is available to all workspaces.

</details>

<details>

<summary>v2.140.0 - Developer Console: Text Playground Entity ID Validation (July 2026)</summary>

#### Text Playground Entity ID Validation <a href="#text-playground-entity-id-validation" id="text-playground-entity-id-validation"></a>

The Text playground now validates the entity ID input before starting a session, preventing sessions that would fail server-side due to an invalid entity ID format.

**What changed:**

* **Client-side entity ID validation.** The entity ID field in the Text playground now checks that the value is either a valid UUID (e.g. `550e8400-e29b-41d4-a716-446655440000`) or a phone number before allowing the session to start. Previously, any freeform string was accepted, and invalid values caused server-side failures after session creation.
* **Inline error with destructive styling.** When the entity ID value is invalid, the input shows a red border and a descriptive error message explaining the accepted formats. The error is linked to the input via accessibility attributes for screen reader support.
* **Start action is blocked while invalid.** Clicking the start button with an invalid entity ID opens the configuration popover to surface the error instead of starting a session that would fail. Correcting or clearing the value removes the error and re-enables starting.
* **Blank values are still accepted.** An empty entity ID is valid - it starts an anonymous session, matching the previous behavior.

**What you need to do:**

* **No action required.** This is a usability improvement that prevents a class of silent failures in the Text playground. Entity IDs that were previously accepted but caused server-side errors are now caught before the session starts.

</details>

<details>

<summary>v2.139.0 - Developer Console: External Integration API Key Permissions (July 2026)</summary>

#### External Integration API Key Permissions <a href="#external-integration-api-key-permissions" id="external-integration-api-key-permissions"></a>

The Developer Console now supports External Integration permissions when creating and managing API keys, allowing fine-grained control over external OAuth integration management.

**What changed:**

* **New External Integrations permission group.** The API key permissions editor now includes an External Integrations group with four permissions: View external integrations (read external integration metadata and credentials), Create external integrations (register external OAuth integrations), Update external integrations (edit external integration metadata and credentials), and Delete external integrations (remove external integrations and revoke their credentials).
* **Admin and owner roles include all External Integration permissions.** API keys with admin or owner-level access now include all four External Integration permissions by default.
* **Member and viewer roles do not include External Integration permissions.** Lower privilege roles do not receive External Integration permissions by default. These permissions can be added manually when creating or editing an API key with a custom scope.

**What you need to do:**

* **No action required for existing API keys.** Existing keys are unaffected. When creating new API keys or updating existing ones, you can now configure External Integration permissions through the permissions editor.

</details>

<details>

<summary>v2.138.0 - Developer Console: Data API Key Permissions (July 2026)</summary>

#### Data API Key Permissions <a href="#data-api-key-permissions" id="data-api-key-permissions"></a>

The Developer Console now supports Data permissions when creating and managing API keys, allowing fine-grained control over workspace data access.

**What changed:**

* **New Data permission group.** The API key permissions editor now includes a Data group with three permissions: View data (read workspace data records), Write data (create and update workspace data records), and Query data (run queries against workspace data).
* **Viewer role includes Data:View and Data:Query.** API keys with viewer-level access now include permissions to view and query workspace data by default.
* **Member role includes Data:Write.** API keys with member-level access now include permission to create and update workspace data records by default.
* **Admin and owner roles inherit all Data permissions.** Higher privilege roles automatically include all three Data permissions.

**What you need to do:**

* **No action required for existing API keys.** Existing keys are unaffected. When creating new API keys or updating existing ones, you can now configure Data permissions through the permissions editor.

</details>

<details>

<summary>v2.137.0 - Developer Console: Text Playground Surfaces Turn Failures (July 2026)</summary>

#### Text Playground Surfaces Turn Failures <a href="#text-playground-surfaces-turn-failures" id="text-playground-surfaces-turn-failures"></a>

The Text playground now displays an error banner when a text turn fails mid-session, instead of silently showing no response.

**What changed:**

* **Error banner on mid-session failures.** When a text turn fails during an active session (for example, due to a transient backend error), the playground now shows the error in a banner at the top of the conversation. Previously, the error was hidden because the session remained connected, and the failure appeared as a silent "no response" with no indication that something went wrong.
* **Consistent error visibility.** Error banners now appear whenever an error is set and the session has not cleanly ended, regardless of whether the session is still connected. This covers both connection-level failures and per-turn failures that occur while the session remains active.

**What you need to do:**

* **No action required.** This is a fix to error visibility in the Text playground. You will now see explicit error messages in cases that previously produced silent failures.

</details>

<details>

<summary>v2.136.0 - Developer Console: Data Sources Page in Example Mode (July 2026)</summary>

#### Data Sources Page in Example Mode <a href="#data-sources-page-in-example-mode" id="data-sources-page-in-example-mode"></a>

The Developer Console now shows the real Data Sources page when a workspace is in example mode, replacing the previously hardcoded example page.

**What changed:**

* **Real Data Sources page in example mode.** Workspaces using example mode now see the same Data Sources page as regular workspaces, including the connector catalog, active sources, and file upload tabs. Previously, example mode displayed a static placeholder page with hardcoded sample data that did not reflect actual workspace configuration.
* **Removed example-only components.** The static Data Sources example page and its associated fixtures have been removed. Example mode workspaces now use the same interactive Data Sources interface as all other workspaces.

**What you need to do:**

* **No action required.** If your workspace uses example mode, the Data Sources page now shows real workspace data and controls instead of static sample content.

</details>

<details>

<summary>v2.135.0 - Developer Console: Integration Approval Policy and Playground Approve/Reject (July 2026)</summary>

#### Integration Approval Policy and Playground Approve/Reject <a href="#integration-approval-policy-and-playground-approve-reject" id="integration-approval-policy-and-playground-approve-reject"></a>

The Developer Console now supports configuring human-in-the-loop approval gates on integrations and resolving pending approvals directly from the Text playground.

**What changed:**

* **Approval policy field on integration creation.** The integration creation form now includes an Approval Policy selector with three options: None (no approval required), Writes (approve create, update, and delete calls), and All (approve every call). The default is None, which preserves existing behavior.
* **Approval policy displayed on integration detail.** The integration detail page shows the configured approval policy as a badge in the Configuration card. Integrations with no approval gate show "No approval required"; gated integrations show "Writes need approval" or "All calls need approval".
* **Playground approve/reject card.** When the agent parks a gated integration write during a Text playground conversation, an inline approval card appears above the chat input. The card shows the tool the agent wants to run and provides Approve and Reject buttons. Approving the action lets the agent proceed; rejecting it declines the action with an optional reason the agent sees. The card clears after resolution.
* **Reject with reason.** Clicking Reject opens a dialog where you can optionally provide a reason. The reason is surfaced to the agent so it can adjust its response.
* **Text and SMS only.** Approval gates are enforced on text and SMS conversation paths. Voice conversations do not yet support the approval gate.

**What you need to do:**

* **No action required for existing integrations.** The default approval policy is None, so all endpoint calls continue to execute immediately.
* **To enable approval gates,** set the Approval Policy when creating a new integration, or update an existing integration through the API. Then use the Text playground (or the API endpoints) to approve or reject pending actions during conversations.

</details>

<details>

<summary>v2.134.2 - Developer Console: CSP Updated for Call Recording Playback (July 2026)</summary>

#### CSP Updated for Call Recording Playback <a href="#csp-updated-for-call-recording-playback" id="csp-updated-for-call-recording-playback"></a>

The Content Security Policy now permits media playback from in-memory object URLs, fixing call recording playback on the Calls detail page.

**What changed:**

* **Call recording playback unblocked.** The Calls detail page plays back call recordings by fetching the audio file and creating an in-memory object URL for the browser's audio element. The previous CSP had no `media-src` directive, so the browser fell back to the default policy, which blocked these in-memory URLs. Audio and video media loads now explicitly allow the same source types as image loads (same-origin, data URIs, in-memory object URLs, and HTTPS), so recordings play without being blocked by the security policy.
* **No security regression.** The new directive mirrors the existing image source policy. No additional origins or protocols are permitted beyond what was already allowed for images.

**What you need to do:**

* **No action required.** Call recording playback on the Calls page now works without workarounds. All other console functionality is unchanged.

</details>

<details>

<summary>v2.134.1 - Developer Console: CSP Updated for Voice Playground Worklets (July 2026)</summary>

#### CSP Updated for Voice Playground Worklets <a href="#csp-updated-for-voice-playground-worklets" id="csp-updated-for-voice-playground-worklets"></a>

The Content Security Policy now permits the script sources required by the Voice playground's audio worklets, fixing voice mode in the playground.

**What changed:**

* **Voice playground audio worklets unblocked.** The Voice playground uses audio worklets for microphone capture and PCM playback. These worklets are loaded from dynamically constructed sources that browsers enforce against the CSP script-src directive. The previous policy blocked these loads, which silently broke voice mode. The CSP now allows the required source types so both the playback and recording worklets load correctly.
* **Worker-src updated.** The worker-src directive has been expanded to match, ensuring consistency between script and worker source policies.
* **No security regression.** The policy already permits inline scripts and eval for framework compatibility. The additional source types do not weaken the existing policy. The planned follow-up to move to per-request nonces will supersede the current inline/eval grants.

**What you need to do:**

* **No action required.** If you use the Voice playground, voice mode now works without workarounds. All other console functionality is unchanged.

</details>

<details>

<summary>v2.134.0 - Developer Console: Agent-First Text Playground Sessions (July 2026)</summary>

#### Agent-First Text Playground Sessions <a href="#agent-first-text-playground-sessions" id="agent-first-text-playground-sessions"></a>

The Text playground now lets you choose whether the user or the agent speaks first when starting a conversation.

**What changed:**

* **Start mode selector.** A new toggle appears next to the Start button in the Text playground. You can choose between "User first" (the default) and "Agent first" before starting a session.
* **Agent-first mode.** When you select "Agent first" and start a session, the platform sends an initial turn to the agent immediately after session creation. The agent generates the opening message without waiting for user input. This is useful for testing greeting behavior, proactive outreach scripts, and scenarios where the agent should initiate the conversation.
* **User-first mode unchanged.** The default behavior is identical to previous releases - the session waits for you to type the first message.
* **Available on new and restarted sessions.** The start mode selector appears both when starting a fresh session and when starting a new session after the previous one has ended.

**What you need to do:**

* **No action required.** The default behavior (user-first) is unchanged. Use the new toggle to test agent-initiated conversation flows.

</details>

<details>

<summary>v2.133.0 - Developer Console: Simulation Write Actions Gated by Role (July 2026)</summary>

#### Simulation Write Actions Gated by Role <a href="#simulation-write-actions-gated-by-role" id="simulation-write-actions-gated-by-role"></a>

The Developer Console now enforces role-based permissions on simulation write actions in the UI, matching the permission model already enforced by the platform API.

**What changed:**

* **Run Case button permission-gated.** The Run button on saved simulation cases in the Case Library is disabled for users whose workspace role does not carry the Service update permission. A tooltip explains that admin or owner access is required. If a 403 is returned from the API (for example, due to a role change after page load), the error message indicates the permission requirement instead of showing a generic failure.
* **Run Suite button permission-gated.** The Run button on simulation suites is disabled for viewer, operator, and member roles, with the same explanatory message. API-level 403 errors are surfaced with a clear permission message.
* **New simulation run form permission-gated.** The simulation run form (used for spot-check and bridge runs) disables the submit button and displays a permission message for roles that lack write access. The form cannot be submitted even if the user bypasses the disabled state.
* **Consistent permission messaging.** All gated actions display the same message: admin or owner access is required to run simulations.

**What you need to do:**

* **No action required.** If you have admin or owner access, simulation controls work as before. If you have viewer, operator, or member access, simulation write actions were already rejected by the API with a 403 - the console now disables those controls proactively instead of showing an error after submission.

</details>

<details>

<summary>v2.132.2 - Developer Console: CSP and HSTS Restored with CDN Compatibility (July 2026)</summary>

#### CSP and HSTS Restored with CDN Compatibility <a href="#csp-and-hsts-restored-with-cdn-compatibility" id="csp-and-hsts-restored-with-cdn-compatibility"></a>

The Developer Console re-introduces Content Security Policy (CSP) and HSTS headers, resolving the compatibility issues that caused the rollback in v2.132.1. The CSP now accounts for CDN-served static assets, so all pages render and function correctly in deployed environments.

**What changed:**

* **CSP and HSTS restored.** The full Content Security Policy and HTTP Strict Transport Security headers are back on every response. The CSP has been updated to allow script, style, and font loading from the CDN origin that serves static assets, fixing the rendering and interactivity issues seen in v2.132.0.
* **All routes covered.** Security headers are applied at both the routing configuration level (covering all pages including login, workspace selection, device approval, and static assets) and on responses issued directly by the authentication middleware (redirects, error responses). No response leaves the console without the full header set.
* **HSTS configuration unchanged.** Strict-Transport-Security uses a two-year max-age without `includeSubDomains` or `preload`, consistent with v2.132.0.
* **CSP inline/eval note.** The policy still permits inline scripts and eval to support the application framework and bundled libraries. A follow-up release will move to per-request nonces for stronger script-injection protection.

**What you need to do:**

* **No action required.** This is a security hardening change. All console functionality works as before. If you embed the Developer Console in an iframe, note that framing is blocked by both X-Frame-Options and CSP frame-ancestors.

</details>

<details>

<summary>v2.132.1 - Developer Console: Security Header Scope Adjustment (July 2026)</summary>

#### Security Header Scope Adjustment <a href="#security-header-scope-adjustment" id="security-header-scope-adjustment"></a>

The Developer Console reverted the broad Content Security Policy (CSP) and HSTS headers introduced in v2.132.0 due to compatibility issues. Core security headers remain in place on all authenticated routes.

**What changed:**

* **CSP and HSTS removed.** The Content Security Policy and HTTP Strict Transport Security headers added in v2.132.0 have been removed while the team addresses compatibility with the application framework and bundled libraries. These will be reintroduced in a future release with a refined policy.
* **Core security headers retained.** X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy, and Permissions-Policy headers continue to be applied on all responses passing through the authentication middleware. Clickjacking protection via `X-Frame-Options: DENY` remains active.
* **No change to console functionality.** All pages and features work as before. The only difference is that CSP and HSTS headers are no longer present in responses until the follow-up release.

**What you need to do:**

* **No action required.** This is an internal security adjustment. If you were relying on the HSTS or CSP headers introduced in v2.132.0, note that they are temporarily removed and will return in a future version.

</details>

<details>

<summary>v2.132.0 - Developer Console: Security Headers on All Routes (July 2026)</summary>

#### Security Headers on All Routes <a href="#security-headers-on-all-routes" id="security-headers-on-all-routes"></a>

The Developer Console now applies a full set of HTTP security headers to every route, including pages that were previously served without them.

**What changed:**

* **Security headers on all pages.** Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and X-XSS-Protection headers are now set on every response - including authentication pages, workspace selection, device approval, and static assets. Previously, some pages outside the authenticated routes were served without security headers.
* **Clickjacking protection.** Both `X-Frame-Options: DENY` and CSP `frame-ancestors 'none'` are set, providing clickjacking protection in both modern and legacy browsers.
* **HSTS enabled.** Strict-Transport-Security is set with a two-year max-age, instructing browsers to use HTTPS for all future requests to the console. The `includeSubDomains` and `preload` directives are intentionally omitted for now pending a subdomain audit.
* **Content Security Policy.** The CSP restricts script origins, disables object embeds, constrains frame embedding, and limits form actions. Note: the current policy still permits inline scripts and eval to support the application framework and bundled libraries - a follow-up will move to per-request nonces for stronger script-injection protection.
* **Consistent coverage.** Security headers are applied at both the routing configuration level and on responses issued directly by the authentication middleware (redirects, error responses), ensuring no response leaves the console without the full header set.

**What you need to do:**

* **No action required.** This is a security hardening change. All console functionality works as before. If you embed the Developer Console in an iframe, note that framing is now blocked by both X-Frame-Options and CSP frame-ancestors.

</details>

<details>

<summary>v2.131.0 - Developer Console: Device Login Preserves Return URL (July 2026)</summary>

#### Device Login Preserves Return URL <a href="#device-login-preserves-return-url" id="device-login-preserves-return-url"></a>

The Developer Console now preserves the return destination through the entire device login authentication flow. When an unauthenticated user lands on the device approval page, signs in via Google, and selects a workspace, they are automatically returned to the device approval page instead of landing on the dashboard.

**What changed:**

* **Return URL preserved through sign-in.** When the device approval page redirects an unauthenticated user to sign in, it now passes the approval page URL as a post-login destination. This destination is carried through Google authentication and workspace selection, so the user lands back on the device approval page after completing sign-in.
* **Updated sign-in prompt.** The device approval page now tells users "we'll bring you right back here afterward" instead of asking them to re-open the link from their CLI. The flow is now automatic - no manual re-navigation required.
* **Open-redirect protection.** The return URL is validated at every step in the chain to ensure it is a same-origin internal path. Protocol-relative URLs, backslash-prefixed paths, and external URLs are rejected, falling back to the default dashboard destination.

**What you need to do:**

* **No action required.** This is a UX improvement to the device login flow. Users authenticating via CLI device codes will now experience a smoother flow that returns them to the approval page automatically after sign-in.

</details>

<details>

<summary>v2.130.0 - Developer Console: Example Mode for Console Pages (July 2026)</summary>

#### Example Mode for Console Pages <a href="#example-mode-for-console-pages" id="example-mode-for-console-pages"></a>

The Developer Console now supports an example mode that displays representative sample data across all major console pages. This lets prospective users and new workspace members explore the console experience without requiring a configured workspace with live data.

**What changed:**

* **Example mode on all primary pages.** The Dashboard, Calls, Call Detail, Data Sources, Actions, Agent Memory, and Agent Readiness pages can now display pre-populated example content showing realistic healthcare workflow data - including sample agents, calls, data sources, tools, memory dimensions, and readiness results.
* **Feature-gated activation.** Example mode is controlled by a feature gate. When enabled, each console page renders example content instead of loading live workspace data. This is useful for demos, onboarding walkthroughs, and evaluating the console before connecting production systems.
* **Local override for development.** In local and preview environments, example mode can be activated via a URL parameter (`?example=1`) or session storage, allowing developers and sales teams to toggle example content without requiring a feature gate change.
* **No impact on production workspaces.** When example mode is not enabled, all pages behave exactly as before. Live data loading, filtering, and interaction are unchanged.

**What you need to do:**

* **No action required.** This is an additive feature. Existing workspaces and console behavior are unaffected. Example mode is only visible when explicitly enabled through the feature gate or local override.

</details>

<details>

<summary>v2.129.0 - Developer Console: Text Playground Action Loading State (July 2026)</summary>

#### Text Playground Action Loading State <a href="#text-playground-action-loading-state" id="text-playground-action-loading-state"></a>

The text playground turn detail panel now shows a loading indicator for available actions while a turn is in-flight, instead of displaying stale actions from a previous turn.

**What changed:**

* **Loading state for available actions.** When a message is being sent and the latest turn has not yet received its available actions from the conversation detail, the turn detail panel now displays a skeleton loading indicator under "Loading available actions" instead of showing actions from a prior turn or an empty list.
* **No more stale action display.** Previously, selecting the most recent turn while a message was in-flight could show available actions from the previously completed turn, which was misleading. The panel now correctly distinguishes between "actions not yet loaded" and "no actions available."
* **No change for completed turns.** Turns that have already received their available actions from the conversation detail continue to display them as before. The loading state applies only to the latest turn while a response is pending.

**What you need to do:**

* **No action required.** The turn detail panel now shows an explicit loading state for available actions while a turn is in-flight, so the actions displayed accurately reflect the current turn state.

</details>

<details>

<summary>v2.128.0 - Developer Console: Create Workspace Hidden for Non-Admin Users (July 2026)</summary>

#### Create Workspace Hidden for Non-Admin Users <a href="#create-workspace-hidden-for-non-admin-users" id="create-workspace-hidden-for-non-admin-users"></a>

The workspace selection page in the Developer Console no longer shows the "Create Workspace" option to users who lack the required permissions. This mirrors the backend restriction introduced in Platform API v0.9.281, where workspace creation requires the `workspaces:write` scope carried only by admin and owner credentials.

**What changed:**

* **Create Workspace button hidden for non-admin users.** The workspace selection page now checks whether the current user holds an admin or owner role in at least one existing workspace. If not, the "Create Workspace" action is not displayed. This prevents users from encountering a permission error after clicking a button that would always fail.
* **Updated empty state messaging.** Users who have no workspace memberships now see the title "No workspace access yet" and a message directing them to ask a workspace administrator for an invitation. Previously, the empty state encouraged creating a workspace, which would fail for users without admin or owner credentials.
* **No change for admin and owner users.** Users who hold admin or owner roles in at least one workspace continue to see the "Create Workspace" option as before.

**What you need to do:**

* **No action required.** This is a UX improvement that aligns the Developer Console with the backend permission model. Users who could not create workspaces before (due to the backend restriction) will no longer see a button that fails. Users with admin or owner access are unaffected.

</details>

<details>

<summary>v2.127.0 - Developer Console: One-Click Invite via Magic Link (July 2026)</summary>

#### One-Click Invite via Magic Link <a href="#one-click-invite-via-magic-link" id="one-click-invite-via-magic-link"></a>

Workspace invitation links now work end-to-end with magic-link sign-in. When an invited user clicks a magic-link that carries an invitation reference, the Developer Console signs them in and routes them directly into the invited workspace - no extra clicks required.

**What changed:**

* **Invitation-aware magic links.** Invitation emails can now include the invitation identifier in the magic-link URL. After the user clicks the link and the sign-in token is exchanged, the console detects the invitation reference and hands off to the invitation acceptance flow automatically.
* **Validated invitation reference.** The invitation identifier embedded in the link is validated as a well-formed invitation ID before it is used. If the value does not match the expected format, it is silently ignored and the user proceeds through the normal post-login flow. This prevents the redirect target from being steered to an arbitrary destination.
* **Straight-to-workspace experience.** After sign-in, the user is routed to the invitation acceptance handler, which pins the invitation and lands the user on the workspace selection page where auto-accept (introduced in v2.126.0) takes over. The combined effect is that clicking one link in an email signs the user in and drops them into the workspace.
* **Secure token handling preserved.** The sign-in token is still scrubbed from the browser URL and history immediately after extraction, before any network request is made. The invitation identifier does not extend the token's lifetime or exposure window.

**What you need to do:**

* **No action required.** This is a UX improvement for the invitation flow when using magic-link sign-in. All existing sign-in methods, invitation behavior, and workspace selection continue to work unchanged. Users who arrive via a magic link without an invitation reference see the same post-login flow as before.

</details>

<details>

<summary>v2.126.0 - Developer Console: Auto-Accept Invitation After Sign-In (July 2026)</summary>

#### Auto-Accept Invitation After Sign-In <a href="#auto-accept-invitation-after-sign-in" id="auto-accept-invitation-after-sign-in"></a>

The Developer Console now automatically accepts a pending workspace invitation when a user arrives through an invite link and completes sign-in. Previously, invited users had to click an "Accept" button on the workspace selection page after signing in - a redundant step since they already expressed intent by clicking the invite link.

**What changed:**

* **Automatic invitation acceptance.** When a user clicks an invite link, signs in (or signs up), and lands on the workspace selection page, the console now detects the pending invitation that matches the invite link and accepts it automatically. The user sees a "Joining \[workspace name]" screen with a progress indicator instead of a manual accept button.
* **Only the linked invitation is auto-accepted.** Auto-accept applies exclusively to the invitation referenced by the invite link. If a user has multiple pending invitations, only the one they clicked through is accepted automatically. All other invitations still require a deliberate click to accept.
* **Graceful fallback on failure.** If the automatic acceptance fails for any reason, the console falls back to the standard manual accept UI with the error displayed. The user can retry by clicking the accept button manually.
* **No flash of manual UI.** The "Joining" screen appears immediately when the matching invitation is detected, so there is no brief flash of the accept button before the auto-accept takes effect.

**What you need to do:**

* **No action required.** This is a UX improvement for the invitation flow. All existing sign-in methods, invitation behavior, and workspace selection continue to work unchanged. Users who arrive without an invite link see the same workspace selection page as before.

</details>

<details>

<summary>v2.125.0 - Developer Console: Passwordless Magic-Link Login (July 2026)</summary>

#### Passwordless Magic-Link Login <a href="#passwordless-magic-link-login" id="passwordless-magic-link-login"></a>

The Developer Console login page now supports passwordless magic-link sign-in as an alternative to Google OAuth. Users enter their email address and receive a single-use sign-in link - no password required.

**What changed:**

* **Magic-link sign-in option on login page.** When enabled, the login page displays an email input below the existing sign-in options. Enter your email address and click "Email me a sign-in link" to receive a one-time login link. The confirmation message is intentionally generic and does not reveal whether an account exists for the address.
* **One-click sign-in from email.** Clicking the link in the email signs you in automatically. The link is single-use and expires after a short window. If the link has already been used or has expired, you are shown a clear error with an option to request a new one.
* **Multi-workspace support.** If your account belongs to multiple workspaces, you are routed to the workspace selection page after clicking the magic link. Because magic-link tokens are single-use, an expired workspace selection session redirects you back to the login page to request a new link rather than attempting a silent re-authentication.
* **Controlled rollout.** Magic-link login is gated by a server-side configuration flag. The feature does not appear on the login page until it is explicitly enabled for your deployment.

**What you need to do:**

* **No action required for existing users.** Google OAuth and all other existing sign-in methods continue to work unchanged. Magic-link login is an additional option that appears when enabled.

</details>

<details>

<summary>v2.124.0 - Developer Console: API Keys and Personal Access Tokens Consolidated on Developer Page (July 2026)</summary>

#### API Keys and Personal Access Tokens Consolidated on Developer Page <a href="#api-keys-and-personal-access-tokens-consolidated-on-developer-page" id="api-keys-and-personal-access-tokens-consolidated-on-developer-page"></a>

The Developer Console now routes all API key and Personal Access Token (PAT) management to the tabbed Developer page. The standalone API Keys and Personal Access Tokens pages have been removed.

**What changed:**

* **Single Developer page with tabs.** API keys and Personal Access Tokens are now managed on the Developer page under the `api-keys` and `tokens` tabs respectively (`/{workspace}/developer?tab=api-keys` and `/{workspace}/developer?tab=tokens`). The previous standalone routes (`/{workspace}/api-keys` and `/{workspace}/personal-access-tokens`) have been removed.
* **Navigation updated.** Sidebar navigation, the account page quick-action links, the user menu, and the home page developer setup section all link to the appropriate Developer page tab instead of the removed standalone pages.
* **Create API Key flow unchanged.** The API key creation wizard continues to work at its existing route and returns to the Developer page API keys tab on completion or cancellation.

**What you need to do:**

* **Update any bookmarks or saved links.** If you have bookmarked `/{workspace}/api-keys` or `/{workspace}/personal-access-tokens`, update them to `/{workspace}/developer?tab=api-keys` and `/{workspace}/developer?tab=tokens` respectively.

</details>

<details>

<summary>v2.123.0 - Developer Console: Case Library and Suite Loading Improvements (July 2026)</summary>

#### Case Library and Suite Loading Improvements <a href="#case-library-and-suite-loading-improvements" id="case-library-and-suite-loading-improvements"></a>

The Developer Console Case Library and Suites pages now load case data more efficiently and display richer case detail information.

**What changed:**

* **Suite-aware case loading.** When a suite is selected on the Case Library page, the console now loads only the cases belonging to that suite rather than fetching the entire case library. Suites with explicit case lists load those cases directly; suites with required tags fetch matching cases using tag filters. Hybrid suites that use both explicit case lists and required tags load from both sources and merge the results.
* **Paginated case loading with load-more.** The Case Library now loads cases incrementally with a "Load more cases" button instead of attempting to fetch the entire library at once. The table header displays loaded and total case counts so you can see how much of the library has been fetched.
* **Improved case detail display.** The case detail panels now show temperament in the scenario section, display case ID, workspace ID, service ID, and created-by fields in the metadata section, and render evaluation criteria as structured cards instead of raw JSON. Grounding data and metadata are displayed as human-readable key-value grids with nested value support rather than collapsed JSON blocks.
* **Service filter disabled during suite filtering.** The service filter is now automatically disabled when a suite filter is active, since suite membership already determines which cases are shown.
* **Unknown suite handling.** Selecting a suite filter value that does not match any saved suite now shows a clear "Unknown simulation suite" message with an option to clear the filter, instead of showing an empty table.
* **Suites page no longer loads all cases.** The Suites page now displays suite metadata and case counts from the suites API directly, without loading the full case library. This significantly improves page load time for workspaces with large case libraries.
* **Simplified suite table display.** The Suites table now shows case counts and timestamps with a cleaner layout, removing redundant service and patient binding details that are better viewed on the Case Library page.

**What you need to do:**

* **No action required.** These are display and performance improvements. All existing case and suite data is unchanged.

</details>

<details>

<summary>v2.122.0 - Developer Console: Voice Defaults Tab Removed from Workspace Settings (July 2026)</summary>

#### Voice Defaults Tab Removed from Workspace Settings <a href="#voice-defaults-tab-removed-from-workspace-settings" id="voice-defaults-tab-removed-from-workspace-settings"></a>

The Voice Defaults tab has been removed from the Developer Console workspace settings page. Workspace-level voice configuration - including TTS provider selection, per-language TTS routing, voice ID, tone, speed, volume, domain awareness (keyterms, correction categories, pronunciation dictionary), sensitive topics, and post-call intelligence toggles - is no longer managed through workspace settings.

**What changed:**

* **Voice Defaults tab removed from settings.** The workspace settings page no longer includes a Voice Defaults tab. The remaining tabs are General and Retention.
* **Voice configuration moved to agent and service level.** Voice settings such as TTS provider, voice ID, tone, speed, and volume are now configured per agent or per service rather than as workspace-wide defaults. This gives you more granular control over voice behavior across different agents and services within a workspace.

**What you need to do:**

* **Review your voice configuration.** If you previously relied on workspace-level voice defaults, verify that your agents and services have the voice settings they need configured directly. Workspace-level defaults no longer apply.

</details>

<details>

<summary>v2.121.0 - Developer Console: Security Tab Removed from Workspace Settings (July 2026)</summary>

#### Security Tab Removed from Workspace Settings <a href="#security-tab-removed-from-workspace-settings" id="security-tab-removed-from-workspace-settings"></a>

The Security tab has been removed from the Developer Console workspace settings page. Security features including session management, IP allowlists, account lockout management, and egress IP display are no longer accessible through workspace settings.

**What changed:**

* **Security tab removed from settings.** The workspace settings page no longer includes a Security tab. The remaining tabs are General, Voice Defaults, and Retention.
* **Admin security page removed.** The standalone admin security page has also been removed. Security management for workspaces is no longer available through the Developer Console.

**What you need to do:**

* **No action required.** If you previously used the Security tab to manage IP allowlists, view locked accounts, manage sessions, or view egress IPs, these controls are no longer available in the Developer Console. Contact your account team if you need to manage workspace security settings.

</details>

<details>

<summary>v2.120.0 - Developer Console: Integration Type Handling Improvements (July 2026)</summary>

#### Integration Type Handling Improvements <a href="#integration-type-handling-improvements" id="integration-type-handling-improvements"></a>

The Developer Console now handles integration types more consistently across the tools and integrations pages, improving reliability when the API omits the integration kind field.

**What changed:**

* **Consistent integration kind display.** Integration detail pages, the integrations table, and the integration tool picker now display the integration kind reliably even when the API response omits the field. REST integrations are correctly identified and labeled throughout the console.
* **REST-specific fields shown only for REST integrations.** Configuration details like base URL, auth type, and endpoint count are now shown only for REST integrations using a consistent check. Desktop integrations no longer show empty or irrelevant REST fields.
* **Integration test dialog improvements.** The integration test dialog now correctly resolves only REST integrations when looking up tools by name or endpoint ID. Non-REST integrations are excluded from test resolution, preventing confusing error states.
* **Tool inventory filtering.** The tools overview page now filters integration endpoints to REST integrations before building the tool inventory, ensuring that only actionable REST endpoints appear in the unified tools list.

**What you need to do:**

* **No action required.** These are display and consistency improvements. No API behavior, integration configuration, or data model has changed.

</details>

<details>

<summary>v2.117.0 - Developer Console: Data Sources Connector Catalog and Page Redesign (July 2026)</summary>

#### Data Sources Connector Catalog and Page Redesign <a href="#data-sources-connector-catalog-and-page-redesign" id="data-sources-connector-catalog-and-page-redesign"></a>

The Developer Console data sources section has been redesigned with a new connector catalog, reorganized page tabs, and a detail drawer for each connector.

**What changed:**

* **Connector catalog tab.** The data sources page now opens to a Connector Catalog tab that displays all available, connected, paused, and coming-soon connectors organized by category: EHR & Clinical, CRM & Engagement, Data Warehouses, Data Lakes & Pipelines, Messaging & Telephony, and Files & Custom. Each connector is shown as a card with its name, connection protocol, and status badge. A search bar and segmented status filter let you narrow the catalog to find specific connectors.
* **Connector detail drawer.** Clicking any connector card opens a side drawer with a description, the list of entities that Amigo ingests from that system, compliance details (HIPAA, PHI handling, BAA), and connection steps. Connected or paused connectors show their current workspace status and a field mapping preview. Coming-soon connectors display a notice that the connector is under development.
* **Three-tab layout.** The page now uses three top-level tabs: Connector Catalog, Sources, and Upload. The previous two-tab layout (Sources and Upload) has been replaced. The Sources tab retains the connected sources table with filtering, search, health badges, and sync history. The Upload tab retains the existing file upload functionality.
* **Stat strips on each tab.** The Connector Catalog tab shows summary counts for connected, paused, available, and coming-soon connectors. The Sources tab shows total sources, active count, sources needing attention, and time since last sync.
* **Page header redesigned.** The data sources page header now includes a hero section describing the platform's data ingestion capabilities and a data flow diagram illustrating how sources are normalized and mapped into the world model.
* **Source count badges on tabs.** The Connector Catalog and Sources tab labels show count badges indicating the number of connectors in the catalog and the number of connected sources, respectively.
* **Default tab changed.** The data sources page now defaults to the Connector Catalog tab instead of the Sources tab.
* **Custom connector request CTA.** A footer section at the bottom of the catalog encourages users to request custom connectors, noting a two-week turnaround from request to production sync.

**What you need to do:**

* **No action required.** These are visual and navigation changes to the data sources section. No data, API behavior, or connector configuration has changed. Bookmarks or links using the previous `?view=sources` query parameter will continue to work; the new tab values are `catalog`, `active`, and `upload`.

</details>

<details>

<summary>v2.116.0 - Developer Console: Simulations Observability Improvements (July 2026)</summary>

#### Simulations Observability Improvements <a href="#simulations-observability-improvements" id="simulations-observability-improvements"></a>

The Developer Console simulations section has been redesigned with improved run grouping, richer run detail headers, and a reorganized case library layout.

**What changed:**

* **Suite runs are grouped in the runs list.** Simulation runs triggered as part of a suite execution are now collapsed into a single expandable row in the runs table. The collapsed row shows an aggregate status, total sessions and turns, and the services involved. Expand the row to see individual child runs. Standalone case runs and spot checks remain as individual rows.
* **Run source filter.** A new filter dropdown on the simulations page lets you filter the runs list by execution source: all runs, suite runs, case runs, or spot checks. The filter is also accessible via the `source` URL query parameter, so links from suite run confirmations can pre-filter to suite runs.
* **Run overview summary.** The runs list now displays summary cards showing the count of suite runs, case runs, and spot checks, along with how many runs are visible under the current filters.
* **Run detail header shows outcome cards.** The run detail page now displays three outcome cards at the top: session score (percentage of sessions passing above threshold with pass/total counts), eval results (passed/total with failed and pending breakdowns), and run status (with duration when completed).
* **Execution context on each run row.** Each run row now shows contextual information below the source badge, such as the originating suite or case ID, helping you trace a run back to its source without opening the detail page.
* **Case library redesigned.** The case library table has been rebuilt with an expandable detail row for each case. Clicking a case row expands an inline panel showing scenario, persona, eval criteria, service, labels, patient binding, and opening message. The table columns now include binding, evals summary, and suite membership.
* **Suite names shown on cases.** The case library now displays which suites each case belongs to, derived from suite membership rather than case tags.
* **Suites page simplified.** Suite cards now show service names, patient binding counts, and required tags in a compact layout. Entity preview lists and summary stat blocks have been replaced with inline metadata.
* **Suite run confirmation improved.** After triggering a suite run, the confirmation banner now shows the batch ID, skipped count, and failed-to-start count, with a direct link to the runs page filtered to suite runs.
* **Services load with full pagination.** The simulations pages now load the complete service list across all pages, so service name resolution is accurate for workspaces with large service catalogs.
* **Column renamed.** The "Source" column in the runs table has been renamed to "Execution" and the "Tags" column has been renamed to "Labels" to better describe their content.

**What you need to do:**

* **No action required.** These are visual and usability improvements to the simulations section. No data, API behavior, or simulation execution logic has changed.

</details>

<details>

<summary>v2.115.0 - Developer Console: Workspace Selection Sorted Alphabetically (July 2026)</summary>

#### Workspace Selection Sorted Alphabetically <a href="#workspace-selection-sorted-alphabetically" id="workspace-selection-sorted-alphabetically"></a>

The Developer Console workspace selection screen now sorts workspaces alphabetically by name.

**What changed:**

* **Workspaces sorted by name.** The workspace selection list displayed after login now sorts workspaces alphabetically by name using locale-aware, case-insensitive ordering with natural numeric sorting (e.g., "Workspace 2" appears before "Workspace 10"). Workspaces with identical display names are sorted by ID as a tiebreaker.
* **Display name fallback.** Workspaces without a name are sorted by their workspace ID, consistent with the existing display logic that shows the ID when no name is set.

**What you need to do:**

* **No action required.** This is a visual improvement to workspace selection ordering. No functionality or workspace data has changed.

</details>

<details>

<summary>v2.114.0 - Developer Console: Sortable Last Event Column on Data Source Entities (July 2026)</summary>

#### Sortable Last Event Column on Data Source Entities <a href="#sortable-last-event-column-on-data-source-entities" id="sortable-last-event-column-on-data-source-entities"></a>

The Developer Console data source entities table now supports sorting by the Last Event column.

**What changed:**

* **Last Event column is sortable.** The Last Event column header in the data source entities table is now a clickable sort toggle. Clicking cycles through three states: newest first, oldest first, and default ordering. A directional arrow icon indicates the current sort direction.
* **Pagination resets on sort change.** Changing the sort order resets pagination to the first page, so you always see results from the beginning of the new ordering.
* **Default behavior unchanged.** When no sort is selected, the table continues to display entities in the same default order as before.

**What you need to do:**

* **No action required.** This is an additive UI enhancement. Existing data source entity browsing behavior is unchanged unless you click the new sort toggle.

</details>

<details>

<summary>v2.113.0 - Developer Console: Sidebar Navigation Label Truncation Fixed (July 2026)</summary>

#### Sidebar Navigation Label Truncation Fixed <a href="#sidebar-navigation-label-truncation-fixed" id="sidebar-navigation-label-truncation-fixed"></a>

The Developer Console sidebar no longer truncates navigation labels when the sidebar is in its expanded state.

**What changed:**

* **Navigation labels display fully.** Previously, sidebar navigation labels could be clipped due to extra padding in the sidebar layout. Labels now display their full text in the expanded sidebar view.
* **Collapsed sidebar alignment improved.** When the sidebar is collapsed to icon-only mode, navigation icons are now centered correctly within the sidebar rail.

**What you need to do:**

* **No action required.** This is a visual fix. Navigation behavior and sidebar functionality are unchanged.

</details>

<details>

<summary>v2.112.0 - Developer Console: Execution Tier Removed from Skills UI (July 2026)</summary>

#### Execution Tier Removed from Skills UI <a href="#execution-tier-removed-from-skills-ui" id="execution-tier-removed-from-skills-ui"></a>

The Developer Console no longer displays execution tier information for skills. The skill creation wizard has been simplified to remove tier selection and computer-use-specific configuration steps.

**What changed:**

* **Tier selection step removed from skill creation.** The "Action Type" step that let you choose between orchestrated and computer use execution has been removed. All new skills use the standard orchestrated execution model. The creation wizard now starts at the template selection step.
* **Computer use configuration steps removed.** The "Execution" step (agent loop settings including max agent turns, checkpointing, and approval required) is no longer part of the skill creation wizard. These fields are no longer included in the skill creation form.
* **Tier badge removed from skills table.** The skills list table no longer shows a Tier column. The execution tier filter has been removed from the table filter controls.
* **Tier badge removed from tools inventory.** The per-service tools view no longer displays an execution tier badge on skill entries.
* **Skill detail page simplified.** The skill configuration tab no longer shows an execution tier banner or computer-use-specific agent loop configuration (max agent turns, checkpointing). The approval required field has been removed from the companion agent configuration card.

**What you need to do:**

* **No action required.** These are UI-only changes that align the Developer Console with the platform API changes in v0.9.247 that removed the computer use execution tier. Existing skills continue to work as before.

</details>

<details>

<summary>v2.111.0 - Developer Console: Integrations Table and Skill Binding Copy Simplified (July 2026)</summary>

#### Integrations Table and Skill Binding Copy Simplified <a href="#integrations-table-and-skill-binding-copy-simplified" id="integrations-table-and-skill-binding-copy-simplified"></a>

The Developer Console integrations table no longer displays the Kind column, and copy referencing "skill tools" has been simplified.

**What changed:**

* **Kind column removed from integrations table.** The integrations list no longer shows a Kind column (REST / Desktop). The Kind filter has also been removed from the table filter controls.
* **Simplified integration tool picker copy.** The integration tool picker no longer refers to "skill tools" - it now says "tools" instead. The descriptive subtitle below the "Integration Tools" heading has been removed. The empty-state message now reads "Create an integration first, then come back to wire it" instead of referencing skills.
* **Server-side filtering only.** The integrations table now uses server-side filtering exclusively. The previous client-side filtering behavior for the Kind column is no longer needed.

**What you need to do:**

* **No action required.** These are cosmetic changes. Integration functionality is unchanged.

</details>

<details>

<summary>v2.110.0 - Developer Console: Playground Service Ordering Preserved from Server (July 2026)</summary>

#### Playground Service Ordering Preserved from Server <a href="#playground-service-ordering-preserved-from-server" id="playground-service-ordering-preserved-from-server"></a>

The Developer Console playground now displays active services in the order returned by the server rather than re-sorting them alphabetically on the client.

**What changed:**

* **Server-defined service ordering.** The playground services list previously sorted active services alphabetically by name on the client side. Services are now displayed in the order the server returns them, which preserves any server-side ordering logic (such as relevance or configuration order).

**What you need to do:**

* **No action required.** The service list in the playground may appear in a different order than before. The set of displayed services has not changed - only active services are shown, with pagination for large catalogs.

</details>

<details>

<summary>v2.109.0 - Developer Console: Retention Policy Constraints Aligned with Platform API (July 2026)</summary>

#### Retention Policy Constraints Aligned with Platform API <a href="#retention-policy-constraints-aligned-with-platform-api" id="retention-policy-constraints-aligned-with-platform-api"></a>

The Developer Console retention settings now enforce the same constraints as the platform API, and save operations surface clearer feedback on success and failure.

**What changed:**

* **Minimum retention raised to 365 days.** All retention period fields (call recordings, call transcripts, audit logs, world events, PHI data) now require a minimum of 365 days, matching the platform API constraint. The previous minimum of 1 day is no longer accepted.
* **Maximum retention capped at 36,500 days.** Retention periods cannot exceed 36,500 days (approximately 100 years). Values above this limit are rejected with a validation message.
* **Whole numbers required.** Retention values must be whole numbers. Decimal values are rejected with a validation message.
* **Default values updated.** When no existing policy is set, all retention fields now default to 365 days instead of the previous defaults (90 days for most fields, 365 for audit logs).
* **Improved save feedback.** Success and error messages after saving retention settings are now more descriptive. Error messages include detail from the server response when available.

**What you need to do:**

* **Review existing retention settings.** If any retention period was previously set below 365 days, update it to at least 365 days. The form will reject values outside the 365-36,500 day range.

</details>

<details>

<summary>v2.108.0 - Developer Console: Environment Overrides Removed from Settings (July 2026)</summary>

#### Environment Overrides Removed from Settings <a href="#environment-overrides-removed-from-settings" id="environment-overrides-removed-from-settings"></a>

The Environment Overrides tab has been removed from the Developer Console workspace settings. This feature was non-functional and has been cleaned up.

**What changed:**

* **Environments tab removed.** The "Environments" tab no longer appears in workspace settings. The settings page now includes General, Voice Defaults, Retention, and Security tabs.
* **Environment override management removed.** The key-value environment variable editor that previously appeared under the Environments tab is no longer available. No data was being persisted by this feature, so no existing configuration is lost.

**What you need to do:**

* **No action required.** The removed feature was not operational. No workspace configuration has changed.

</details>

<details>

<summary>v2.107.0 - Developer Console: MFA Configuration Removed from Security Settings (July 2026)</summary>

#### MFA Configuration Removed from Security Settings <a href="#mfa-configuration-removed-from-security-settings" id="mfa-configuration-removed-from-security-settings"></a>

Multi-factor authentication (MFA) configuration has been removed from the Developer Console security settings. MFA is now managed outside the Developer Console.

**What changed:**

* **MFA card removed from Your Security.** The "Your Security" section no longer includes the MFA enrollment, verification, or unenrollment card. The section now focuses on active session management.
* **Admin MFA reset removed from Workspace Security.** The "Reset User MFA" card has been removed from the workspace security settings. Administrators can no longer reset MFA for individual users from the Developer Console.
* **Section tooltip updated.** The "Your Security" tooltip now reads "Manage your active sessions" instead of referencing multi-factor authentication.

**What you need to do:**

* **No action required.** If you previously managed MFA through the Developer Console, use your organization's identity provider or authentication service to configure MFA going forward.

</details>

<details>

<summary>v2.106.0 - Developer Console: Playground Services Pagination and Active Filter (July 2026)</summary>

#### Playground Services Pagination and Active Filter <a href="#playground-services-pagination-and-active-filter" id="playground-services-pagination-and-active-filter"></a>

The Developer Console playground now paginates services and shows only active services, making it easier to find and test services in workspaces with large service catalogs.

**What changed:**

* **Only active services shown.** The playground services section now displays only active services. Inactive services are filtered out, so the list reflects services that are ready for testing.
* **Services sorted alphabetically.** Active services are sorted by name in ascending order, so you can find services predictably in large lists.
* **Pagination support.** The playground loads services in pages. When more services are available, a "Load more services" button appears below the service grid. Clicking the button fetches the next page of results.
* **Empty state updated.** When no active services are found, the playground displays "No active services found" with guidance to activate or create a service and a link to the Services page.

**What you need to do:**

* **No action required.** The playground automatically filters to active services and supports pagination. If you have inactive services you want to test, activate them from the Services page first.

</details>

<details>

<summary>v2.105.0 - Developer Console: Simulation Cases and Suites Aligned with Platform Schema (July 2026)</summary>

#### Simulation Cases and Suites Aligned with Platform Schema <a href="#simulation-cases-and-suites-aligned-with-platform-schema" id="simulation-cases-and-suites-aligned-with-platform-schema"></a>

The Developer Console simulation cases and suites pages have been updated to match the current platform API schema for simulation cases and first-class suites.

**What changed:**

* **Case detail view updated.** The case detail page now displays scenario content (instructions, initial message) and grounding data using the current platform schema structure. The "Fixtures and grounding" section is replaced by a dedicated "Grounding" section. The "Constraints", "Target spec", and "Assertions" sections are replaced by a single "Evals" section showing evaluation criteria. A new "Metadata" section displays the full case metadata object.
* **Case source displayed.** The case detail page and case library table now show the case source from metadata instead of the previous provenance label.
* **Suite filtering loads from the API.** The Case Library page now loads suites from the platform suites API rather than deriving them from case tags. Suite options in the filter dropdown are populated from first-class suite resources, ensuring consistency with the Suites page.
* **Suites page loads suite resources.** The Suites page now fetches suites from the dedicated suites API endpoint. Suites are no longer inferred from case tags. Each suite card displays its description and required tags alongside the existing case count and entity information.
* **Suite run uses suite ID.** Running a suite from the Suites page now targets the suite-specific run endpoint using the suite ID, rather than passing required tags to the general benchmark endpoint.
* **Page descriptions updated.** The Case Library page description now reads "Durable simulation cases with embedded personas, scenarios, patient bindings, and evals." The Suites page description now reads "Customer-defined sets of simulation cases that can be reviewed and run together."
* **Empty state messaging updated.** The empty state on the Suites page now reads "Create a simulation suite to group runnable cases" instead of referencing tag-based suite inference.

**What you need to do:**

* **No action required.** These changes align the Developer Console with the current platform API schema. If you previously relied on tag-derived suites in the Developer Console, create first-class suite resources through the API to see them in the updated UI.

</details>

<details>

<summary>v2.104.0 - Developer Console: Integrations UI Migrated to SDK 0.58.0 (July 2026)</summary>

#### Integrations UI Migrated to SDK 0.58.0 <a href="#integrations-ui-migrated-to-sdk-0.58.0" id="integrations-ui-migrated-to-sdk-0.58.0"></a>

The Developer Console integrations pages have been updated to reflect the Platform API integration auth redesign and endpoint sub-resource changes introduced in SDK 0.58.0.

**What changed:**

* **Auth types updated throughout.** The integration creation wizard, detail page, and table now reflect the four new auth types: Static Header, OAuth2 Client Credentials, OAuth2 JWT Bearer, and Custom Token Exchange. The previous auth types (API Key Header, Bearer Token, Bearer Token Exchange, GCP Workload Identity, SMART Backend Services, JSON Token Exchange) are no longer available in the UI.
* **New "Custom Token Exchange" form.** The integration creation wizard includes a new form section for the Custom Token Exchange auth type, supporting exchange URL, body encoding (JSON or form), response token path (RFC 6901 JSON Pointer), static headers, static body fields, parameter headers, and parameter body fields.
* **OAuth2 JWT Bearer form expanded.** The JWT Bearer form now includes fields for assertion algorithm selection, assertion lifetime, include-iat and include-jti toggles, and an extra claims JSON editor.
* **OAuth2 Client Credentials form updated.** The Client Credentials form now includes a client auth method selector (HTTP Basic or Request Body).
* **"Secret Value" field replaces per-type secret fields.** All auth types now use a single "Secret Value" field in the creation wizard, matching the unified secret storage model in the API.
* **Integration "Kind" replaces "Protocol" and "Source".** The integrations table and detail page now display "Kind" (REST or Desktop) instead of "Protocol" and the previous "Built-in" / "Custom" source badge.
* **Endpoints loaded as a sub-resource.** The integration detail page now loads endpoints as a separate sub-resource rather than reading them inline from the integration object. The endpoint count is shown on the configuration card.
* **Inline endpoint editing removed.** The integration detail page no longer supports inline endpoint editing. Endpoint management is handled through the API or Agent Forge CLI.
* **Integration test dialog updated.** The integration test dialog in both the detail page and the playground now resolves endpoints via the sub-resource API, supporting the new endpoint data model.
* **Table filtering updated.** The integrations table now filters by "Kind" (REST, Desktop) instead of "Protocol". The kind filter is applied client-side.
* **Delete restricted to REST integrations.** Desktop integrations are system-provisioned and cannot be deleted from the Developer Console. The delete option is only shown for REST integrations.

**What you need to do:**

* **If you create integrations through the Developer Console:** The creation wizard now uses the new auth types and field names. Review the [Integration Auth Redesign changelog entry](/api-reference/change-logs/amigo-api.md) for migration details on each auth type.
* **If you previously edited endpoints inline on the detail page:** Use the Platform API or Agent Forge CLI to manage endpoints. The detail page now displays endpoints in read-only mode.

</details>

<details>

<summary>v2.103.0 - Developer Console: Tool Call Duration in Playground Inline View (July 2026)</summary>

#### Tool Call Duration in Playground Inline View <a href="#tool-call-duration-in-playground-inline-view" id="tool-call-duration-in-playground-inline-view"></a>

The Developer Console playground now displays tool call duration inline next to each tool call in the text conversation trace view.

**What changed:**

* **Tool call duration shown inline.** Each completed tool call in the inline agent trace now displays its duration in seconds with one decimal place (e.g. "1.2s", "0.1s", "12.3s"). The duration appears next to the tool name after the call completes.
* **Duration hidden for in-progress calls.** Tool calls that are still running do not show a duration chip. The duration only appears once the call has completed.
* **Failed tool calls show duration.** Failed tool calls display their duration in the same position, styled with a destructive color to visually associate the timing with the failure.
* **Zero-duration calls handled.** Instant tool calls (e.g. cache hits reporting zero duration) display "0.0s" rather than hiding the duration chip.
* **Accessible labeling.** The duration chip includes a screen-reader label describing the tool call timing.

**What you need to do:**

* **No action required.** This is an additive visual enhancement to the playground trace view. Tool call duration data was already available in the underlying events - it is now surfaced inline for easier debugging.

</details>

<details>

<summary>v2.102.0 - Developer Console: Secure Access Login Card Removed (July 2026)</summary>

#### Secure Access Login Card Removed <a href="#secure-access-login-card-removed" id="secure-access-login-card-removed"></a>

The "Secure access" informational card has been removed from the Developer Console login page. The login page now shows only the sign-in methods (Google, preview user, dev mode) without the additional security description panel.

**What changed:**

* **Secure access card removed.** The login page previously displayed an informational card below the sign-in buttons describing authentication details ("short-lived tokens and rotating refresh"). This card has been removed. The login page now ends after the sign-in method buttons.
* **Login card extracted as a standalone component.** The login UI has been refactored into a dedicated component with explicit props for each sign-in method, making the login page easier to test and maintain. No visual changes to the sign-in buttons, error banners, or reason banners.

**What you need to do:**

* **No action required.** This is a visual simplification of the login page. All sign-in methods continue to work as before.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.concurrence.com/api-reference/change-logs/web-platform/web-platform-history-04.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
