the northbound API
Keep the same whiteboard stack in mind: applications on top, controller in the middle, switches at the bottom. If southbound points down to the hardware, northbound points up to the software that wants to use the network. The northbound API is the interface the controller offers to control applications — routing, load balancing, security, monitoring — so they can ask for what they want without touching switches directly. It is the network's programming interface for software developers.
Concretely, the northbound API lets an application express high-level desires and read high-level state. Rather than installing flow rules itself, an app might say give host A a path to host B, or block all traffic from this subnet, or report which links are congested. The controller takes that request, consults its global view, computes the concrete flow rules, and installs them downward via the southbound API. Northbound interfaces are usually friendly to programmers — commonly REST APIs over HTTP, or language libraries — and they speak in network abstractions (hosts, paths, policies) rather than in ports and counters.
Why it matters: the northbound API is where SDN's promise of a programmable network actually reaches people who write software, and it is the foundation for intent-based networking, where you state goals and let the controller work out the mechanics. The honest reality is that, unlike OpenFlow on the southbound side, the northbound side has never had one dominant standard — different controllers expose different APIs — which makes applications less portable across controllers. So north is the easy, high-level side to program against, but it is also the less standardized one.
A monitoring app makes a simple REST call to the controller's northbound API: GET /links, and receives a JSON list of every link with its current utilization. Seeing one link at 95 percent, the app then POSTs a request to reroute a big flow away from it. The app never spoke OpenFlow or touched a switch — it worked entirely through the friendly northbound interface.
Apps talk to the network in high-level terms; the controller does the low-level work below.
There is no single agreed northbound standard the way OpenFlow standardized the southbound side, so applications written for one controller's northbound API often need rework to run on another.