As described earlier, the lwIP sequential API provides a straightforward and easy-to-use method of interfacing to the stack. Unlike the raw API, which requires event-driven callbacks, an application can simply call the API functions as needed to perform stack operations such as sending data, receiving data, or manipulating packet buffers or connections. While the raw API may allow for more efficient operation, the sequential API typically allows for simpler application design.

In design, it is not unlike the BSD sockets API. Some of the terminology differs however: in the sequential API, the term connection is used for any communication link between network peers, and the handle for a connection is termed a netconn. A netconn can be considered analogous to a socket, albeit specific to networking - BSD sockets traditionally represent both network connections and files.

The main reason for superiority over the socket API occurs with buffer management. The BSD socket API was designed to manage the fact that the user and the operating system kernel operate in different address spaces and data must always be copied regardless. This results in not only decreased performance, but also increased footprint as buffers must be allocated to hold the copied data.

Instead of the BSD approach of generic buffers, the sequential API uses netbufs, which are based on pbufs. This allows users to manage buffers directly, including even allowing data to come from ROM. Since pbufs, and hence netbufs, can be chained, this also allows the application and lwIP to avoid the need for large regions of entirely contiguous memory in order to hold data. Instead data can be constructed in chunks, and chained together.

When the application wishes to send data, it can send a netbuf directly with UDP. TCP is different as it is intrinsically a buffering, streaming protocol, which requires data to be kept aside to allow for retransmissions. As a result data is sent using just a pointer to memory and a length. However since TCP data can also reside in ROM, it is possible to indicate that the data does not need copying, and so will persist even if the stack needs to queue the data. This can lead to huge savings of memory. For example, static web page content can reside in ROM, and never need to be copied to RAM.

For both TCP and UDP, incoming data is passed to the application as netbufs. The application can use API functions to extract the data from the netbufs - care must be taken as the received data may in fact be a chain. A convenience function exists to copy out the entirety of data across the whole chain into a single contiguous region of memory. Otherwise the application can process data in each netbuf in the chain in turn. The functions netbuf_first() and netbuf_next() can be used to iterate throught the chain.

When interacting with the network stack using the sequential API, all operations are not handled by the calling thread, but instead are passed to the lwIP network processing (TCP/IP) thread. Inter-thread communication is used inside lwIP to ensure that at the point the API function returns, operation is either complete, or for asynchronous operations, under way.

For example, to register a timeout callback the tcpip_timeout() function can be used from client threads to cross the thread boundary into the sequential TCP/IP thread. However, since the actual timeout callback handler registered will be executed within the sequential TCP/IP thread context, it can subsequently directly call the lwIP internal sys_timeout() if it needs to re-schedule its callback.