What is the difference between using Burp’s older extender API and the Montoya API for extension development?

The older extender API is more rigid and often requires more manual handling for tasks such as parsing message bodies or adding support for newer features. The Montoya API is designed to be more object-oriented, easier to use, and better aligned with modern extension development. It also exposes capabilities such as WebSocket support and simpler access to HTTP message contents.

Why Burp’s Extension Model Changed

The difference is mainly architectural. Burp’s older extender API gives you lower-level primitives and more manual work, which can make simple tasks feel fragmented as an extension grows. Montoya is the newer, higher-level model: it is designed around cleaner objects, clearer flows, and less boilerplate, so common extension tasks are easier to express and maintain.

That shift matters most when you are building beyond a one-off proof of concept. The older API can still do the job, but Montoya usually reduces the amount of glue code you need for request/response handling, message parsing, and feature adoption as Burp evolves.

What You Gain with Montoya

Montoya’s main advantage is developer ergonomics. It exposes HTTP message contents in a more direct way, which reduces the need to manually decode or reconstruct data before inspection and modification. It also gives you better support for newer protocol features, including WebSocket workflows, without forcing you to build those abstractions yourself.

That tends to make extensions easier to read and easier to extend. For teams maintaining security tooling over time, the difference is not just convenience, it is also lower maintenance cost and less risk of brittle parsing logic when Burp or the underlying traffic model changes.

Montoya is also the better fit when you want extension code to feel like a modern SDK rather than a collection of callbacks and utility methods. If your extension needs to inspect traffic, transform messages, or support multiple protocol surfaces, the higher-level object model usually shortens the path from idea to working feature.

When the Older Extender API Still Makes Sense

The older extender API is not obsolete in the sense of being unusable. It remains relevant when you already have legacy extensions, existing codebases, or a narrow workflow that has not justified migration. In those cases, the cost of rewriting may be higher than the benefit if the extension is stable and simple.

The trade-off is flexibility versus developer experience. The older API can feel closer to the raw mechanics of Burp, which may suit maintainers who know it well, but it often asks more of the developer when handling message bodies, adapting to newer features, or keeping code tidy as the extension grows.

For new development, that usually means Montoya is the default recommendation unless you have a specific dependency on legacy extender behavior. For existing extensions, the practical question is whether the code is merely functioning or whether maintainability and feature coverage are becoming a burden.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP ASVS	V15 — Secure Coding and Architecture	Extension API choice affects code structure and maintainability for security tooling.
Recommendation — Prefer the cleaner API to reduce brittle parsing and maintenance burden in extension code.
NIST SP 800-53 Rev 5	SA-11 — Developer Testing and Evaluation	Extension development benefits from stronger testability and maintainable interfaces.
Recommendation — Use the newer API to simplify verification and reduce manual handling errors.
CIS Controls v8	CIS-16 — Application Software Security	Security extensions are application code and should be maintainable and robust.
Recommendation — Standardize on the modern API for easier upkeep of security tooling.

Practitioner Guidance

What to verify: Choose Montoya if the extension needs to work with modern Burp capabilities, clearer HTTP message access, or WebSocket handling. Keep the older API only when migration cost is high and the extension scope is stable enough that the extra manual handling will not become a maintenance problem.

Decision rule: If you are starting a new extension, build on Montoya unless you have a hard compatibility reason not to. If you are maintaining an older extension, assess whether the real constraint is feature support, developer time, or simply inertia, because that determines whether a rewrite is justified.

Practitioner takeaway: The key difference is not just syntax, it is the level of abstraction. Montoya is the better long-term choice for most new work, while the older extender API is mainly a legacy fit when existing code or constraints outweigh the benefits of modernization.