What shipped, and when

Added

• Each documentation portal shows how well AI agents can read it. The new Agent Readiness card on the Insights tab of the portal settings scores the published portal against the Agent-Friendly Docs Spec. It shows an overall grade, a score per category and every check that did not pass. Each open check is filed under Fix in your content or settings or Handled by Routebase, and a missing meta description links straight to the SEO field. Run check samples up to 50 published pages, requires docs:manage-portal and is part of every plan, with five checks per portal and day.
• Documentation portals answer AI agents in Markdown. A request with Accept: text/markdown receives the Markdown version of a portal page instead of its HTML. Every page points agents to the portal's llms.txt, links in the Markdown versions are absolute, and the overview page of each API reference now has a Markdown version as well.
• OpenAPI default responses and status ranges such as 4XX are part of the response model. Import, export, version comparison, branch merges and version clones carry the key as written, and the designer labels a default response as Any other status. The mock server, schema assertions and monitors pick an exact status first, then a range, then default. The style guide accepts a default response next to a success response as a defined error response.

Improved

• API reference pages carry every operation in their HTML. Descriptions, parameters, request bodies and responses are part of the page as delivered, so search engines and agents read them without running JavaScript. Tag pages are titled after their tag, and the description of a specification becomes the meta description of its reference pages.
• docs pull and docs push carry the meta description and keywords of each page. The CLI writes both as frontmatter when it pulls and sends them back when it pushes, so the SEO metadata of a page lives in your repository next to its content. This ships as Routebase.Cli 2.1.0 with unchanged exit codes and flags.
• Every page on routebase.dev is available in Markdown. An agent that asks for text/markdown receives a Markdown version of the page, and each page points to llms.txt.
• Mail to routebase.dev travels only over encrypted connections. The MTA-STS policy of the domain is enforced, so a sending server that cannot open an encrypted connection holds the message and retries rather than delivering it in plain text.

Added

• Specifications can be authored, imported and exported as OpenAPI 3.2. The designer now reads and writes 3.0, 3.1 and 3.2, and a new specification starts as 3.2 unless you pick another version. An imported file keeps the version it declares, and the import preview lists everything it found before anything is created. The 3.2 constructs travel all the way through. Reusable media types under components.mediaTypes, the document $self URI, discriminator.defaultMapping, xml.nodeType and examples in both data and wire form are imported, edited in the designer, exported and rendered in the documentation portal.
• The HTTP method QUERY can be designed, tested, mocked and monitored. QUERY is a safe read whose parameters travel in the request body, and OpenAPI 3.2 gives it a field of its own. The designer offers it on 3.2 specifications, and the test runner, the mock server, monitors and the security scanner send it. The documentation portal renders it with its own badge and code samples in every language.
• Streaming responses carry an item schema. JSON Lines, JSON text sequences, server-sent events and multipart bodies describe the shape of one item with itemSchema, and Routebase imports, edits and exports it alongside the body schema. The mock server streams such a body as a sequence of items, with a delay per item you choose, and the test runner validates every item on its own.
• The test runner obtains tokens through the OAuth device authorization flow. Security schemes carry the 3.2 fields deprecated and oauth2MetadataUrl together with the device flow, and the OAuth 2.0 configuration of a suite or test case gains the grant type deviceCode. Get New Token shows the user code and the verification link, polls the token endpoint at the interval the provider names, and a token obtained this way refreshes like any other.
• Parameters carry style and explode, and a 3.2 specification can describe the whole query string as one parameter. All eight OpenAPI styles are available for path, query, header and cookie parameters, only a value that differs from the default is stored and exported, and in: querystring describes the complete query string through a media type. The designer edits them in the Advanced popover, Try It sends a query string exactly as written, and the documentation portal shows the settings on the lines that carry them.
• The designer has a tag manager, and tags form a hierarchy. A new Tags row in the sidebar opens a list where you order tags, edit their summary, choose a parent and assign a kind, as OpenAPI 3.2 describes them. A published portal without designer folders nests its navigation from that hierarchy, with stable anchors and slugs.
• Review mode has an Only changes switch. It reduces endpoints and schemas to what changed since the baseline, hides folders without a change and expands the rest, so a large specification shows its changes without scrolling. The bar above counts endpoints and schemas separately, and the folder badges tell new endpoints from changed ones.
• The suite overview shows the contract coverage of a test suite. The card names how many test cases are linked to a specification endpoint, how many endpoints that covers and how many links show schema drift since they were made. It appears as soon as a suite has its first link.
• A running security scan shows its progress. The live view names the scanner at work and counts finished scanners and checks while the run is going, in the product and through list_scan_runs. A cancelled run reports how far it got.
• The style guide checks whether a create endpoint accepts an idempotency key. The rule should-have-idempotency-key reports a POST that declares a 201 response without an idempotency header, with Info severity by default and the usual overrides per organization and project. Accepted are Idempotency-Key, X-Idempotency-Key and Idempotency-Token.
• Routebase has a public API reference, built with Routebase. The new API Reference section on docs.routebase.dev documents the endpoints the CLI and SCIM use, rendered by the same portal you publish with. Everything else under /api/ is internal and documented as such.
• Ten long-form guides are live on routebase.dev. They cover API testing, authentication, versioning, documentation, OpenAPI, monitoring, the decisions before a specification, mock servers, governance and security, each chapter under its own URL. The guides show how each method looks in Routebase and link the matching product guide.

Improved

• MCP tool descriptions say when to use a tool and name its neighbour. Each description that had a close alternative gained a sentence naming it, and single-item and list tools point at each other. No tool was renamed and no signature changed.
• list_schemas returns the row version that update_schema needs. An agent updating many schemas no longer fetches each one first.
• A vulnerability report to routebase.dev can be encrypted, and the domain's DNS answers are signed. The security.txt names an OpenPGP key for reports, DNSSEC covers every answer for routebase.dev, and mail to the domain is protected by DMARC at its strictest level.
• The website is fully operable with keyboard and screen reader, and every text meets the highest contrast level. Focus rings are visible on every button, tables and code blocks scroll by keyboard, and a Pause animation switch stops moving backgrounds.

Added

• Routebase is on the Microsoft Marketplace. Buy Routebase through Azure and pay for it on your existing Microsoft bill, with the seat count and the plan coming straight from the purchase. The activation page shows what you bought before anything is created, and you choose where your workspace lives — European Union or United States — the same choice every other sign-up gets, because a workspace's region is fixed once it exists. Starter and Pro include 14 free days, and the plan card names the trial and its end date, so a subscription that turns into a paid one by doing nothing is visible in the product rather than only in the purchase mail. During the trial the full limits of the purchased plan apply.
• Sign in with Microsoft. Alongside email and password, the sign-in page offers Continue with Microsoft — work, school and personal Microsoft accounts through one entry point. If you already have an account under the same address, signing in this way attaches to it rather than creating a second one.
• Routebase runs as a GitHub Action. routebase-dev/routebase-action runs a test suite, starts a security scan, or records after a deploy which version an environment actually serves — three lines in a workflow file, with nothing to install first. Two results land where GitHub shows them itself: test runs as a JUnit report in the pull request summary, security findings as SARIF in the Security tab. The CLI version the action uses is pinned rather than floating, so an action that evolves cannot quietly change your pipeline.
• The desktop app ships as an MSIX package. For Windows fleets rolled out through Microsoft Intune, Routebase now comes as an MSIX for x64 and ARM64 alongside the .exe and .msi installers. MSIX is the native format for managed deployment: Intune treats it as a line-of-business app, with no silent-install switches to work out. Both packages are signed through Microsoft Trusted Signing, so no certificate has to be pushed to your devices first. See Desktop App for the deployment steps.
• A new endpoint is testable against the mock server the moment you create it. Until now the mock answered a freshly designed endpoint with 404 No matching rule found until someone ran Generate from Spec by hand. A rule is now created with the endpoint, using the same logic — including a schema-based dynamic template when the endpoint already carries a response. Add a response schema later and the mock serves the body without a further step. Hand-written rules are untouched: the automatic rule attaches at the lowest priority, and an existing rule on the same path keeps winning.
• The API Designer opens on an overview of the specification. Opening a spec without a selected endpoint used to show one sentence on the widest surface of the app. That space now carries the shape of the specification: how many endpoints, schemas and other components it holds, how the endpoints spread across HTTP methods, what changed most recently — each of it clickable — and where it stands on summaries, validation errors and warnings. At the top sits the place you last worked, one click away, and it survives a reload. The overview appears whenever orientation helps most: a freshly opened spec, a deleted endpoint, a version or branch switch, or Escape. The way back is the heading — API Designer above the tree, and Mock Server likewise, which returns to its dashboard.

Improved

• SSO setup shows the Entity ID and the ACS URL before the connection exists. Both values used to appear only on the test step — after the connection had been created — so administrators configured their identity provider with placeholders, came back, and then went in a second time to enter the real values. That second pass is where typos come from. The metadata step now shows both with copy buttons, computed the same way the connection itself computes them.
• The light appearance takes its colours from the theme. Charts, status bars and surfaces used to draw from a stock palette that sat beside the rest of the product rather than in it, and the layers were stacked the wrong way round — a raised card could read as lower than the surface behind it. Both are corrected, and the status bars have stopped shouting.
• Run history is back in the right panel of the test runner, and the run rows hold up at any panel width.
• The settings navigation is sorted, most noticeably where no order was recognisable before, and the governance settings now mark their place in it.

Changed

• An API key without the necessary permission reports an authentication error everywhere in the CLI. run and list used to answer a 403 with the exit code for a network problem, which sent CI users looking at their firewall instead of at a missing scope. All commands now map 403 to exit code 4. Exit codes are part of the CLI contract, so this is a major version: Routebase.Cli 2.0.0. Pipelines that branch on exit codes from run or list should be checked once.

Added

• An agent can put images into your documentation. Writing a documentation page over MCP covered the words but not a single screenshot: every image had to be uploaded by hand in the editor and its address carried back. Five new tools close that — upload_doc_image for content images, and upload_branding_asset, delete_branding_asset, upload_custom_font and delete_custom_font for a portal's logo, favicon, social image, backgrounds and typefaces. The limits are the editor's own (5 MB per image, 2 MB per font, WOFF2) and the conversion to WebP still happens on our side. The file travels base64-encoded in the call rather than as a path, because the MCP server runs in the Routebase cloud and not on the machine your agent works from. The address that comes back is root-relative and belongs in the page exactly as given — an absolute blob address stops loading once a portal moves to your own domain.
• Documentation images can be listed and removed. list_doc_images names every content image of a documentation with its address, size, dimensions and whether a page still points at it; delete_doc_image removes one. An image a page or snippet still uses is refused rather than deleted, and that check covers every version of the documentation, not just the newest — a published older version keeps the images its pages were written with. Both are available over REST as well.
• Guides in a repository carry their images. sync-guides transfers Markdown and images together: write a repo-relative reference such as ![Endpoint tree](<Section 3/endpoints-tree.png>), and the sync finds the file, uploads it and rewrites the reference to its portal address. The same image keeps the same address — its name is derived from its content — so repeated runs neither duplicate anything in portal storage nor mark untouched pages as changed. A local manifest skips files that have not changed, --dry-run shows the planned uploads without writing, and --force-images transfers everything again. Addresses already pointing at the portal are left untouched, so nothing needs migrating.
• A rebase conflict shows what actually differs. Bringing a branch up to the current main state meant choosing between Take main and Keep branch for each conflict without seeing either side. Every conflict card now carries a table of the differing fields with the value on main and on the branch side by side; lists such as parameters and responses appear line by line as a +/− diff, so a parameter added on the branch is immediately visible. Above the table stands who last touched which side and when, and under the two buttons the consequence in one sentence. From the second conflict on the cards start collapsed. The choice stays deliberately per entity — merging field by field is not offered.

Improved

• Saving in the settings works the same way on every page. Save and Discard sit together at the bottom right of a card, they appear with your first edit rather than sitting greyed out, and they leave again once the change is stored — a card you have not touched shows no buttons at all. The labels are the same everywhere (Save changes, or Create … when something is being added), success is reported once and inline instead of as a toast, and a switch that saves immediately shows a small Saving… / Saved at the control rather than filling the screen with notifications. Where an entry is invalid — score weights that do not add up to 100 %, for instance — the button stays visible and greyed out, because there the grey button is the explanation.
• Unsaved work is harder to lose. A dialog no longer closes when you click beside it, and around 85 forms across the product — from New endpoint through monitors and webhooks to the organization settings — ask Discard changes? on Escape, the close button or Cancel while something is filled in. Leaving a settings page with unsaved edits, by the navigation or the back button, asks the same question. A successful save closes without asking, an untouched form closes as before, and the command palette still closes on a click beside it.
• Five consequential actions ask first. Deactivating AI Assist, Reset to Defaults in the API Designer (which also resets every keyboard shortcut — the dialog now says so), switching an SSO connection on or off, and rotating a SCIM token each carry a confirmation. Enable All / Disable All for the built-in matching rules now covers every rule of the chosen filter rather than the twenty on screen, and names the count.
• A modified schema in a merge request shows its changes. Opening a schema marked Modified in the Changes tab used to reveal an empty area: the branch comparison knew that the definition differed, not in what. It now uses the same comparison as the version diff — added, removed and changed properties line by line with type and required marker, changed enum values likewise. With an intended side effect: because the breaking-change rules read exactly this data, a branch diff now also recognises a field becoming required or an enum value disappearing, so the breaking counter of a merge request and the approval on breaking changes policy apply to schema changes too.
• Notes in sequence diagrams stay inside their box. A note spanning two participants takes its width from the distance between them, so a longer text used to run past the box on both sides. Routebase now measures the finished diagram and, where a note overflows, redraws it once with more room until the text fits. This holds across all three places a diagram appears — the app preview, the portal preview and the published portal — and diagrams that never overflowed are drawn exactly as before.
• Portal addresses are stated consistently. The canonical link, og:url, sitemap.xml, llms.txt and llms-full.txt all name a page by the same address the portal serves it under. Search engines see one page instead of two spellings of it, and an agent following llms.txt is spared the detour. This takes effect with the next portal publish, which rebuilds the portal once in full.
• The governance dashboard is organised in tabs, and the duplicate quality-score card is gone.

Added

• Images in the documentation have a display width and an alignment. A portrait screenshot no longer has to fill the whole text column: select an image in the editor and set it to 25 %, 50 %, 75 % or 100 % — and once it is narrower than the column, align it left, centre or right, centre being the default. The percentage is a ceiling on the text column rather than a zoom, so a small image is never blown up beyond its own size, the aspect ratio holds in both themes, and a page does not jump while it loads. A light/dark pair takes both settings together. Pages maintained outside the editor carry them as classes — class="docs-img docs-img--w50 docs-img--right". Without a width set, nothing changes.
• A click on an image opens it full size. Every content image on a documentation page enlarges up to its own full resolution — in the Doc Hub preview and on the published portal alike — so an annotated screenshot stays readable on a phone and a deliberately narrowed one stays readable at a desk. Escape, a click beside it or the close button bring you back; the keyboard path works the same way and returns the focus to the image it came from. Where a page carries a light/dark pair, the variant the reader is looking at is the one that opens, and an image wrapped in a link stays a link. There is nothing to switch on. Existing portals pick this up on their next build, which re-uploads every page.
• An environment shows how it got to the version it runs. Every promotion has been recorded from the first one; the Contract tab now opens that record per API. Each entry names the version, when it was promoted and — the column that carries the weight — where it came from: stated in the UI, reported by the pipeline, or deployed by Routebase. Routebase does not deploy your service, so a pin set by hand is an assertion while one reported by a deploy job is a fact, and the two should not read alike. The promotion that froze a contract and the one that was a walk back are marked as such, and Pin this again takes an earlier version through the ordinary promote dialog, warnings included. The rollback button stays where it is: one click for the common case, with the precise way beside it.

Improved

• The promote dialog offers every version, not just the draft. An environment running 1.2 while 1.4 is being designed can now state what it actually serves — the version is a choice rather than whatever sits in draft. The previous candidate stays preselected, so the one-click path is unchanged, and deprecated versions are left out. The freeze warning follows the version you pick: one that is already frozen gets a calm note instead of a warning about something that cannot happen a second time.
• Diagrams look like the portal they are published in. Mermaid diagrams render in the portal's own typeface and colours — dark mode and your organization's primary colour included — instead of the library's stock theme. Edge labels have room to breathe, nodes sit further apart, rectangular shapes carry soft corners, and the layout is measured with the real font once it has loaded, so a multi-line shape keeps every line. One configuration drives all three places a diagram appears: the published portal, the preview, and Markdown inside the app.
• Search results name the API they belong to. In a project with more than one specification, two endpoints sharing a path were told apart only by opening them. Endpoints, schemas and tags now carry project › API as their context. Results that belong to no specification — projects, test suites, mock rules and organization documents — are unchanged.

Changed

• A test suite's base URL and variables come from the environment. The suite configuration no longer carries its own Base URL and Suite Variables fields. A run resolves the base URL and the variables from the environment it is started against, and run-specific values from the data set — in the app, in scheduled runs and in the CLI alike. Suite authentication (Inherit, Custom or None) is unchanged.

Added

• The CLI runner is on nuget.org. dotnet tool install --global Routebase.Cli installs routebase — run test suites with JUnit output your CI renders as a real test report, run security scans with SARIF export and a threshold gate, promote a version after a deploy, and pull documentation as Markdown files out of the Doc Hub and write it back, with optimistic concurrency, --dry-run, and the guarantee that it never deletes anything. From 1.0.0 on, exit codes and flag names are part of the contract. US-hosted organizations set their region once with routebase config set-region us, or per pipeline with ROUTEBASE_REGION. A new CLI section in the docs covers all of it. See the CLI overview.
• SSO setup guides for Okta, Microsoft Entra ID, Google Workspace, OneLogin and Ping Identity. Each one walks the order that actually works: create the SAML application at your identity provider with placeholders, create the connection in Routebase, then carry the real Entity ID and ACS URL back. They name the exact pages — Domains, Single Sign-On, API Keys and Audit Log each have their own — and the one step people miss: a domain verified after the connection exists needs the connection saved once more before it routes. New portal section SSO Setup, linked per provider from the SSO page.
• A folder in the Doc Hub is a working surface. Clicking a folder or a section opens an overview beside the tree: its slug, a description field that saves when you leave it, the numbers that matter (pages, changes since the last publish, last edit and who made it), and its contents as a list you can reorder by handle — the same call as dragging in the tree, so both show the same order. Every page edited since the last successful portal build carries a "Changed since publish" dot, subfolders roll their pages up, and the header names the total. Create a page or subfolder, rename, change a slug or delete right from the surface. Read-only versions show the same overview without the fields and handles.
• The documentation opens on a version overview. Instead of an empty pane, the Doc Hub greets you with the state of the version you are in: whether it is live and at which address, how the last portal build went, and whether an embedded API specification has moved on since.
• PHP code samples — and a language selection that takes effect. PHP joins the generated samples, built on the cURL extension every PHP installation ships with, version header included. And the languages you pick in the documentation settings are exactly the tabs that appear, in the app and on the published portal alike. Deliberately forgiving: no selection, or one that matches nothing, still shows every language — an endpoint page without a code sample would be the worse outcome. Existing portals pick this up on their next build, which re-uploads every page.
• A test suite sets its fixture scope. All fixtures (the default), only the selected ones, or all except the selected ones, across the project's fixtures and those imported from the organization library — the latter under the name a run actually resolves them by, alias included. update_test_suite takes the scope over MCP too. The scope is per suite, not per test case, and that is deliberate: a suite loads its fixtures once for every case, so values captured with CaptureToFixtureName stay visible to later ones.
• The branch workflow has the surfaces it was missing. The Merge Requests page opens on four figures — open requests, merges in the last 30 days, the share of merges carrying breaking changes, and the average time from opening to merge — and splits into Requests and History, the merges in the order they actually landed, each with the changes recorded at its merge. A merge request's detail view carries a History tab with its review trail. Manage Branches in the branch picker opens the full branch list for the current version, closed and merged ones included, filterable by status — and the one place to close a branch. Merges from before this release carry no timestamp and are left out of all four figures rather than counted as zero; the page says so.

Improved

• Reviewers are picked from your organization. Adding reviewers to a merge request is a searchable member list with avatars and roles, not a field asking for identifiers.
• A merge request states whether the branch breaks the contract — read from the actual diff between branch and base — and the merge policy can require an administrator's approval before such a branch lands.
• A test step blocked by a read-only environment reads the same everywhere. Routebase refuses write requests against an environment marked read-only before they reach the network and reports the case as Blocked, not failed. Scenario runs now say so as plainly as suite runs do, and the summary toast at the end of a run counts Blocked and Pending as their own states rather than folding them into failures.

Changed

• Billing access rests on two permissions. billing:read — every member — carries the plan and limit information the product uses to explain why something is gated. billing:manage is owner-only and governs the billing pages and every change to a subscription.

Added

• Contract drift has a page of its own. Under Monitoring → Contract Drift, every endpoint whose live responses no longer match its contract is listed — grouped by endpoint (method, path, spec), with one row per environment naming since when it has been drifting, when it was last seen, how many of the checks are affected, the individual deviations, and the contract version they were checked against. Filter by severity, environment and time range; the sidebar carries a counter. The card on the health dashboard stays, carries the same name, and links through with View all. Agents get the same list as list_contract_drift.
• Every deviation is an event with a history. Acknowledge keeps it in the list but takes it out of the sidebar counter; Resolve closes it, with a note if you want one; both can be undone. When the endpoint matches its contract again the next check closes the event on its own and says so — "Recovered on its own" reads differently from one somebody closed by hand — and "Including resolved" brings the history back. An event is defined by the fields that deviate, not by the endpoint: when a deploy changes which field is off, that is a new event, so an acknowledged "unexpected field discountCode" cannot quietly swallow a later "required field customerEmail missing" on the same route. Agents: manage_drift_event.
• Details opens the whole picture behind a drift. A table of Field · Change · Expected · Received across all deviations, a jump straight to that endpoint with Open in API Designer, and on request the response the finding was read from — status code, duration, headers and the first 4 KB of the body. The call that produced it sits in the same place: method, the URL actually hit, and the headers sent, recorded with each check rather than read from the monitor's current configuration, so a later change does not relabel an old finding. Credentials are never written into that record in the first place: only variables not marked secret are resolved, and a header carrying a credential shows its name without its value — that it went out belongs to the diagnosis, its contents do not. A deviation also names the value that actually arrived — expected Integer, got "30", where the quotes are the finding — while a missing required field says not present rather than null. Agents: get_contract_drift.
• A monitor can watch whether a field's value still moves. Contract validation catches a field that changes its shape — suddenly null, a different type, a broken format. A field that keeps returning a perfectly valid value but has not updated in three weeks passes all of it: the contract holds and the numbers are wrong anyway. Under Field freshness on the monitor, a handful of paths ($.data.updatedAt, $.items[0].price, one per line) are read on every successful check, compared with the value last seen, and kept: "Unchanged for 47 checks · last changed Aug 9, 14:02", with the value beside it. There is deliberately no threshold and no alarm — whether a value that has not moved in 200 checks is a frozen feed or a correct constant is something only you can know, and an invented limit would pass judgement on data we cannot judge. A field standing still counts neither against availability nor opens an incident. Three states are kept strictly apart because they mean different things: a fresh path says "No check has read this path yet", the first measurement says "First value recorded", and a path absent from the last response is reported as "Not found in the last response" — a missing field is unknown, not stable. Agents: manage_monitor(action: "set_freshness_watches") and get_monitor(includeFreshnessWatches: true).
• A monitor says which contract it validates against. The monitor detail view carries a line "Validated against 2.1.0 (environment pin)", and the drift card on the health dashboard the same per event. Three states: pinned (with a frozen note where the version is frozen), no pin — a neutral statement, since nothing deployed is a normal condition — and a stale pin, where the pin sits behind the published version: that monitor keeps validating the old contract, and drift against the current one goes unnoticed. Only that third case warns, and it offers "Re-pin … to 2.1.0" on the spot. The version used is recorded at check time, so a re-pin does not relabel history. The "Watch for drift" dialog names the baseline before you switch it on.

Improved

• Publishing a version takes 37–50 % less time, and the gap grows with the size of the spec. Two pieces of work nobody was waiting for — the diff against the previous version behind the breaking-change notification, and the recalculation of the governance score — now run in a background job, as documentation, mock, test and monitor synchronisation have done for a while. Measured on a spec with 600 endpoints: 21.8 s → 13.1 s; at 50 endpoints, 4.8 s → 2.4 s. Nothing changes about what happens: the breaking-change notification still goes out, the governance score is still recalculated after every publish — opening the governance dashboard in the same second shows the previous figure for a few seconds.
• A failed check says what kind of failure it was. Every failure now carries a structured reason, shown as a badge in the check list: Auth failure (401/403, or the environment auth failing to resolve at all), Timeout, Connection error, Schema drift (the response arrived as expected and its body failed strict contract validation), and Waiting for deployment. An ordinary status-code failure deliberately keeps just its status code beside it — "500" and "Status mismatch" say the same thing twice. An expired token no longer reads like a dead endpoint. The numbers are unaffected: these failures count against availability, the error-rate window and the sparkline exactly as before.

Added

• Enum values can carry a readable label and a description. An integer enum — 1, 2, 3 — says nothing on its own. Each value now takes a display label ("Mr", "Mrs") and, optionally, a description, entered right in the schema editor: a new "Show labels and descriptions" toggle turns the chip list into a grid with Value, Label and Description columns, on the schema itself and on any property. They travel by the common convention — labels as x-enumNames, descriptions as x-enumDescriptions — so an imported spec that already carries them shows its labels immediately, and both survive publish, export and the portal build. The docs reader and the published portal render every enum value as a badge with its label and description, parameters included, and the Markdown export carries the labels into "Possible values".
• Response and request body components define their schema in the editor. A newly created component offers Add Property to build a schema inline and Link Schema to point at an existing one — from the empty state and from the schema card's header, where a linked component shows Unlink instead. A schema can also be dragged onto the card straight from the sidebar. Unlinking keeps the content: a previous inline schema comes back, and where there was none, a copy of the linked schema stays behind.
• The schema table's columns can be resized. Name, Type and Example have handles on the column edge, and a double-click restores the default. The widths apply across every schema table — response body, request body, component and shared-schema editors — and survive a reload.

Improved

• An object[] property is filled in like any object. Item properties are ordinary child rows: add, rename, retype, move, delete, or drag another property in to nest it — in every property table and at any depth. A property that switches between object and object[] takes its children along. Items that reference another schema (Category[]) stay read-only by design; those fields belong to that schema and are edited there. A schema whose own type is Array with Inline Object items behaves the same way, and a schema dropped from the sidebar onto the Items block becomes the list's item type (Category[]).
• Following a $ref leaves a way back. Clicking the link icon beside a type like Category[] opens that schema, and the editor now carries a "← Back to GET /categories" chip at the top — it stays while you scroll and disappears once you navigate elsewhere. Reference icons work in the schema editor's own property table too, so a jump from one schema to the next is remembered the same way.