Thank you for your interest in Ansible Tower. Ansible Tower is a commercial offering that helps teams manage complex multi-tier deployments by adding control, knowledge, and delegation to Ansible-powered environments.
The Ansible Tower API Guide focuses on helping you understand the Ansible Tower API. This document has been updated to include information for the latest release of Ansible Tower v3.8.0.
We Need Feedback!
If you spot a typo in this documentation, or if you have thought of a way to make this manual better, we would love to hear from you! Please send an email to: firstname.lastname@example.org
If you have a suggestion, try to be as specific as possible when describing it. If you have found an error, please include the manual’s title, chapter number/section number, and some of the surrounding text so we can find it easily. We may not be able to respond to every message sent to us, but you can be sure that we will be reading them all!
Ansible Tower Version 3.8.0; November 18, 2020; https://access.redhat.com/
Ansible, Ansible Tower, Red Hat, and Red Hat Enterprise Linux are trademarks of Red Hat, Inc., registered in the United States and other countries.
If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original version.
Third Party Rights
Ubuntu and Canonical are registered trademarks of Canonical Ltd.
The CentOS Project is copyright protected. The CentOS Marks are trademarks of Red Hat, Inc. (“Red Hat”).
Microsoft, Windows, Windows Azure, and Internet Explore are trademarks of Microsoft, Inc.
VMware is a registered trademark or trademark of VMware, Inc.
Rackspace trademarks, service marks, logos and domain names are either common-law trademarks/service marks or registered trademarks/service marks of Rackspace US, Inc., or its subsidiaries, and are protected by trademark and other laws in the United States and other countries.
Amazon Web Services”, “AWS”, “Amazon EC2”, and “EC2”, are trademarks of Amazon Web Services, Inc. or its affiliates.
OpenStack™ and OpenStack logo are trademarks of OpenStack, LLC.
Chrome™ and Google Compute Engine™ service registered trademarks of Google Inc.
Safari® is a registered trademark of Apple, Inc.
Firefox® is a registered trademark of the Mozilla Foundation.
All other trademarks are the property of their respective owners.
This document offers a basic understanding of the REST API used by Ansible Tower.
REST stands for Representational State Transfer and is sometimes spelled as “ReST”. It relies on a stateless, client-server, and cacheable communications protocol, usually the HTTP protocol.
You may find it helpful to see which API calls Tower makes in sequence. To do this, you can use the UI from Firebug or Chrome with developer plugins.
Another alternative is Charles Proxy (http://www.charlesproxy.com/), which offers a visualizer that you may find helpful. While it is commercial software, it can insert itself as an OS X proxy, for example, and intercept both requests from web browsers as well as curl and other API consumers.
Other alternatives include:
Live HTTP headers FireFox extension (https://addons.mozilla.org/en-US/firefox/addon/live-http-headers/)
REST APIs provide access to resources (data entities) via URI paths. You can visit the Ansible Tower REST API in a web browser at:
http://<Tower server name>/api/
Ansible Tower 3.2 introduced version 2 of the API, which can be accessed by clicking the v2 link next to “available versions”:
Alternatively, you can still access version 1 of the API this way, but it will be removed in a future release of Ansible Tower.
If you perform a GET just the
/api/ endpoint, it gives the
current_version, which would be the recommended version.
Clicking on various links in the API allows you to explore related resources.
Clicking on the next to the page name (toward the top of the screen) for an API endpoint gives you documentation on the access methods for that particular API endpoint and what data is returned when using those methods.
You can also use PUT and POST verbs on the specific API pages by formatting JSON in the various text fields.
You can also view changed settings from factory defaults at
/api/v2/settings/changed/ endpoint. It reflects changes you made in the API browser, not changed settings that come from static settings files.