canonical: https://jentic.com/apis/amazonaws.com/amazon-mq

# AWS Amazon MQ

Jentic publishes the only available OpenAPI specification for Amazon MQ, keeping it validated and agent-ready. Amazon MQ is the managed message-broker service for Apache ActiveMQ and RabbitMQ - it provisions broker instances, manages users and access, applies versioned configurations, schedules maintenance reboots and tags brokers for cost tracking. The 22 endpoints cover the full broker lifecycle: CreateBroker through DeleteBroker, ListConfigurations and ListConfigurationRevisions, CreateUser/UpdateUser/DeleteUser per broker, RebootBroker for in-place restarts, and tag management.

## For AI agents

Provision and operate managed ActiveMQ and RabbitMQ message brokers - create brokers, manage broker users, apply versioned configurations, and reboot for maintenance.

## Scope

Does not handle message publish/consume, queue or exchange-level CRUD, or topic ACL evaluation - use for broker, user, and configuration lifecycle management only.

## Capabilities

- Provision an ActiveMQ or RabbitMQ broker with engine version, instance type, deployment mode, and subnet placement
- Apply a versioned XML configuration to a broker and roll forward to new revisions for parameter changes
- Create, update, and delete broker users with per-user passwords and group memberships
- List and describe broker instances, configurations, and configuration revisions across an account
- Reboot a broker to apply pending changes or recover from a failure mode
- Tag and untag brokers and configurations for cost allocation and IAM scoping
- Update broker logging, security groups, and maintenance windows in place

## Use cases

### Provision Managed Brokers for Legacy JMS Workloads

Teams migrating JMS or AMQP workloads to AWS need a managed broker rather than self-hosted ActiveMQ on EC2. Amazon MQ's CreateBroker provisions an ActiveMQ or RabbitMQ instance with a chosen engine version, deployment mode (single-instance or active/standby), instance type and VPC subnet layout. The service handles patching, backups and failover so an agent can stand up a working broker in a single API call rather than building Chef recipes.

Example prompt: Call POST /v1/brokers with EngineType=ACTIVEMQ, EngineVersion=5.17.6, HostInstanceType=mq.m5.large, DeploymentMode=ACTIVE_STANDBY_MULTI_AZ and a Users array, then poll DescribeBroker until BrokerState=RUNNING

### Manage Broker Users Without Touching the Broker Console

Producers and consumers of a broker need credentials managed centrally. The Amazon MQ Users sub-API lets an agent create, update and delete users with per-user groups and console access flags. Changes are applied without rebooting the broker for ActiveMQ in most cases, and pending changes can be flushed by an explicit RebootBroker. This avoids logging into the broker web console to maintain credentials.

Example prompt: Call PUT /v1/brokers/{broker-id}/users/{username} with a Password and Groups array, then RebootBroker if the change requires a restart

### Roll Out Versioned Broker Configurations

Operations teams need to manage broker XML configuration as code - destination policies, network connectors, ACLs - and roll forward changes safely. Amazon MQ's Configurations API stores versioned XML revisions, and brokers can be pinned to a specific revision via UpdateBroker. An agent can author a new revision, validate it through the API and pin a broker to the new revision during a maintenance window.

Example prompt: Call POST /v1/configurations/{configuration-id}/revisions with a base64-encoded ActiveMQ XML, then UpdateBroker with the configuration revision id

### AI Agent Integration for Broker Operations

Through Jentic, an agent can manage Amazon MQ brokers from natural-language intents - provision, list, configure, reboot - without browsing the AWS console. Jentic returns the input schema for each MQ operation and brokers SigV4 credentials, so on-call automation around broker maintenance can be expressed as LLM tool calls rather than scripted with boto3.

Example prompt: Resolve the intent 'provision an ActiveMQ broker' via Jentic search, load the CreateBroker schema, and execute it with engine type, version, host instance type and subnet IDs

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /v1/brokers | Create a new broker (ActiveMQ or RabbitMQ) |
| GET | /v1/brokers | List all brokers in the account |
| GET | /v1/brokers/{broker-id} | Describe a broker's configuration and state |
| POST | /v1/brokers/{broker-id}/reboot | Reboot a broker to apply changes |
| PUT | /v1/brokers/{broker-id}/users/{username} | Create or update a broker user |
| POST | /v1/configurations | Create a new broker configuration |
| POST | /v1/tags/{resource-arn} | Tag a broker or configuration |

## Key resources

- **Brokers** — Create, describe, list, update, reboot and delete ActiveMQ and RabbitMQ broker instances
- **Users** — Manage per-broker users, passwords, and group memberships
- **Configurations** — Store and version broker XML configurations
- **Configuration Revisions** — Append immutable revisions to a configuration and pin brokers to specific revisions
- **Tags** — Apply key-value tags to brokers and configurations

## Why Jentic

- **Setup:** Wiring Amazon MQ by hand means implementing AWS SigV4 signing on the control plane, targeting the regional host such as mq.eu-west-1.amazonaws.com, and polling DescribeBroker through provisioning rather than retrying CreateBroker. Through Jentic you install once, import Amazon MQ from the API Directory, store the AWS access key once, and your agent calls it.
- **Permission scoping:** Amazon MQ puts the broker id in the URL path (/v1/brokers/{broker-id}/...), so a rule can pin your agent to one broker: it can manage that broker's users and configuration and nothing else. You choose the operations it may call, so destructive ones like DeleteBroker or DeleteUser are not included unless you add them.
- **Credential handling:** Your AWS access key is stored once, encrypted, by your own Jentic One instance and used to sign each Amazon MQ control-plane request with SigV4 at execution time. The raw secret never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create an Amazon MQ broker' or 'reboot a broker', and Jentic returns the matching MQ operation such as CreateBroker with its input schema so the agent calls the right endpoint without browsing the AWS reference.

## Related APIs

- **Amazon EventBridge** — EventBridge is AWS's serverless event bus - useful when you want managed routing rather than a JMS or AMQP broker
- **Amazon EC2** — EC2 hosts the producer and consumer applications that connect to Amazon MQ brokers
- **Amazon CloudWatch Logs** — CloudWatch Logs receives broker general and audit logs for a configured broker

## FAQ

### Why is there no official OpenAPI spec for Amazon MQ?

AWS does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Amazon MQ via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Amazon MQ API use?

The Amazon MQ control plane is signed with AWS SigV4 using IAM access keys; the broker data plane (publishing and consuming messages) uses broker-managed username/password credentials separately. Through Jentic, AWS credentials are stored in your Jentic One instance and used to sign each MQ control-plane call on the agent's behalf.

### Can I create both ActiveMQ and RabbitMQ brokers with the same API?

Yes. POST /v1/brokers accepts an EngineType of ACTIVEMQ or RABBITMQ, with engine-specific options for EngineVersion and HostInstanceType. Configuration revisions and the Users sub-resource behave slightly differently between engines, so check the returned BrokerEngineType before applying engine-specific calls.

### What are the rate limits for the Amazon MQ API?

AWS applies per-account control-plane throttling to Amazon MQ; specific TPS limits are not published in the spec. Treat throttling as expected and use exponential backoff. Broker provisioning itself takes minutes, so poll DescribeBroker rather than retrying CreateBroker.

### How do I provision a broker through Jentic?

Use the Jentic search query 'provision an ActiveMQ broker', load the operation behind POST /v1/brokers, and execute it with EngineType, EngineVersion, HostInstanceType, DeploymentMode, SubnetIds and an initial Users array. Jentic signs the request with SigV4 against your stored AWS credentials.

### Do I need to reboot a broker after updating a user?

Most ActiveMQ user updates apply on a maintenance schedule; pending changes can be applied immediately by calling POST /v1/brokers/{broker-id}/reboot. RabbitMQ user changes typically take effect without a reboot. Always check the broker's pending change set in DescribeBroker before triggering a reboot.

### Can I limit what my agent is allowed to do with the Amazon MQ API?

Yes. Because Jentic One is self-hosted, your own rules decide which Amazon MQ operations and AWS credentials the agent may use. Since the broker id sits in the URL path (/v1/brokers/{broker-id}/...), a rule can pin the agent to a single broker so it manages only that broker's users and configuration revisions and nothing else. You choose the operations it may call, so destructive ones like DeleteBroker or DeleteUser are excluded unless you add them.