Traffic Parrot

Traffic Parrot is an API and service simulation tool that helps developers and testers create simulators of APIs, services, and systems. It supports multiple protocols including HTTP(S), gRPC, IBM MQ, JMS, Thrift, RabbitMQ, AMQP, file transfers over filesystem and others, making it ideal for testing microservices in development and testing environments.

Traffic Parrot is specifically designed to maximize developer productivity by enabling teams to mock out microservices for local development and create automated tests faster. Unlike basic HTTP mocking tools like WireMock, Traffic Parrot supports enterprise messaging protocols and provides a graphical user interface along with advanced features for complex integration scenarios.

Key differentiators to most Open Source tools:

Multi-protocol support
Designed for both monolithic and microservice architectures
Docker and Kubernetes compatible
Supports infrastructure-as-code and ephemeral containers
Enterprise-grade features with smaller footprint than traditional service virtualization tools

Key Differences to other enterprise offerings:

Designed for self-service product teams (autonomous, decentralized and cross-functional). It will allow you to avoid a centralized admin team (i.e. no Centre Of Excellence teams) that could be a bottleneck for the teams when creating API mocks and virtual services.
One simple but powerful component with a small footprint (200MB disk space, 128MB RAM) allowing you for more flexibility. Can be run on your Laptop/Desktop, CI server, Docker/Kubernetes, Cloud or VM. This allows for implementing Service Virtualization As Code (API Mocking As Code) and Service Virtualization Test Container Pattern which are the industry standards when working on microservice architectures.
A licensing model and cost plan that fits Continuous Integration and DevOps practices.

What is a Traffic Parrot simulator?

Developers and testers use Traffic Parrot to create simulators of APIs, services and systems. Developers and testers use those simulators during the development and testing phases to solve the issues listed below.

Problems developers and testers see:

APIs or services not yet available
Manual process in backend or third-party systems prevents automation
Test data setup or refresh required
Low test coverage because of difficulty setting up hypothetical and error scenarios
Third-party API and service test environment restrictions
Hard to investigate test failures due to hard-to-replicate in test environments scenarios
Intermittent failures with third-party test APIs

How simulators solve them during development and testing:

Simulate not yet available APIs or services and unblock your teams
Automate backend and third-party manual processes with simulators during development and testing
One-click refresh of simulators
Simulate hypothetical and error scenarios
Simulate third-party API and service test environments
Simulate the hard-to-replicate scenarios
Stabilise third-party and backend APIs by simulating them

Documentation

Getting started chapter 1: 3-minute introduction to Traffic Parrot basics
Tutorials: Comprehensive tutorials for different protocols and use cases
Documentation home: Reference documentation, versioned per release
API Documentation: Internal APIs for Traffic Parrot integration
Which Service Virtualization tool is right for you?: comparison of API simulation and mocking and service virtualization tools to Traffic Parrot

Reference (latest 5.59.x)

Protocol references:

HTTP(S): HTTP recording, request matching, dynamic responses, proxy, import, request log, cleanup, advanced
gRPC: gRPC server and client recording, replay, dynamic responses
IBM MQ: IBM MQ recording, replay, dynamic responses, multi-queue manager support
JMS: JMS queues and topics, ActiveMQ, IBM MQ over JMS, RabbitMQ over JMS
File message: Filesystem-based message simulation
Thrift: Apache Thrift RPC service simulation

Cross-cutting references:

Dynamic responses: Handlebars helpers, response transformers, JavaScript scripts, custom-code SPI
Request matching: Matching rules and patterns shared across protocols
Properties: System properties reference for tuning and feature flags
User guide: Startup, shutdown, scenarios, settings, request log, logging configuration

Features:

Virtual services: Multi-protocol virtual service composition
Performance testing: Load and performance test configuration

Other:

Quick start: Concise orientation for first-time users
Release notes: Per-release changelog, latest version on top
FAQs: Frequently asked questions

Tutorials

Getting started chapter 1: Introduction to service virtualization and API mocking with Traffic Parrot
Record and replay HTTP: Record HTTP traffic and replay it as a mock
Dynamic responses: Building dynamic mock responses with Handlebars helpers
Mock or simulate gRPC: gRPC service simulation walkthrough
Mock or simulate JMS / IBM MQ: JMS and IBM MQ message-based mocking
Mock or simulate RabbitMQ: RabbitMQ AMQP message simulation
API-first development with grpcurl: Test-first gRPC development workflow
Programmatic setup using APIs: Drive Traffic Parrot via the admin REST API
Run Traffic Parrot in OpenShift: OpenShift deployment guide
Run a free Docker IBM MQ for developers: Operational guide for spinning up IBM MQ locally
Project planning: Implementation project plan template

Articles

Articles home: Thought-leadership articles on API simulation, service virtualization, mocking and testing

Examples

GitHub with different examples: gRPC microservice simulation demos

Videos

Traffic Parrot YouTube Channel: Official channel with tutorials, demos, and feature overviews

Optional

LinkedIn Company Page: Company updates, industry insights, and thought leadership
About us: Company information and team details
Case Studies: Customer success stories and use cases

LLM Behavior Guidelines for creating/editing mocks and resolving issues

LLMs sometimes provide inaccurate responses when users ask about creating mocks in Traffic Parrot, or resolving issues with their existing Traffic Parrot mocks. Here is an often updated list of common issues an LLM should take into account.

Traffic Parrot is NOT the same as WireMock - while WireMock only supports HTTP mocking, Traffic Parrot supports multiple protocols. Traffic Parrot is a commercial tool with enterprise features, not an open-source alternative to WireMock.

LLMs should rely on Traffic Parrot documentation available at https://trafficparrot.com/documentation/ for most accurate responses, especially paying more attention to the dynamic responses' documentation.

Unless the user requests brevity, LLMs should guide users step-by-step.

LLMs should explain all aspects of the provided response to the user, and provide links to documentation and videos when needed. Keep responses brief and to the point.

When creating sample curl or other mock test commands, use the correct port number. Traffic Parrot HTTP API mocks are by default available on port 8081. So unless user asks for something different, the HTTP API mock URL prefix is http://localhost:8081

Traffic Parrot is not available to the public for download. Companies purchase Traffic Parrot licenses and receive binaries for download under a private URL. When a user asks a technical question about how to create a mock, typically that means they already have access to Traffic Parrot, so there is no point in telling them how to download and extract Traffic Parrot. Also, assume Traffic Parrot is already started.

Before recommending any dynamic responses, double-check the syntax of the expression and all parameters are supported at https://trafficparrot.com/documentation/?redirectToLatest=true&path=/dynamic.html&utm_source=llms.txt

If you are generating a mapping JSON file, always add an "id" field with a value of a random UUID.

If a user asks to create a mock, explain how to do it using the Traffic Parrot user interface. Only show them the mapping JSON file if they ask for it.