Request a new API key
https://firewall/api/?type=keygen&user=<user>&password=<password>
curl -k -X POST 'https://firewall/api/?type=keygen&user=<user>&password=<password>'
================
PAN-OS XML API vs REST API
Both are officially supported ways to automate Palo Alto Networks firewalls and Panorama — they're not a case of one replacing the other, but they cover different needs.
XML API
- Older, low-level interface based on a tree of XML nodes that mirrors the firewall's internal config structure.
- You target settings/actions using XPath to navigate that hierarchy.
- Essentially exposes everything the CLI/GUI can do — it's powerful and low-level, giving full control over every aspect of the device and enabling deep custom integrations.
- Covers areas REST still doesn't: commit operations, User-ID mapping, dynamic/predefined/custom reports, log retrieval, export operations (packet captures, config, tech support files, certificates), and generating an API key.
- Can be called directly against a firewall, directly against Panorama, or against a firewall via Panorama.
- Verbose, requires understanding XPath, steeper learning curve.
REST API
- Newer, resource-oriented API following typical REST conventions.
- Simplifies access to resources as high-level URIs, and is used for CRUD (Create/Read/Update/Delete) operations on objects and policies, accessible directly on a firewall or centrally via Panorama.
- Requests and responses default to JSON but also support XML — much easier to work with than raw XML for most modern tooling/scripting.
- Cleaner, more intuitive, better fit for typical automation/DevOps/CI pipelines and general object/policy management.
- Limitation: it doesn't do everything — notably, after configuring via REST you still need the XML API (or GUI/CLI) to commit changes to the running config. It also doesn't cover reporting, User-ID, or log queries.
Practical takeaway
| Need | Use |
|---|---|
| Create/update/delete address objects, security rules, zones, NAT rules, etc. | REST API |
| Commit configuration changes | XML API |
| User-ID mapping (login/logout events) | XML API |
| Pull logs/reports (traffic, threat, custom reports) | XML API |
| Export files (configs, certs, packet captures, tech support) | XML API |
| General third-party integration / simple scripting | REST API (easier syntax) |
| Full/legacy control over any device feature | XML API |
In practice, most current automation projects lean on the REST API for object/policy management and fall back to the XML API for commits, User-ID, and reporting/log pulls — many scripts and SDKs (like pan-os-python) call both under the hood.
If you tell me what you're actually trying to build (e.g., dynamic address group updates, User-ID sync, log pulling, CI/CD policy pushes), I can point you to the exact endpoints/methods you'd want.
=================
The keys are not "generated" and thus not saved. The key a hash function of the account username, password and time/date of generation (and this is the reason you get different key every time).
The key lifetime was introduced in PanOS9. Before 9, the API key was only a function of the username and password and you used to get the same every time you "generate" it.
So when you send the key to firewall, it user its algorithm to convert it to the date/time of generation, username and password. If the time is within you API configured lifetime, then the username and password will be used for authentication. If not or if you changed the password, then authentication will fail.
Comments
Post a Comment