Changelog

v0.3.0

• **The Callbacks list groups by service and can be searched.** With callbacks from more than one mock service, each service is a section with its count and how many are waiting or failed; with more than three services the sections start folded (Fold all / Open all), and a search by name, address, service, scenario or result opens every section that has a match.
• **A callback that saved something links to it:** its detail and the request's Traffic detail have "Open <collection>" next to what it saved.
• **A callback can save its answer into state.** In a callback's Settings, "Save its answer into state" keeps something from the answer when it comes: add or replace a record, always add one, or change fields of one, in any collection. The record's id and fields can use {{callback.status}}, {{callback.ok}}, {{callback.body.…}} (JSON, else text) and {{callback.headers.…}}, and what the request said when it came in ({{request.…}}, {{response.…}}, {{scenario}}), so a result that arrives later (a provider confirming a payment) is there for rules and responses to read. It is saved once the callback is finished and only if an answer came back; the callback's detail says what was saved, or why not.
• **A request's Traffic detail lists the callbacks it triggered,** right under its heading (where each stands, its answer, the certificate it used, what it saved into state, and why one failed), instead of behind a tab.
• **One look for every error.** The panel the mock service shows when its port is in use (an icon, what happened, what to try, and the exact message with a Copy button) is now how Zyvra shows errors everywhere: a page that could not load, a dialog that could not save or import, a spec that could not be read, a test that could not run, a failed script, a callback or update that did not go through, and what to fix before saving an endpoint. Errors that Zyvra can explain say so in their own words (a missing item, a conflict, the secret store, the project's data folder), and a list of things the server found wrong is shown as a list. The Overview's "needs attention" notes use it too (a service that cannot start says why and what to try; a file with several errors lists them), in red, amber or grey by how serious it is.
• **Mock Services shows the error panel for a service that cannot start,** above the table, with Change port and Try again right there (one per failing service, named). The table row only says Error; the one-line reason under it is gone.
• **No per-field errors.** The endpoint editor no longer outlines fields or writes a message under each one: after you try to save, the summary at the top lists what to fix (each line takes you to its tab), and a tab with something to fix shows a count.
• **A trigger copes with a hundred scenarios or rules.** Up to eight choices are chips you switch on and off; with more, the ones you chose are chips you can remove, and a **Choose scenario** button opens a list you search (with how many match). Rules work the same way.
• **Mistakes are shown where they are.** After you try to save, the endpoint editor marks the field that is wrong (a condition with no name, a callback with no address), says what is needed right under it, puts a red count on each tab that has something to fix, and replaces the red list at the top with a summary whose lines take you to the right tab. It stays in step as you type, so a mistake disappears the moment it is fixed. Nothing is red before you have tried to save.
• **Callbacks: define them in one place, and say when they are sent.** Every endpoint has a **Callbacks** tab. Each callback there has a **Send when**: every time the endpoint answers, or only when the response status is one you list (2xx, 404), the answer is a scenario you tick, and the request has something (a header, a query value, a field in the body: the same conditions as a rule). A callback with no trigger chosen, or one that points at a scenario that was deleted, shows a warning (and the tab shows one too), because it would never be sent. A trigger can also be **the rule that answered** (it matched, or it did not and its "otherwise" answered), which is what a rule's "Also call" used to be.
• **Rules and scenarios no longer carry callbacks.** The "Also call" section of a rule is gone, and a scenario's callbacks are not edited on the response page: callbacks are defined on the endpoint's Callbacks tab, one place. Callbacks that a rule or scenario already has (in zyvra.yaml, or from an older version) are handed over when the endpoint is opened, with that rule or scenario as the trigger, so they are sent in the same cases; a note says so, and saving writes them in their new place. Renaming a rule or scenario keeps the callbacks that follow it. Projects you have not opened keep working unchanged.
• **A callback can carry more.** Query parameters (a table, encoded for you), a body as JSON, form fields, text or none, authentication (a bearer token, basic, an API key in a header or the query, or an HMAC signature of the body you choose the header, algorithm and prefix of), a timeout (1 to 60 seconds) and a switch to skip checking the target's certificate. Values can now read the answer too: {{response.status}}, {{response.body.id}}, {{response.headers.x}}, {{scenario}}, and {{env.name}} for a variable of the local environment, so a secret does not have to be written into the project file. The editor groups them in tabs (Params, Headers, Auth, Body, Settings) so a callback stays short.
• **The Callbacks list shows the certificate used,** and pages at 25 rows. A callback's stored credentials (Authorization, API keys, signatures) are not shown back in its detail.
• **Drag and drop in the API Client's collection tree.** Drop a request on another to reorder it, a folder on another folder, either one onto a folder to move it in, or onto the collection to bring it back to the top. A line shows where it will land. Move to… and Move up/down stay for the keyboard.
• **Five smaller things.**

- *Start counting again:* the Faults tab has a button that makes "every 3rd", "the first 3", rate limits and what custom fault scripts remembered start from zero on the running mock, without restarting it.

- *Examples for API Client scripts:* pre-request and test scripts have a "Start from an example" menu (a timestamp or request id header, an HMAC signature, a short-lived JWT; status, speed, JSON shape, saving an id). Every example is run in the real sandbox by the tests.

- *Move and reorder:* requests and folders can be moved into another folder (Move to…, in the sidebar, the requests table and the folders column) and up or down among their own kind. The control API's move takes an optional `index`.

- *Re-import an OpenAPI spec:* when a route already exists you can now add the responses it is missing instead of skipping it. Rules, faults, edited responses and the active scenario are kept; routes the spec dropped are listed, never deleted.

- *Certificates for callbacks:* https callbacks present the client certificate declared for their host (the same ones as the API Client) and trust its CA file. The callback's detail names the certificate that was presented. A certificate that cannot be loaded fails the callback with the reason instead of sending without it.

• **Scenarios, Traffic and History stay bounded.** Scenarios shows a foldable section per service (they start folded once there are more than 30 endpoints, with Fold all / Open all, and searching opens everything that matches). Traffic and History page at 25 rows, and Traffic gains an outcome filter (any, errors, no route matched) plus a count with a one-click "N failed" link.
• **A collection's page has folders on the left and requests on the right.** Run history moves above both, as a closable section: one line that says how the collection is doing (the last runs as a strip, and what the latest one found) and, when opened, the full list (up to 20 runs, scrolling on its own). It starts closed and stays as you leave it. Folders are a column of their own: **All requests** first, then each folder with how many requests it holds, nested folders that fold (a big tree starts folded), a search box once there are more than a few, and a "⋯" menu on each for its settings, rename and delete. Click a folder to see only its requests; a chip above the table says so and clears it. However many folders there are, the column keeps its own height and scrolls, so the rest of the page stays in reach. The requests table shows 25 at a time with Previous and Next (a search looks through every page), and shows its Auth and Checks columns when it has room for them.
• **Four screens that explain themselves.**

- **Rules tab:** each rule folds to one line ("no token · if header authorization absent → denied 401"), a list of more than three starts folded (with Open all and Fold all), the status of the scenario a rule answers with is shown beside its name, and "Also call" is one quiet line until a rule has a callback.

- **Mock service Settings:** it is now a real settings page. The details with an Edit button, a switch for starting with the project that says what each position does, the base address and a curl command to try, a summary of what the service holds with a click through to each tab, and delete in a marked place that says what goes.

- **Endpoint Test tab:** it says what it does (nothing is sent or changed, unsaved edits count), shows the method with the path, groups the request and the result in panels, and copies the sample request as a curl command.

- **State records:** a table with the fields as columns (the id first, then the fields most records have, timestamps last), numbers and true/false looking different, nested values summarised instead of cut off, a filter, and the collection's facts as small badges.

v0.2.15

• **The endpoint's General tab does more.** The path explains itself as you type: the changing parts are listed with how to read them ({{request.path.id}}), a path that cannot work (no leading /, spaces, a stray {) is explained at once, and an endpoint that would answer the same requests as another one of the service is flagged. Beside the form, **How to call it** shows the address and a curl command (each changing part set to 1) with copy buttons, and **What it holds** sums up the responses, rules and faults with a click through to each tab. Switching an endpoint off now says what happens: requests get a 404 and nothing is lost.
• **Suggestions and hover help in the API Client's scripts too.** The pre-request and test script editors (on a request, and in a folder's or collection's settings) now suggest what each can use as you type: request. (changeable before sending, or what was sent), vars., response., expect(…)., pm.… for scripts imported from Postman, and the helpers; hovering a name shows what it does. Suggestions and hover tips are no longer clipped by the editor's frame.
• **A tidier request bar in the API Client.** There is one **Save** button now (it updates a saved request, or asks where to put a new one), and a **⋯ More actions** menu next to it holds Generate code, Import from cURL, and Save as a copy (for a saved request). Cookies and Certificates stay beside the tabs.
• **Scripted responses are easier to find and to write.** The "Response from" dropdown explains both choices (a fixed response, or JavaScript). The script editor suggests what a script can use as you type (request., state., jwt., fault.…) and shows what a name does when you hover it, and "Start from an example" offers eight working scripts. A fixed response has a **Convert to a script** button that writes the script giving the same answer (templates such as {{request.path.id}} become code). The same suggestions work in custom fault scripts.

v0.2.14

• **Custom faults: write your own.** Add a fault, choose **Custom (a script)**, and a short JavaScript decides for each request what happens: wait (fault.delay), answer with an error (fault.fail), drop the connection, hang, break the body, cut it short, or slow it down. fault.count says how many requests it has seen and fault.memory is kept between requests, so a script can write an outage that comes and goes, a quota per API key, or a slowdown that grows. Seven examples to start from, and the script can live in a project file. Like other scripts it needs the project to be trusted, and a script that fails answers 500 with the reason instead of being ignored.
• **More chaos options on mock endpoints.** New faults: **No answer** (accept the request and never answer, so a client's timeout is tested), **Broken response** (the right status with a body that cannot be parsed: invalid JSON, empty, or an HTML error page) and **Rate limit** (429 with Retry-After once there are too many requests per window, with X-RateLimit-* headers, optionally counted per API key). Any fault can now apply to particular requests by count (every 3rd, the first 3, everything after the first 5), so retry and circuit-breaker tests behave the same every time. The Faults tab has an **Add a fault** menu, with ready-made situations: Slow 3G, Flaky mobile connection, Fails 3 times then works, Goes down after 5 requests.
• **The HTTP QUERY method.** QUERY (a GET that carries a request body, for searches too big or too structured for a URL) can be chosen in the API Client and in the mock endpoint editor, is answered by mock endpoints (rules and templates can read its body like any other), is imported from OpenAPI 3.2 specs, and becomes an endpoint when a mock is made from a collection. It has its own colour, a light green, in the method lists and badges.
• **Method colours.** Each HTTP method has its own colour everywhere it is shown (GET green, POST gold, PUT blue, PATCH purple, DELETE red, HEAD teal, OPTIONS magenta), and the method dropdown lists each one as a coloured chip with what it is for.
• The API Client's "New collection" button is black, like the other main buttons.
• **The auth type dropdown explains each choice.** Every type has an icon and a line on what it does ("A token in the Authorization header", "A token signed for every request"…), and the chosen one shows its icon. The Auth tab is now two columns: the type on the left, the fields it needs on the right (stacked when the space is narrow).
• **Import a browser recording (HAR).** On the Collections page or in the API Client, Import → Browser recording (HAR). The API Client's Import… button is now the same menu as the Collections page (OpenAPI spec, Postman file, Browser recording), where it used to open only the Postman dialog. Save the Network tab as a HAR file, choose it, and pick the calls to import: API calls are selected for you, pages and files are one click away, and repeated calls count as one. Each becomes a request with its parameters, headers and body; the server becomes a {{baseUrl}} variable. Cookies are left out, and tokens, passwords and API keys become secret variables whose values go to the Vault, never a file. The responses can be kept too, so the result has a button to make a mock service from it that answers the way the real API did.

v0.2.13

• **Questions before deleting are now a proper dialog.** The browser's "127.0.0.1:7777 says" pop-up is gone everywhere (deleting endpoints, services, collections, records, certificates, clearing history and traffic, discarding unsaved tabs, and so on). The new dialog says what will be deleted and what will not, the button says what it does ("Delete endpoint", "Clear"), and Cancel is focused first, so Enter does not delete by accident.
• **A clear message when Zyvra stops responding.** If the dashboard loses its connection to Zyvra (it was stopped, or the computer slept), a dialog now covers the page instead of red "Failed to fetch" errors: it says what happened, shows the command to start Zyvra again (zyvra up) with a Copy button, and counts how long it has been waiting. The page cannot be used until Zyvra answers, and the dialog closes by itself when it does. A restart you asked for from the dashboard does not trigger it.

v0.2.12

• **Failed requests are easier to read.** Instead of one red line, the API Client now shows what went wrong in plain words (for example "Couldn't connect to localhost:23123"), a short list of what to try, and the exact error message with a Copy button.
• **A mock service that cannot start explains why.** "Port 8081 is already in use" (or "No permission to use port 80") replaces the raw system message, with what to try, Change port and Try again buttons, and the exact message with Copy. The services list shows the same thing as one short line.
• Fixed: on some pages (a mock service with an error, or made from a collection) the content ran past the right edge of the window and got cut off.

v0.2.11

• **A request and its mock are connected.** A service made from a collection remembers it. In the API Client, a request of that collection shows "Mocked by <service> · GET /path" with a link to the endpoint, and Save as mock starts on that service and endpoint (it says why), so a new response is added as a scenario of the mock that already exists. The service's page says which collection it came from.
• **Create a mock service from an API Client collection.** In Create service, choose "An API Client collection" (and optionally one folder): every request becomes an endpoint, answering the way the collection expects. A preview shows the endpoints and scenarios before anything is created. Answers come from a real response you already received for that request, else from its checks (expected status, expected JSON values, or the JSON schema from an OpenAPI import). Requests to the same endpoint become scenarios, and numbers, UUIDs and hex ids in paths can become {id}.
• **Save as mock**: in the API Client, a response can be kept as a scenario of a mock endpoint with one click (the Save as mock button next to Copy and Save). It starts from the mock that answered or the one on that port, offers {id} for paths with ids, names the scenario after its status, and adds to an existing endpoint without changing what it answers unless you ask. Cookies, credentials and per-request headers are left out, JSON is stored as data, and text that looks like a template is stored safely.

v0.2.10

• An update is now offered in the top right corner of every page: **Update available** when a new version is out, and **Restart to update** once it is installed. Both ask for confirmation first (the dialog shows the release notes), and installing leads straight to a second question before Zyvra restarts.
• **Restart now**: Zyvra restarts itself from the dashboard. It shuts down cleanly, starts the new version in the same terminal, and the page reloads by itself. The terminal command is still shown as a fallback.

v0.2.9

• The page tabs have icons, like the Collections page: API Client, Mock Services, a service (Endpoints, Scenarios, State, Settings), the endpoint editor (General, Responses, Rules, Faults, Test), Traffic and State.

v0.2.8

• Collections and folders now list their folders first, then their requests. Runs still go through requests in the order they were created.
• API Client: on a wide window, scrolling the Collections or History list no longer scrolls the whole page. The list scrolls on its own, with its buttons and tabs staying in place, and the request area scrolls separately.
• Start all and Stop all moved from the Overview to Mock Services, where they act on the services you are looking at.
• Fixed: after Stop all, starting a single mock service did nothing. It now starts that service, and says why if it cannot.

v0.2.7

• When the release server is busy, the update check and the install scripts now fall back to the Zyvra website, which serves the same signed files.

v0.2.6

This includes everything planned for v0.2.5, which was never published.

• Settings is a real page now, with an Updates card: see whether a new version is out, read its notes, and install it with one button. The sidebar shows "Update available" or "Restart to use vX" and leads there.
• Optional automatic updates: switch on "Install updates automatically" and a new release is installed as soon as it is found, after the same signature and checksum checks. Off by default.
• "Check for updates" works even when the daily check is switched off.

v0.2.4

• New projects are suggested in a hidden folder, ~/.Zyvra. Projects you already have stay where they are.
• The dashboard has a new tab icon, the same cube as the website.
• The project list is no longer fetched every few seconds. It refreshes when the dashboard loads, when you return to the tab, when you open the project switcher, and when a service starts or stops.
• When the release server is busy or unreachable, the update check says so in plain words, waits as long as the server asks, and tells you when it will try again.

v0.2.3

• A redesigned Get started screen for an empty project: two ways to start (mock an API, test an API), a progress checklist that follows what you actually do, and terminal shortcuts.
• "Create service" opens the create dialog directly.

v0.2.2

First release published through the new release pipeline.

• zyvra update installs the newest release after checking its signature and checksum; zyvra version --check only looks.
• The dashboard shows the version, announces new releases with their notes, and has a switch for the daily check.
• zyvra verify <file> checks a downloaded file against Zyvra's release signature.
• Installers for macOS, Linux (install.sh) and Windows (install.ps1).