apstra-api-python

The problem no one was solving

Apstra had API libraries. Engineering had built them — sophisticated, dynamically generated clients tightly integrated with the product internals. Exactly what you’d expect from a platform team moving fast.

They were also completely inaccessible to anyone outside that team.

That wasn’t an engineering failure. The internal libraries weren’t meant for customers. They were built for Apstra, by Apstra engineers, to serve Apstra’s development workflow. They weren’t documented for outsiders. They assumed context that only came from working inside the codebase. And they exposed a level of complexity that would have been overwhelming even to experienced API consumers.

The customers trying to use them were not experienced API consumers.

Who the customers actually were

Apstra sold to network engineers running enterprise datacenters. These were often highly credentialed, deeply experienced professionals — people who could architect and troubleshoot networks most engineers will never encounter in their careers. CCIEs. Veterans of Cisco, Juniper, Arista environments.

But the craft they’d mastered was CLI-native. show interfaces. configure terminal. The mental model was imperative and sequential. You connected to a device. You issued commands. You read the output. You did it again.

REST APIs don’t work that way. The concept of a stateless request-response cycle, of authentication tokens, of HTTP verbs as semantic actions, of JSON payloads as structured data — none of this mapped intuitively onto what network engineers had spent their careers doing. It wasn’t a gap in intelligence. It was a gap in exposure.

And on top of that gap sat Apstra’s API — which was, to be generous, not designed for newcomers.

What made Apstra’s API hard

Apstra was intent-based networking software. The API reflected that: you weren’t configuring individual interfaces or routes, you were describing intent across blueprints, design nodes, resources, and logical devices. The abstractions were deep and the relationships between objects were non-obvious.

Even for someone comfortable with REST APIs in general, Apstra’s surface required significant time investment to understand. For a network engineer making their first serious attempt at programmatic infrastructure work, it was a wall.

Where it came from

While building CloudLabs, I needed direct integration with the Apstra API — the platform had to be able to configure network topologies, manage lab environments, and interact with Apstra’s intent layer programmatically. So I built a client. It lived inside the CloudLabs codebase, proved itself in production, and did what it needed to do.

That internal code became the seed of apstra-api-python.

I extracted it from CloudLabs, stripped out the parts that were specific to our internal systems, and rebuilt it as something a customer could actually pick up and use. The transformation wasn’t just technical — it was a rethink of who the code was written for. Internal tools carry context in the heads of the people who built them. A public library has to carry its own context.

Where I fit

I’d made the crossing myself. CCIE in Routing and Switching, years at PNC Bank as a network engineer before I ever wrote production Python code. I knew what it felt like to stare at an API reference and not have the vocabulary to understand it. I knew how to read a show bgp neighbors output cold and how lost a REST response body can make you feel when the mental model isn’t there yet.

At Apstra, I was the bridge between the engineering team and the field — sales engineers, professional services, and the customers themselves. That position gave me a clear view of the gap: customers needed to automate complex Apstra workflows, the tools Apstra had internally weren’t the right tools for them, and nobody was building what they actually needed.

What the library actually is

apstra-api-python is a Python client for the Apstra REST API, built to be learned from as much as used.

Everything — the code structure, the documentation, the usage examples — was built around one goal: helping non-programmers get good at this stuff. Not just hand them a working tool, but actually close the gap between where they were and where they needed to be.

The design priorities weren’t typical open source library priorities. I wasn’t optimizing for performance or feature completeness. I was optimizing for readability — for a network engineer who had just started learning Python to be able to open the source code and understand what was happening and why.

That meant:

• Explicit over clever. No dynamic generation, no magic. Every method does one clear thing.
• Verbose authentication. The session lifecycle is handled, but the code shows you what’s happening — tokens, headers, session state — so the concepts land, not just the convenience.
• Error messages for humans. Specifically, for network engineers who might not yet know what a 401 or a 403 means in context.
• Documentation written for people learning, not people who already know. Usage guides built around real Apstra workflows — blueprint management, device registration, resource allocation — so there was a direct line from “I need to do X” to working, understandable code.

The outcome

The library became the on-ramp for network engineers integrating with Apstra. It survived the Apstra → Juniper acquisition and stayed in active use. It’s been cited in blog posts, customer implementations, and internal tooling.

More than the usage numbers, what mattered was the crossing. Engineers who started with apstra-api-python as their first real API integration work came out the other side with the mental model. The library did its job — not just as a tool, but as a teacher.

Open source on GitHub. The CloudLabs platform that seeded this library has its own case study.