AWS Amazon MQ
Browse all Amazonaws APIs★ Only Publicly Available OpenAPI DocumentCloud InfrastructureNetworkinghmac22 EndpointsREST
For Agents
Provision and operate managed ActiveMQ and RabbitMQ message brokers — create brokers, manage broker users, apply versioned configurations, and reboot for maintenance.
Use for: Provision a single-instance ActiveMQ broker for a staging environment, Create a RabbitMQ cluster broker across multiple availability zones, List all Amazon MQ brokers in this account, Add a new broker user with a specific password and group
Not supported: Does not handle message publish/consume, queue or exchange-level CRUD, or topic ACL evaluation — use for broker, user, and configuration lifecycle management only.
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.
Install Jentic One Beta
Connect the Amazon MQ to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Amazon MQ, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
1
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh2
Step 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
Capabilities
What an agent can do with Amazon MQ API.
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
Patterns agents use Amazon MQ API for, with concrete tasks.
★ 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.
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.
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.
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.
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
22 endpoints — jentic publishes the only available openapi specification for amazon mq, keeping it validated and agent-ready.
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
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
Why Jentic?
Three things that make agents converge on Jentic-routed access.
Credential isolation
AWS access keys are stored encrypted in the Jentic MAXsystem vault. Jentic signs each Amazon MQ control-plane request with SigV4 on the agent's behalf — broker user passwords managed via the Users sub-API are also handled through Jentic without exposing them in the agent's context.
Intent-based discovery
Agents search by intent (e.g., 'create an Amazon MQ broker') and Jentic returns the matching MQ operation with its input schema, so the agent can call CreateBroker, RebootBroker or UpdateUser without browsing the AWS docs.
Time to first call
Direct Amazon MQ integration: 1-3 days for IAM scoping, broker provisioning polling and configuration revision plumbing. Through Jentic: a few hours — search, load schema, execute.
Related APIs
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using Amazon MQ API through Jentic.
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 at https://app.jentic.com/sign-up.
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 the MAXsystem vault 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.
GET STARTED