Traffic Parrot 5.61.0 released, what's new?

We have just released version 5.61.0. Here is a list of the changes that came with the release:

Features

• Added the ability to import an AsyncAPI specification to create messaging mappings automatically — the messaging counterpart of importing an OpenAPI specification for HTTP. Go to JMS or IBM® MQ in the top navigation bar and click Import AsyncAPI, then upload a JSON or YAML AsyncAPI 2.x or 3.0 document. Traffic Parrot parses the document's channels and operations and shows a preview of one mapping per importable operation (destination, queue/topic type, operation id, the example payload generated from the message schema, and a duplicate-status badge); you select exactly which operations to import with per-row checkboxes and an Import Selected count. A malformed, unsupported, or empty document reports a clear error and creates nothing. Each selected operation becomes a mapping — a JMS mapping from the JMS page or a native IBM® MQ mapping from the IBM® MQ page — that serves the generated example payload, ready to refine in the editor. Both AsyncAPI 2.x and AsyncAPI 3.0 documents are supported with the JMS and IBM® MQ channel bindings; for a 3.0 document the destination is taken from the channel's address (falling back to the channel name). Both one-way send/receive operations and request-reply operations (those carrying an AsyncAPI 3.0 reply object) are imported: a request-reply operation receives the request on the operation's own channel and publishes the reply message's example on the reply channel's destination, shown in a Reply destination column in the preview. Other bindings (AMQP, Kafka, MQTT) and AsyncAPI 4.x are not yet supported, and advanced JSON Schema draft 2020-12 constructs that cannot yet be turned into an example render a placeholder payload.
• The headless trafficparrot validate command now also checks your messaging mappings against your imported AsyncAPI specifications, so a partially-mocked messaging API cannot silently drift from its contract — the messaging counterpart of the OpenAPI (HTTP) and proto (gRPC) coverage checks. It enumerates the operations declared in the AsyncAPI specifications under <files-root>/asyncapi/ and reports any declared operation that has no backing JMS, native IBM® MQ or file-message mapping, for example No mapping covers AsyncAPI operation: QUEUE:orders. Operations are matched to mappings by destination identity (TYPE:name, where TYPE is QUEUE or TOPIC); for a request-reply operation coverage is measured on the inbound (request) destination only. Messaging drift participates in the same report and the same exit codes as the HTTP and gRPC checks (drift fails the build with exit code 1). Destinations you deliberately leave unmocked can be excluded with a messaging-coverage.properties file (key exclude.destinations) in the files-root, and a stale allowlist entry for a destination not present in any AsyncAPI specification is itself reported as drift. See Messaging coverage check on the JMS page.
• The add/edit messaging-mapping editor now has a skeletons dropdown that pre-fills a messaging mapping form from an operation in an imported AsyncAPI specification — the messaging counterpart of the HTTP and gRPC skeletons dropdowns. Place AsyncAPI specifications (JSON or YAML, 2.x or 3.0) into the install's asyncapi/ directory (or use the import button beside the dropdown to upload one), then pick an operation: the form's destination name, destination type (Queue/Topic radio) and request body/payload pre-fill. For a request-reply operation the option is labelled <operationId> (request-reply) and pre-fills both the request side and the reply side (a cloned response row); a one-way operation pre-fills the request side only. The dropdown appears in both the JMS and native IBM® MQ messaging editors. See Messaging skeletons on the JMS page and on the IBM® MQ page.
• Added the ability to import an async-message Pact contract as JMS or native IBM® MQ messaging stubs — the messaging counterpart of importing a Pact contract's HTTP interactions. Go to JMS or IBM® MQ in the top navigation bar and click Import message Pact, then upload a Pact .json file. Both contract shapes are detected automatically: a specification v3 contract's top-level messages[] array and a v4 contract's Asynchronous/Messages interactions[] (whose example body is read from the contents.content envelope). An HTTP-only contract is rejected with a message pointing you to the HTTP Pact import. Traffic Parrot shows a preview of one mapping per message interaction (destination, queue/topic type, the message description as the operation id, the example contents payload, and a duplicate-status badge); you select exactly which messages to import with per-row checkboxes and an Import Selected count. A file that is not valid JSON or has no message interactions reports a clear error and creates nothing. Each selected message becomes a one-way publish mapping — a JMS mapping or a native IBM® MQ mapping — that publishes the example payload on receipt of any message on its destination; Pact message interactions are fire-and-forget, so these are not request-reply stubs. Because a Pact message carries no destination, it is derived from the message's metadata (a destination, queue or topic key, where a topic key makes it a TOPIC) or, failing that, from the message's description; a description-derived destination raises a warning in the preview so you review it before importing. Import message Pact is licence-gated, available on a JMS or IBM® MQ licence respectively (the menu link does not appear without it). See Import a message Pact contract on the JMS page and on the IBM® MQ page.
• You can now import a Pact contract (consumer-driven contract, specification v2, v3 and v4) as HTTP stubs. Upload the Pact .json file on the HTTP Import page exactly as you would any other format — Traffic Parrot detects it automatically (no format to choose) and turns each HTTP interaction into a stub mapping through the same preview, filter and select flow used for HAR and OpenAPI/Swagger. The request (method, path, query, headers, body) becomes the request matchers and the response (status, headers, body) becomes the stubbed response; JSON request bodies are matched tolerantly. For v4 contracts the Synchronous/HTTP interactions are imported (their bodies are read from the v4 body.content / body.contentType envelope); everything else is imported the same way as for v2 and v3. Pact matchingRules are honoured where they map onto Traffic Parrot's request matchers (request header and path regex, default JSON-body type matching); other rules fall back to an exact match and the import reports a warning listing them. This HTTP import handles HTTP interactions only — Pact message (asynchronous) interactions, including the Asynchronous/Messages interactions of a v4 contract, are imported separately as JMS or IBM® MQ messaging stubs (when a v4 contract mixes the two, the HTTP import brings in the HTTP interactions and skips the message ones with a warning). Response templating and provider verification / Pact Broker pull are not yet supported. See Importing Pact contracts.
• Added the ability to export HTTP mappings as an OpenAPI 3.0 specification — the inverse of importing an OpenAPI specification. The active scenario's mappings are translated into OpenAPI paths and operations (grouping by path and method, normalising exact, templated and regular-expression URL matchers into OpenAPI paths, lifting query and header matchers into parameters, and emitting each response body as a literal example together with an inferred JSON schema for JSON bodies) and served off the existing export endpoint via a new ?format=openapi query parameter (GET /http/management/exportMappings?format=openapi), returning a YAML document (Content-Type: application/yaml) as openapi-<timestamp>.yaml; without the parameter the endpoint still returns the native WireMock ZIP unchanged. The same document can also be exported as JSON with ?format=openapi-json (Content-Type: application/json, downloaded as openapi-<timestamp>.json) — only the serialisation differs. The OpenAPI export can be triggered from the GUI with the Export as OpenAPI (YAML) button on the HTTP Export page (alongside the existing Download Mappings button) as well as programmatically through the endpoint. Matchers with no clean OpenAPI representation (regex/JSONPath/XPath body matchers, proxy responses) are never silently dropped — every mapping's disposition (REPRESENTED, APPROXIMATED or OMITTED) is recorded in a coverage report surfaced both as a root-level x-trafficparrot-export-coverage extension and as a one-line summary in info.description. For each JSON response body Traffic Parrot also infers a JSON schema and emits it alongside the example, so generated clients, SDK codegen and documentation portals get real models rather than just a sample value; inference is conservative and based on the single example body (structure followed recursively, integral numbers become integer and non-integral number, JSON null becomes nullable, observed keys become properties but none is marked required, and no enum is inferred). A non-JSON response body (XML, plain text, empty) gets no schema — the example is still emitted and the mapping is recorded in the coverage report with reason no-schema-inferred. This release is single-scenario and OpenAPI 3.0 (not 3.1), with no multi-example merge or security schemes yet.
• Added the ability to export recorded HTTP traffic as a HAR 1.2 file, ready to drive a load or resilience test through your own engine. Unlike the native ZIP and OpenAPI exports, which export the deduplicated mappings, the HAR export is taken from the live request journal — the ordered, timed stream of inbound requests served during the current session — so the request order and per-request timing a load profile needs are preserved. Each request becomes one HAR log.entries entry carrying the method, URL, headers, query string and request body, the response status, headers and body, and startedDateTime / time. Click the new Download recorded traffic (HAR) button on the HTTP Export page (alongside Download Mappings and Export as OpenAPI (YAML)), or trigger it programmatically off the existing export endpoint with the ?format=har query parameter (GET /http/management/exportMappings?format=har), which returns a HAR 1.2 document (Content-Type: application/json) downloaded as recorded-traffic-<timestamp>.har; without the parameter the endpoint still returns the native WireMock ZIP unchanged. The exported HAR can be fed into the common HAR-to-load-test converters such as the Gatling HAR Converter or Grafana har-to-k6 (Traffic Parrot does not run the load itself — you supply the engine). The export reads the in-memory request journal, so only the most recent requests retained by trafficparrot.virtualservice.maxRequestJournalEntries (default 1000) are exported; if the journal is disabled (=0) the export is a valid but empty HAR. This first release exports text bodies for HTTP traffic only.
• HAR import now offers explicit conflict resolution for duplicate entries. When a preview entry matches an existing stub with the same HTTP method and exact URL, an On duplicate dropdown on that row — and a single For duplicates: control that applies to every duplicate at once — lets you Skip it (the default, so imports you do not touch are unchanged), Overwrite the existing stub (all stubs matching that method and URL are removed before the imported one is added, so no duplicate is left behind), or Import as new (the existing stub is kept and the imported one is added under a disambiguated name such as <name> (copy)). A per-row choice overrides the bulk default. Re-importing the same file still replaces the mappings it created last time, so those entries show as New; the actions apply to a clash against a stub from a different import or one created by hand. The same choice is available on the REST import endpoint (POST /http/management/importSelectedEntries) through an optional conflict-strategy parameter (skip | overwrite | importAsNew, default skip) with per-entry conflictStrategies overrides; omitting the parameter keeps the previous behaviour. Duplicate detection is an exact method-and-URL match, so an existing stub that matches its URL by pattern or regular expression is not detected as a duplicate. See Preview and filter before importing.
• The HTTP and gRPC mappings list now shows the bodyFileName path for a mapping whose response body is served from a binary file (an image, PDF or other non-text file), truncated to fit the column with the full path on hover, instead of an unreadable placeholder — so you can tell at a glance which mapping serves which file. Inline, recorded, and text file-backed responses show their body content in the Response body / Response message column as before. See File-backed responses in the mappings list.
• In the HTTP and gRPC mappings list, hovering a row whose response body is an image file (PNG, JPEG, GIF, WebP, BMP, ICO, APNG or AVIF) now pops a small rendered preview of the image instead of the file-path tooltip, so you can recognise the picture a mapping serves without opening the editor. The cell still shows the truncated bodyFileName path; the preview only changes what the hover shows, is loaded on first hover and capped to a thumbnail, and falls back to the plain path tooltip if the image cannot be read. Non-image binary rows keep the full-path tooltip. See File-backed responses in the mappings list.
• The HTTP mappings list now shows a composite request body matcher — one built from the logical and, or or not operators — as a readable one-line summary in the Request body column, for example and (contains 'A', contains 'B') or not (equalTo 'X'), instead of the raw matcher JSON. The row's request-match hover tooltip (which already summarised the method, URL matcher, URL and query parameters) now also lists each request body matcher on its own Body: line. Simple (leaf) matchers such as equalTo and contains are shown exactly as before; this changes only how existing matchers are displayed — nothing about how requests are matched or how mappings are saved changes.
• The HTTP Add/Edit mapping panel now shows a live, non-blocking warning beneath the URL match mode when you combine a full-URL match mode (equal to or matches regex) with one or more query parameter matchers — a combination that is almost always wrong, because those modes match the whole URL (including the query string) and conflict with the separate query parameter matchers. The warning explains the problem and recommends switching to a path-only mode (path equal to or path matches regex), and it appears and disappears as you change the URL mode or add and remove query parameter rows. Saving is not blocked.
• The HTTP and gRPC Add/Edit mapping forms now show a Manage files link in the response body area that opens the Static Files browser in a new browser tab, so you can manage the files a response is served from without leaving — or losing — the mapping you are editing. The link is always shown, whether the response is inline or already file-backed. Previously the Static Files browser was reachable only from the HTTP menu.
• The HTTP and gRPC Add/Edit mapping forms now show an inline preview of an image response body file (PNG, JPEG, GIF, SVG, WebP, BMP, ICO, APNG or AVIF) above the Response from file note, so you can see at a glance which image a mapping serves without opening the file. The body field stays read-only for binary files as before, and non-image binary files keep the read-only field with no preview. This mirrors the inline image rendering already used in the Static Files browser preview pane. See Editing a file-backed response in the UI.
• On the HTTP and gRPC Add/Edit mapping forms, clicking Switch to file now shows a Choose an existing file… dropdown beside the response body file name field, listing the files already in the scenario's __files directory (including nested responses/ files). Selecting one fills the file name so you can point a response at an existing body file without typing the path; typing the name by hand still works as before. See Editing a file-backed response in the UI.
• The HTTP Mapping cleanup results now include a collapsible Per-endpoint detail view showing, per recorded endpoint, exactly what cleanup did to it (kept, consolidated, headers stripped, body match removed, URL pattern applied, response template added, or removed), plus a consolidation-groups breakdown of which recorded URLs collapsed into each surviving pattern. The /api/http/cleanup/execute response gains matching endpointDispositions and consolidationGroups fields.
• The HTTP Add/Edit mapping editor's request body matcher dropdown now offers matches JSON schema, which was previously only usable by editing the mapping JSON directly — it matches when the request body is JSON that validates against the given JSON Schema. Enter the schema as the matcher value; it round-trips on save. The advanced JSON-only option (the JSON Schema schemaVersion dialect selector) remains available by editing the mapping JSON — see the JSON-only matchers reference.
• The HTTP Add/Edit mapping editor's Request URL matcher dropdown now offers path template as a fifth URL match type, alongside equal to, matches regex, path equal to and path matches regex. Enter a URL path template with named variables such as /orders/{orderId}; a request path matches when it fits the template's shape regardless of the concrete variable values (so /orders/{orderId} matches /orders/123). It persists as the urlPathTemplate request field and round-trips on save. The matcher also appears in the editor's Available helpers panel under URL match types.
• The HTTP Add/Edit mapping editor now also matches request headers with per-header rows — each with a header name, a matcher dropdown (equal to, contains, matches regex, does not match regex, equal to date/time, before date/time and after date/time) and a value — using the same click-to-add-rows editing already offered for query parameters. The free-text request-headers field is kept for bulk, copy-paste-friendly editing, and the rows and text area stay in two-way sync (most recent edit wins). Click Add request header to add a row and the trash button to remove one. The saved mapping JSON is unchanged (standard WireMock request headers), so existing mappings load back into both views and round-trip on save, and no header-matching expressiveness is lost.
• The HTTP Add/Edit mapping editor now also lets you set the stub's response headers with per-header rows — each with a header Name and a Value — using the same click-to-add-rows editing already offered for request headers and query parameters. Response headers are static Name: value pairs the mock returns rather than request matchers, so a row has just a name and a value (no matcher dropdown). The free-text response-headers field is kept for bulk, copy-paste-friendly editing, and the rows and text area stay in two-way sync (most recent edit wins). Click Add response header to add a row and the trash button to remove one. The saved mapping JSON is unchanged (standard WireMock response headers), so existing mappings load back into both views and round-trip on save. The gRPC and messaging editors are unchanged.
• A file-backed request body matcher (one whose value is read from a bodyFileName file in __files) is now editable in the HTTP Add/Edit mapping editor, like a file-backed response: a Content from file note names the file, the request body field is pre-filled with its contents, and saving writes your edit back to the file (the matcher keeps its bodyFileName reference). A single file-backed text matcher also offers a Switch to inline button (mirroring the file-backed response control) that detaches the bodyFileName reference and keeps the loaded contents as an inline matcher value; on save the matcher is stored inline, with no __files reference and the file on disk left untouched. A binaryEqualTo matcher, or a mapping with more than one request body matcher, stays read-only, offers no Switch to inline, and is edited on disk. See Request body file: In the GUI.
• The Available helpers panel is now also available on the gRPC mapping editor (gRPC » Add/Edit), as it already is on the HTTP and messaging editors. Expand the collapsible Available helpers card to browse, filter and copy the response-templating helpers and the request-body matchers that apply to a gRPC mapping, without leaving the editor.
• HAR import now offers an opt-in Preserve full fidelity (all headers) mode. By default an imported stub stays flexible — it matches on method, URL and the request Content-Type, and its response carries only the status, body and Content-Type, with all other request and response headers dropped so the stub is not tied to the exact browser, session or environment that produced the recording. Tick the new Preserve full fidelity (all headers) checkbox next to Import Selected on the HAR import preview (off by default; a whole-import setting, not per-entry) to instead turn every recorded request header — including Content-Type — into an exact request matcher and emit every recorded response header (with the exact response Content-Type and charset) on the stub response. This produces a faithful reproduction of the recorded exchange but makes stubs strict and often single-use: headers such as Host, Cookie, Authorization and Content-Length tie the stub to a specific host, session, token or body, so leave it off for reusable stubs. HTTP/2 pseudo-headers (:method, :authority, :scheme, :path, :status) are automatically excluded. The same behaviour is available programmatically through an optional preserveAllHeaders parameter on the /http/management/importMappings and /http/management/importSelectedEntries REST endpoints. Request and response bodies import unchanged (base64-encoded bodies are decoded automatically), and the option affects HAR import only — OpenAPI, Swagger, RAML, Pact and WireMock ZIP imports are unaffected. See Preserve full fidelity (all headers).
• Added a Keep valid-JSON response body inline option to HTTP recording. Tick it under Advanced parameters on the HTTP Record page to keep a recorded response body inline in the mapping (as a structured jsonBody) when it is valid JSON served with a text content type, instead of writing it to a separate __files/ body file — so a recorded JSON API produces self-contained mappings with no companion body files. Non-JSON text bodies and binary bodies (including a binary content type whose bytes happen to parse as JSON) are still externalised to __files/ as before, and there is no size limit on inlining, so a very large JSON response is embedded directly in the mapping file. The option is off by default, so existing recording workflows are unchanged; set trafficparrot.http.recording.response.inlineJson in trafficparrot.properties to change the checkbox's default state. See Keeping JSON response bodies inline.
• Added an Externalise request body to file option to HTTP recording — the request-side counterpart of the response-side inline option, and the write-time counterpart of a file-backed request body matcher. Tick it under Advanced parameters on the HTTP Record page to have a recorded request body written to a separate __files/ file, with the recorded mapping's request matcher carrying a bodyFileName reference (equalToJson, equalToXml, binaryEqualTo or equalTo according to the request's content type, a binary body written byte-for-byte) instead of an inline bodyPatterns value. Empty and multipart request bodies are always kept inline. An externalised request body loads, matches on replay, and is editable in the Add/Edit mapping editor exactly like a manually file-backed one. The option is off by default, so existing recording workflows produce byte-identical mappings; set trafficparrot.http.recording.request.externaliseToFile in trafficparrot.properties to change the checkbox's default state. See Externalising request bodies to files.
• The URL contains filter on the HTTP import preview now supports glob wildcards — * for any sequence of characters and ? for any single character — in addition to plain substring matching. Plain text still matches any path that contains it; a pattern with a wildcard switches to an anchored, case-insensitive match against the request path (for example /api/*, *.json or /users/?). This filters which entries are shown for selection only and does not change how the imported stubs match at runtime (GitHub issue #68).
• The admin request-journal endpoint (GET /api/http/requests) now accepts two optional query parameters for paging and filtering a large journal: limit bounds the response to the first N entries in journal order, and since returns only the requests recorded strictly after a given ISO-8601 timestamp (for example 2026-07-16T10:00:00Z); a negative limit or a malformed since is rejected with HTTP 400. Both are off by default, so a request with neither parameter still returns the whole journal unchanged, and the meta.total field continues to report the full count of everything recorded, independent of either parameter. See Page or filter the journal.

Documentation

• Added a Recording HTTPS via the browser proxy section to the User Guide. It explains that Traffic Parrot records HTTPS by acting as a browser (forward) proxy: point your browser or application's proxy setting at Traffic Parrot, import the Traffic Parrot CA certificate (certificates/virtualservice-CA-keystore.p12, password trafficparrot, PKCS12) into the client's trust store, and Traffic Parrot mints a per-host certificate on the fly from the TLS SNI so it can decrypt and record traffic to any host. The Recording HTTP section links across to it.

Changes

• The default in-memory request-journal retention has been lowered from 10000 to 1000 entries. The trafficparrot.virtualservice.maxRequestJournalEntries property bounds all request journals — HTTP, gRPC and JMS/IBM® MQ — so by default each now keeps the last 1000 requests (older entries age out as new requests arrive) instead of 10000. This keeps the default -Xmx128m install memory-safe under a sustained first-run/evaluation workload, where the oversized journal could otherwise exhaust the heap. If you need a longer request-log history, raise maxRequestJournalEntries in your trafficparrot.properties; the JVM heap setting (-Xmx128m) is unchanged.

Traffic Parrot 5.60.4 released, what's new?

We have just released version 5.60.4. Here is a list of the changes that came with the release:

Features

• The HTTP Add/Edit mapping form now lets you edit a file-backed response (one served from a bodyFileName file) directly in the editor: a Response from file note above the response body field shows the file name, the body field is editable in place, and saving writes the edited content back to the body file in the __files directory through the mapping repository (so the in-memory cache stays in sync). When the same body file is shared by other mappings a warning is shown, because saving changes the response for all of them. You can flip a response between inline and file-backed in both directions — Switch to inline detaches the file and stores the body on the mapping, and Switch to file externalises an inline body to a new file under responses/ on save. Binary body files stay read-only and are edited on disk. Previously a file-backed response appeared as an empty body field with no indication it was served from a file.
• The same file-backed response handling is now available on the gRPC Add/Edit mapping form: when a gRPC mapping's response is served from a response.bodyFileName file, a Response from file note shows the file name, the body field is editable in place and pre-filled from the __files directory, and saving writes the edited content back to the body file through the mapping repository. A warning is shown when the file is shared by other mappings, and you can flip a response between inline and file-backed in both directions (Switch to inline / Switch to file). Binary body files stay read-only.
• Added support for externalising a request body matcher into a file in the __files directory via bodyFileName, mirroring the response-side bodyFileName convention. Any of the request body matchers (equalTo, equalToJson, equalToXml, binaryEqualTo, contains, doesNotContain, matches, doesNotMatch, matchesJsonPath, matchesXPath, matchesXml) can load the value it compares against from a file instead of inlining it in the mapping, resolved relative to the mapping's sibling __files directory and loaded once at mapping-load time. A file-backed matcher is shown in the HTTP Add/Edit mappings GUI with a Content from file note, and the mappings-list Request body column renders the matcher content inlined from the file. The externalised form is also accepted through the WireMock admin API (POST /__admin/mappings, PUT /__admin/mappings/{id} and POST /__admin/mappings/import): the file is resolved when the mapping is registered, a reference to a missing file is rejected at registration with HTTP 422 naming the file, combining bodyFileName with any other key in the same matcher entry is rejected, and mappings saved to disk keep the bodyFileName reference instead of the file's contents.
• Added a Static Files browser under the HTTP menu that lists the active scenario's __files directory, marks each file as referenced or orphaned by cross-referencing the HTTP mappings, and previews a selected file's content (JSON and XML are pretty-printed; image files are rendered inline and other binary files show their content type and size). The browser also lets you:
  • Create a new text file under the __files directory directly from the admin UI: a New file affordance prompts for a relative file name and content and adds the file to the browser, where it appears with an orphaned badge until a mapping references it.
  • Edit a text file in place: selecting a non-binary file and clicking Edit replaces the preview with an editable text area and Save/Cancel buttons, and saving overwrites the file's content in the __files directory. When the file is referenced by one or more mappings (through response.bodyFileName) a warning is shown, because saving changes the response for all of them. Binary files remain read-only and are edited on disk.
  • Delete a file: each row has a Delete button that reveals an inline Confirm/Cancel step (no browser pop-up), and confirming the deletion of an unreferenced file removes it from disk and the row disappears. The delete is reference-safe — if the file still backs a mapping the deletion is refused, a banner lists the referencing mapping(s) and the file stays listed. The reference check is complete: it covers both a file used as an HTTP response body (response.bodyFileName) and a file used as a request body matcher, so a file that the browser's orphaned badge reports as unreferenced (the badge inspects only response references) can still be blocked from deletion when it is genuinely in use, protecting you from silently breaking a request matcher. Overriding the refusal is not currently supported; to delete a referenced file, first remove or repoint the mapping(s) that use it.
  • Rename a file within the __files directory: each row has a Rename button that reveals an inline editable target-name field with Confirm/Cancel (no browser pop-up). Renaming an unreferenced file moves it to the new name, creating any intermediate sub-directories the new name implies. Like delete, the rename is reference-safe — if the file still backs a mapping the rename is refused, a banner lists the referencing mapping(s) and the file keeps its old name, because renaming would leave the mapping pointing at a name that no longer exists. The reference check is complete in the same way: it covers both a file used as an HTTP response body (response.bodyFileName) and a file used as a request body matcher, so a file that the orphaned badge reports as unreferenced (the badge inspects only response references) can still be blocked from renaming when it is genuinely in use. Renaming onto a name that already exists is refused as well, so you never silently overwrite another file. To rename a referenced file, first remove or repoint the mapping(s) that use it; automatically updating the referencing mappings to the new name is not currently supported.
  • Upload an existing file into the __files directory straight from your browser: an Upload button next to New file opens a file picker, and the chosen file is uploaded and added to the browser. Both text and binary files are accepted — the bytes are stored verbatim, so an uploaded image is listed and rendered inline in the preview pane, and any other uploaded binary file is listed and shown with its content type and size. Uploading a file whose name already exists is refused so you never silently overwrite another file, and unsafe file names (for example an absolute path or one containing .. that would escape the scenario's __files directory) are rejected. The upload has a configurable size limit, set by the new trafficparrot.multipart.upload.max.size.mb property (default 10 MB, shared by all admin-UI file uploads); a file larger than the limit is rejected with HTTP 413 and the message File exceeds the maximum upload size of N MB shown in the upload form. The limit applies only to file uploads through the admin UI and does not affect recorded traffic or mapping sizes.
  • Resize the panes with a draggable divider between the file list and the preview, so you can widen either side to suit the file you are reading. Drag the divider to set the split (it stays between 20% and 80% so neither pane collapses), and double-click it to snap back to the default split. The split you choose is remembered in your browser across page reloads. On narrow screens the panes stack vertically as before.
  • Browse files as a directory tree: files in sub-directories of __files are now grouped under expandable folder rows instead of being listed by full relative path. Each folder shows a caret you can click to collapse or expand its contents (all folders are expanded by default), and each file is labelled by its own name and indented under its folder. Selecting a file previews it, and the referenced/orphaned badges and rename, delete, edit and upload actions all work exactly as before.
  • Preview images and other binary files: selecting an image file (PNG, JPEG, GIF, SVG, WebP, BMP, ICO, APNG or AVIF) now renders the image inline in the preview pane instead of the bare not previewable note, so you can see at a glance which image a mapping serves. Selecting any other binary file shows a Binary file — <content type>, <size> note (for example Binary file — application/octet-stream, 2.3 KB) instead, so you can tell its type and size without downloading it. Text, JSON and XML files are still pretty-printed and editable in place as before; images and other binary files remain read-only and are edited on disk. Image and binary files are served back for the preview with a nosniff content-type guard and as an attachment, so a file whose bytes happen to contain active content (such as a script-bearing SVG) can never run in your browser from the preview.
• Added a Logging documentation page covering how to enable verbose logging, change the log level, find the log files (logs/trafficparrot.log), turn logging down or off, and use the Request Log near-miss view to see why an HTTP request did not match.
• The HTTP mappings list now shows a Recording active banner above the table while a recording session is running, as a reminder that deleting a mapping while recording also stops that endpoint being re-recorded for the rest of the session.
• The HTTP Record page now shows a Live coverage panel while a recording session is active, refreshing about once a second. It gives a running tally of the distinct endpoints seen so far — how many now have a mapping, how many were observed but are still unmapped, and how many mappings have not been observed — plus the per-endpoint observed and unmatched request counts, so you can tell during the session whether a recording has captured everything you expected. Endpoints are grouped by HTTP method and normalised path using the same convention as Mapping cleanup, and the panel notes how many requests in the request journal the tally is based on.
• Added a Verifying requests guide for WireMock users, mapping the verify() DSL onto Traffic Parrot's request journal: assert a request was made, was made exactly N times, or was NOT made via POST /api/http/requests/count, inspect captured bodies via POST /api/http/requests/find, list unmatched requests and near misses, and reset the journal — with a WireMock-to-Traffic-Parrot translation table and copy-paste curl recipes.
• The Application logs view (HTTP menu → Logs → Application logs) now offers a structured view of the server log in addition to the existing raw text view. The raw view remains the default; clicking Structured view parses each entry into its timestamp, level, thread and message, with a coloured band and a level badge (the level text is always shown, not signalled by colour alone, so the view stays readable in greyscale and for colour-blind users). Multi-line stack traces fold into a single collapsible entry (with Expand all / Collapse all), you can filter entries by level and by free text, and any line that does not match the log pattern is shown in full rather than hidden. The existing search, last-10,000-lines truncation and Download raw affordances are unchanged.
• Added an Available helpers panel at form level — below both the request and response cards — on the HTTP and messaging (JMS, IBM MQ and file-message) Add/Edit mapping forms, so you can discover what Traffic Parrot offers without leaving the product. The collapsible, read-only panel is a sectioned shell with three catalogues: a Response templating helpers section listing the helpers grouped by category; a Request matchers section listing the available request matchers; and an Other functionality section covering Scenarios & state, Response delays, Fault simulation, response proxying, serving a response from a file, webhook callbacks and request-matching scripts. Each entry has a one-line description, a copy-ready snippet (already scaffolded with example parameters) and a docs link, with a filter box that narrows every section as you type (matching name and description) and a per-entry Copy button. It is discovery-only and does not change how mappings are saved or how responses are rendered.
• The HTTP Add/Edit mapping form now lets you author the advanced response delay and fault shapes that were previously only configurable in mapping JSON: a log-normal random delay (median, sigma and an optional maximum, to model realistic response-time spread), a chunked dribble delay (split the response body into a number of chunks sent over a total duration, to simulate a slow trickle), and the CONNECTION_RESET_BY_PEER response fault. Because the editor now understands these shapes, opening and saving a WireMock-format JSON mapping in the GUI no longer silently strips them — previously a form open-save dropped a log-normal delayDistribution, a chunkedDribbleDelay or a CONNECTION_RESET_BY_PEER fault, so this also fixes that data loss.
• Added a matches GraphQL request body matcher for stubbing a POST /graphql endpoint, where many operations share one URL. Its full-query form matches the request's query semantically — tolerant of insignificant whitespace, selection-set field order, and argument order, so differently formatted but equivalent queries select the same response (aliases and directives stay significant). Its object form matches on operationName alone to disambiguate operations on one URL, with an optional variables object to also assert on the request's variables. Select matches GraphQL in the Request body matcher dropdown on the HTTP Add/Edit mapping form to author the full-query form; the operation-name form is authored by importing mapping JSON. A request that is not valid GraphQL simply does not match (it is never an error), and a mapping whose own GraphQL query is invalid is rejected at save/import time.
• Added a trafficparrot validate command that checks your mappings against their bound schemas without starting the server, for use as a continuous integration step. For HTTP it reports both schema drift (a mapping whose URL path and method are not declared in any OpenAPI specification in openapi/) and under-coverage (an operation declared in a specification that no mapping covers), so a partially-mocked API cannot silently drift from its contract; gRPC mappings are validated against their proto schema. It prints a labelled report and exits 0 (no drift), 1 (drift detected) or 2 (usage or configuration error, including a files-root with no mappings). Operations you deliberately do not mock can be excluded with an exclude.operations list in an openapi-coverage.properties file in the files-root; an allowlist entry that matches no operation in the specification is itself reported as drift so the list cannot quietly go stale.
• Added an external-process HTTP response transformer that passes the response through a user-supplied executable (the "middleware") written in any language — familiar to Hoverfly users. For each matched request on an opted-in mapping, Traffic Parrot serialises a versioned JSON envelope (the matched request plus the response about to be sent) to the executable's stdin and applies the mutated response read back from stdout (status, headers, body); request mutation is not supported in this release. The feature is off by default (trafficparrot.http.externalprocess.enabled) and confined to a single operator-vetted directory (trafficparrot.http.externalprocess.allowedDir) — the executable runs as the Traffic Parrot OS user with no sandbox, so enable it only on trusted hosts. Each mapping configures the executable, optional args, a per-invocation timeoutMs (default 5000, the process is killed on expiry), and an onError fallback (fail-open returns the original response, fail-closed returns HTTP 500) applied on non-zero exit, timeout, malformed output, or a missing/disallowed executable.
• The external-process transformer can now be enabled and configured directly in the HTTP mapping editor, instead of only by hand-editing the mapping JSON. When an operator has set trafficparrot.http.externalprocess.enabled=true, an ExternalProcessTransformer toggle appears in the Response transformers list under Advanced parameters; turning it on reveals an External Process tab in the Transformer parameters panel with structured fields for the executable, args (space or newline separated), timeoutMs, and onError (fail-open/fail-closed). The option is offered only when the feature is enabled, and selecting it does not bypass the trafficparrot.http.externalprocess.allowedDir allow-list that still gates which executables may run. Saving writes the same transformerParameters.external-process JSON the editor, the mapping file on disk, and the WireMock Admin API all share. See Configuring it in the editor GUI.

Documentation

• Added an Environment variables in responses how-to page covering the {{systemValue}} Handlebars helper: reading an environment variable (type='ENVIRONMENT') or a JVM system property (type='PROPERTY') into a response body or header, the default= fallback, the wiremock* allow-list and the [ERROR: Access to … is denied] failure mode, and the underscore-vs-dot naming rule for environment variables.
• Added a CORS for stub responses how-to answering the common WireMock “CORS not working” question. It documents that the Traffic Parrot virtual service is CORS-friendly out of the box for every path — the browser CORS preflight (OPTIONS) is auto-answered HTTP 200 with Access-Control-Allow-Methods, Access-Control-Allow-Headers and Access-Control-Max-Age, and the request Origin is reflected into Access-Control-Allow-Origin on the actual response — with no flag and no per-stub configuration (unlike WireMock's off-by-default --enable-stub-cors). It also shows how to pin a specific origin by setting Access-Control-Allow-Origin in a stub's response.headers, and clarifies that this CORS behaviour is independent of the trafficparrot.http.optionsResponse.enabled property (which emits only an Allow header).
• Expanded the JVM arguments section of the User Guide with a full reference for the jvm.args file: where it lives in the install directory, how each non-empty line is passed to the server JVM at startup, a table describing every shipped default (including -Xmx128m, the line to raise for large recordings or datasets), and typical adjustments.

Fixes

• Binary bodyFileName responses (images, PDFs, etc.) are now served byte-for-byte unchanged when HTTP Handlebars is enabled (the default, trafficparrot.http.handlebars.enabled=true) — no per-mapping configuration required (fixes a corruption where binary files served via bodyFileName were re-encoded as text). See Response body files: templating vs byte-for-byte.
• Whether a bodyFileName response is templated or served byte-for-byte is now decided by positive binary evidence (the response Content-Type or the file extension): recognised binary types are served byte-for-byte; everything else is run through Handlebars. This also ensures text/template body files with no Content-Type are still rendered.
• The Duplicate and Delete buttons in the gRPC mappings list work again — a regression had stopped them working, so a gRPC mapping could not be duplicated or deleted from the admin UI. Both actions now behave as they do for HTTP mappings.
• A stub configured with the INCORRECT_SMALL_CONTENT_LENGTH response fault now injects the fault correctly — it serves the stubbed status with a too-small Content-Length header and a body truncated to that length — instead of returning an HTTP 500 error.
• File-message mappings now honour the priority field when resolving match precedence. Previously, when two file-message mappings both matched an inbound message, priority was ignored and the mapping loaded first always won; HTTP, JMS and IBM MQ mappings already honoured priority correctly.
• Library upgrades to fix OWASP issues.

Changes

• When the external-process transformer is enabled, Traffic Parrot now validates the trafficparrot.http.externalprocess.allowedDir directory once at startup and logs a warning if it is empty, does not exist, is not a directory, or is non-canonical, so a misconfigured allow-list is surfaced at startup rather than at the first matched request. The check is warn-only — the server still starts.
• The Import skeleton… upload on the HTTP and gRPC Add/Edit mapping pages (importing an OpenAPI/Swagger HTTP skeleton or a proto/descriptor-set gRPC message skeleton) now has a configurable size limit, set by the trafficparrot.multipart.upload.max.size.mb property (default 10 MB) — the same property that caps the Static Files browser upload. A file larger than the limit is rejected with HTTP 413 and the message The uploaded file exceeds the maximum upload size of N MB shown in the import error area, instead of being buffered unbounded. Previously these imports had no size limit.
• The HTTP Import mappings REST endpoint (/http/management/importMappings) now enforces the same trafficparrot.multipart.upload.max.size.mb cap (HTTP 413 on an oversize upload) as the skeleton-import and Static Files uploads. Previously this endpoint had no size limit.
• Externalising an inline response body to a file with Switch to file on the HTTP and gRPC Add/Edit mapping forms now takes a single click. The one click makes the response body file-backed straight away — it reveals the (editable) file name field pre-filled with a suggested name, shows the Response from file note, and offers Switch to inline to revert — and clicking Save then writes the body to that file under __files. Previously a second click was needed to confirm the file name before saving would externalise. Clearing the file name field keeps the body inline.
• Upgraded bundled JRE from 21.0.7 to 21.0.11

Traffic Parrot 5.59.2 released, what's new?

We have just released version 5.59.2. Here is a list of the changes that came with the release:

Features

• Added matches FIX field body matcher for IBM MQ, JMS, and File messaging mappings, enabling tag-level matching on FIX protocol messages by tag number and regex (version-agnostic across FIX 4.2, 4.4, 5.0, and FIXT)
• Added {{fixField}} Handlebars helper for extracting FIX protocol message field values in dynamic response templates by tag number
• Added {{#fixWithChecksum}} block helper with inline {{fixBodyLength}} and {{fixCheckSum}} placeholders that auto-compute FIX 4.x tag 9 (BodyLength) and tag 10 (CheckSum) for FIX response templates, removing the need to hand-calculate these values
• Added {{image}} Handlebars helper for generating placeholder PNG images (grey rectangle with dimensions overlay) directly from a mapping body, with configurable width, height, and overlay text arguments — JDK-only, no external dependencies, deterministic within a single JVM
• Added base64-decode-body built-in response transformer that Base64-decodes the rendered response body and serves it as raw bytes, enabling binary responses (PNG, PDF, ZIP, etc.) from JSON mappings when paired with helpers such as {{image}}
• Added a Transformer parameters editor under Advanced parameters on the HTTP Add/Edit mapping form, so the response.transformerParameters JSON block (used by HmacSigningTransformer and other parameter-driven response transformers) can be authored and edited in the GUI instead of only in the mapping JSON file. The editor auto-formats the JSON on blur (2-space indent) and validates on save (invalid JSON prevents submit with an inline error). Existing mappings round-trip semantically through the form (whitespace is normalised; field order is preserved). See Editing transformer parameters in the GUI for details.
• Added a Query parameters section to the HTTP Add/Edit mapping panel, with per-parameter rows that support equal to, contains, matches regex, and absent matchers (see Request query parameter matchers). Saving produces standard WireMock queryParameters JSON; loading an existing mapping with a queryParameters block populates the rows on the form. This replaces the previous workarounds of putting the full query string in urlEqualTo or hand-writing a lookahead regex in urlMatching — both of which continue to work for existing mappings.
• Added a Convert query string to rows link under the Request URL field on the HTTP Add/Edit mapping panel. Clicking it parses name=value pairs out of a pasted URL's query string, appends one equal to row per pair to the Query parameters section, and strips the query string from the URL field. URL-encoded values (e.g. %20) are decoded automatically. The conversion is staged client-side — you still need to click Save to commit the changes.
• JSON and XML request and response bodies are now pretty-printed in the expanded detail of the Request Log. Each body block is collapsible and has a Copy button that copies the original, unformatted body. Bodies that are truncated (over 10 KB), malformed, or not JSON/XML continue to be shown raw. The same formatting applies to the gRPC requests page and the JMS, IBM MQ, and file messaging requests pages.
• Added support for supplying the license through the TRAFFICPARROT_LICENSE environment variable (base64-encoded), so it can be injected at runtime from a Kubernetes Secret, Docker secret, or secrets manager instead of being baked into a Docker image. The system property -Dtrafficparrot.license.content takes precedence over the environment variable, which takes precedence over the classpath trafficparrot.license file; if neither is set, the classpath file is read as before (no change for existing installations). A set-but-invalid value fails fast with a clear error rather than silently falling back to the file.
• The HTTP Add/Edit mapping form now shows a Response from file note above the response body field when a mapping's response is served from a bodyFileName file, making it clear that the body is loaded from the __files directory rather than typed inline.

Changes

• Removed the unused SOAP message signer dropdown from the HTTP Add/Edit mapping form's Advanced parameters section. SOAP message signing continues to work via the SoapMessageSigner entry in the trafficparrot.http.responsetransformers startup property (see Properties) and the per-mapping Response transformers multiselect.
• The tooltip shown when hovering over the URL Matcher or URL cell in the HTTP mappings list now shows the complete request match for that mapping — the HTTP method, the URL matcher type, the full untruncated URL or pattern, and each query parameter matcher (previously not visible anywhere in the list).
• The tooltip shown when hovering over the gRPC method cell in the gRPC mappings list now shows the complete request match for that mapping — the gRPC method, the request message matcher, and each request metadata matcher (previously not visible anywhere in the list).
• Deleting an HTTP mapping while recording now suppresses re-recording of that endpoint (matched by method and normalised URL path) for the rest of the current recording session, instead of immediately re-creating it the next time the same request is proxied. The suppression is session-scoped — it is cleared when recording stops and at the start of each new recording session.

Traffic Parrot 5.58.6 released, what's new?

We have just released version 5.58.6. Here is a list of the changes that came with the release:

Features

• Added near-miss diagnosis for unmatched HTTP requests with a per-field comparison table showing match/mismatch indicators, stub name headings, a "View Stub" link to edit the stub directly, and a "Show full stub JSON" toggle
• Added HTTP Request Log page with auto-refresh, expandable request details, and near-miss display for unmatched requests
• Added HTTP Passthrough Proxy mode that forwards unmatched requests to a real backend, with a blue "Proxied" badge in the request log and one-click stub creation from proxied requests
• Added FTP and SFTP drivers for file mocking, enabling record and replay of file-based integrations over remote FTP and SFTP servers alongside the existing local file system driver
• Added HAR file import support on the HTTP Import page, allowing you to import HTTP Archive files exported from browser DevTools to create stubs from captured traffic
• Added preview and filter for HAR and OpenAPI imports, with host, method, status, and URL filters plus per-entry selection and duplicate detection before importing
• Added REST API for importing mappings via curl or other HTTP clients, supporting all import formats (HAR, OpenAPI/Swagger, RAML, WireMock ZIP) including filtered import with hostFilter, methodFilter, statusFilter, and urlFilter parameters
• Added matches SWIFT field body matcher for IBM MQ, JMS, and File messaging mappings, enabling field-level matching on SWIFT MT messages by tag number and regex
• Added swiftField Handlebars helper for extracting SWIFT MT message field values in dynamic response templates
• Added header matcher types for HTTP stub creation, supporting contains, matches (regex), and doesNotMatch matchers in addition to the default equalTo
• Added HlsStreamTransformer for simulating HLS video streaming — serves dynamically generated .m3u8 playlists and .ts video segments from a single wildcard mapping, including multi-variant adaptive-bitrate (ABR) playlists with scenario-state-driven variant switching
• Added enable/disable toggle for HTTP mappings — temporarily disable a mapping without deleting it using the eye icon in the mapping list
• Added support for uploading precompiled protobuf file descriptor sets (.desc and .protoset files) via the gRPC skeleton import UI, in addition to .proto source files
• Messaging export/import (JMS, File) now includes the data/ directory in the exported ZIP, so dataSource-backed mappings (CSV lookup, Excel lookup, object store) work correctly when imported on another instance
• Added strict error handling mode for Handlebars helpers via trafficparrot.virtualservice.handlebars.throwErrors, which causes helper errors to throw exceptions (HTTP 500 or messaging failures) instead of embedding inline error strings in responses
• Added scanConsistency parameter to the Couchbase N1QL dataSource helper, allowing you to choose between REQUEST_PLUS (consistent, default) and NOT_BOUNDED (faster) query scan consistency, plus improved error handling that returns error messages instead of exceptions
• Added JMS performance monitoring to log total processing time of JMS messages, matching the existing IBM MQ performance monitoring capability
• Added namespace support to the manageState Handlebars helper using namespace/variableName syntax, allowing state isolation between different test scenarios
• Added namespace support to the State Management REST API, enabling isolated state per scenario or test case:
  • Create or update namespaced state using PUT /api/state/{namespace}/{name}
  • Get namespaced state using GET /api/state/{namespace}/{name}
  • List all state in a namespace using GET /api/state/{namespace}
  • Clear all state in a namespace using DELETE /api/state/{namespace}
  • Existing /api/state/global/{name} routes remain unchanged for backward compatibility
• Added PUT /api/configuration/files/{file} endpoint for creating new configuration files programmatically (returns 201 Created, or 409 Conflict if file already exists)
• OpenAPI import now fetches content from externalValue URLs in named examples, using the fetched response body as the mock response instead of a placeholder message
• Added HMAC response signing built-in response transformer — computes an HMAC signature of the response body and adds it as a Base64-encoded header, configured via transformerParameters.hmacSigning in the mapping JSON, supporting HmacSHA1, HmacSHA256, and HmacSHA512 algorithms for simulating webhook and API gateway authentication
• Added OpenAPI schema check that validates HTTP mappings against OpenAPI specification files at startup, preventing startup if any mapping references a URL path or method not found in the specifications — enable with trafficparrot.virtualservice.openapi.check.mapping.schema.on.startup=true
• Added configurable IBM MQ response headers (replyToQueueManagerName, replyToQueueName) in mapping JSON files with Handlebars template support, allowing dynamic control of response message routing headers
• Added trafficparrot.ibmmq.connect.options.accessQueue.input property to configure how IBM® MQ queues are opened for input (consumer) operations, mirroring the existing accessQueue.output property for producers

Fixes

• Broker configuration panels (JMS, IBM MQ, File messaging) now show empty configuration fields as blank rather than rendering the literal text "null" when no value is configured
• Added path traversal prevention to the objectStore Handlebars helper to ensure file access stays within the data directory
• Fixed OpenAPI 3.1 import to correctly handle JsonSchema types, generating proper example responses instead of failing with an error
• Fixed binary schema fields in OpenAPI imports to show a (binary) placeholder instead of corrupted text
• Improved error messages for unsupported external $ref schema references in OpenAPI imports

Changes

• Upgraded web UI framework from Bootstrap 3 to Bootstrap 5
• Upgraded from WireMock 2 to WireMock 3
• Simplified the HTTP Record page to show a single Recording URL input by default for the common case of recording one backend; click Record from multiple URLs to reveal URL pattern fields and record from multiple backends in one session
• Added trafficparrot.virtualservice.grpc.tls.enabled and trafficparrot.virtualservice.grpc.non.tls.enabled properties to allow independently enabling/disabling each gRPC server port
• New code should use the TransformedRequest.like(Request) static factory method in place of the deprecated TransformedRequest public constructor; the deprecated constructor remains available for backwards compatibility
• IBM MQ client library updated from com.ibm.mq.allclient to com.ibm.mq.jakarta.client. If upgrading, replace com.ibm.mq.allclient.jar with com.ibm.mq.jakarta.client.jar in your lib/external/ folder — see JMS and IBM MQ documentation for details. Existing javax.jms plugins continue to work without source changes; support for javax-based plugins will be removed in a future major release.

Traffic Parrot 5.57.3 released, what's new?

We have just released version 5.57.3. Here is a list of the changes that came with the release:

Features

• Added import/export UI for gRPC, Files and JMS protocols
• Added parseCsv Handlebars helper for parsing CSV data in dynamic responses
• Improved OpenAPI validation to correctly resolve $ref schema references

Fixes

• Fixed mapping name not being saved when cache is enabled
• Fixed OpenAPI validation issue with double-slash paths
• Fixed configuration files API path handling on Mac/Linux and Windows
• Library upgrades to fix OWASP issues

Changes

• Renewed sample SSL certificates

Traffic Parrot 5.56.5 released, what's new?

We have just released version 5.56.5. Here is a list of the changes that came with the release:

Features

• Added ResponseToPdf transformer for converting HTTP responses to PDF documents

Fixes

• Fixed cache invalidation issue when modifying active composite scenario
• Fixed an issue with __files not being read from the current scenario for some file types
• Fixed transformer multi-select UI behavior in mapping editor
• Mapping files are no longer unnecessarily trimmed on startup
• Prevent comment line being written for scenario property files
• Improved SDK workspace configuration to avoid missing dependency errors
• Library upgrades to fix OWASP issues

Changes

• Updated sample gRPC SSL certificates
• Upgraded gRPC from 1.67.1 to 1.75.0

How Traffic Parrot's Service Simulation Platform Accelerates ECC-2 Compliance for Saudi Organizations

Saudi Arabia's updated Essential Cybersecurity Controls (ECC-2:2024) framework presents both challenges and opportunities for organizations operating in the Kingdom. With 108 controls across four domains and new requirements for complete environment segregation, comprehensive security testing, and Saudi workforce localization, organizations need robust testing solutions that can deliver compliance without compromising development velocity.

Traffic Parrot's service simulation and API mocking platform directly addresses these challenges, enabling organizations to meet ECC-2 requirements while maintaining the agility needed for Vision 2030's digital transformation goals.

The ECC-2 Compliance Challenge

The National Cybersecurity Authority's updated framework isn't just about checking boxes. It demands:

• Complete isolation between production, test, and development environments
• Comprehensive security testing before any production deployment
• Zero exposure of production data during testing phases
• Continuous validation of security controls throughout development
• Third-party risk assessment without actual system connections

Traditional testing approaches that rely on production systems or real data simply cannot meet these requirements efficiently or safely.

Traffic Parrot's Direct Solution

Our service simulation platform transforms how organizations approach ECC-2 compliance by creating virtual representations of APIs, services, and third-party systems. This isn't just about mocking—it's about building a comprehensive testing ecosystem that satisfies regulatory requirements while accelerating development.

Real-World Application: Saudi Banking Sector

Consider a Saudi bank integrating with SAMA regulatory reporting APIs, SADAD payment services, and Absher authentication. With Traffic Parrot, they can:

• Simulate all government service APIs without production credentials
• Test security controls including OAuth flows, certificate validation, and encryption
• Validate disaster recovery procedures through controlled failure scenarios
• Train security teams on incident response without real threats
• Document everything for NCA compliance audits

Supporting Saudization Requirements

ECC-2 mandates that all cybersecurity positions be filled by qualified Saudi professionals. Traffic Parrot supports this requirement through:

• Local deployment options within Saudi data centers
• Knowledge transfer initiatives
• Simplified interfaces that accelerate skill development

Getting Started

Organizations can achieve measurable ECC-2 compliance improvements within weeks:

1. Deploy Traffic Parrot in your isolated test environment
2. Create service simulations for your critical APIs and integrations
3. Implement security test scenarios aligned with ECC-2 controls
4. Generate compliance reports for NCA requirements
5. Scale across teams as you demonstrate value

The Path Forward

As Saudi Arabia advances its Vision 2030 objectives, the intersection of innovation and security becomes increasingly critical. Traffic Parrot enables organizations to move fast without breaking things—or regulations.

The updated ECC-2 framework isn't just another compliance burden. It's an opportunity to build better, more secure systems. With Traffic Parrot's service simulation platform, you can turn regulatory requirements into competitive advantages.

#ECC2 #SaudiCybersecurity #APITesting #ServiceSimulation #NCA #Compliance #TrafficParrot

Traffic Parrot 5.55.2 released, what's new?

We have just released version 5.55.2. Here is a list of the changes that came with the release:

Features

• Added keyboard shortcut Ctrl/Cmd+F to focus search in mappings list for improved navigation
• Separated URL matcher from URL in mappings list to enable proper sorting by URL
• Improved UI responsiveness when working with large numbers of mappings

Fixes

• Refresh scenario dropdown when composite scenario first used

How to Mock APIs 10x Faster Using AI Chatbots

In our latest tutorial, we create a dynamic mock that returns different responses based on the day of the week. What typically takes 20 minutes of documentation diving, AI completes helps us complete in under 2 minutes.

Quick Tips for Success

Choose the Right Model

• Paid models (Claude Opus 4, ChatGPT 4.5) = first-try success
• Free models = expect 2-3 iterations

Write Better Prompts

• Be specific about your requirements
• Describe expected behavior clearly

Beyond Basic Mocks

• Use AI for complex troubleshooting
• Validate your debugging approach
• Discover diagnostic steps you might have missed

Get Started Today

We've built custom AI assistants specifically for Traffic Parrot users. Access them at trafficparrot.com/ai.

⚠️ Security reminder: Always remove sensitive data before sharing with AI.

Traffic Parrot 5.54.2 released, what's new?

We have just released version 5.54.2. Here is a list of the changes that came with the release:

Features

• Added Composite scenario support for HTTP virtual services, allowing you to combine mappings from multiple scenarios into a single active scenario
• Added URL rewriting support during HTTP recording via the trafficparrot.http.recording.rewrite.regex property to automatically transform URLs in response bodies
• Added RequestToPdf response transformer for generating PDF files from request bodies in test environments
• Added support for Brotli compression decoding during HTTP recording

Fixes

• Fixed a UI mapping list rendering issue seen on some browsers
• Fixed tooltip display issues in the web interface
• Library upgrades to fix OWASP issues

Changes

• Upgraded bundled JRE from 21.0.6 to 21.0.7