After the first couple of Sprints, a Scrum product should always be a in a potentially-releasable state. That inherently means there's always something to demonstrate at a Sprint Demo, but you may need to be creative and "think outside the box" to find it. Treat demos as first-class work products during Sprint Planning in order to make demonstrations easier and more intuitive to develop.
APIs and Middleware Aren't Magical Unicorns
What happens in an agile project when the nature of the software being built simply doesn't have a previous version to be built upon and thus cannot deliver a successive, usable version? For example, software layers in a mobile phone which have no 'phone' to be a part of yet and which most likely do not involve user input and simply provide a service to other units of functionality.
This is a common misunderstanding of what "iterative" or "incremental" mean in an agile context. It in no way means you must have a prior version of the software; it means that future versions can (and generally should) build upon the work that's gone before. Agile projects benefit greatly from emergent design, and agile frameworks optimize for that.
APIs and middleware can grow and evolve in small, testable increments in the same way as any other software can, so there's nothing orthogonal to INVEST in such systems. APIs and middleware can be versioned, modified, and extended in much the same way as more traditional software, too.
There's nothing inherent to APIs or middleware that prevents them from being kept in a potentially-releasable state or being demonstrable. Such systems should still do something, and if you can test it then you can demonstrate it.
Demonstrating Non-Graphical Whosiwhatsits
Having said all that, what seems to flummox many people is the difficulty in demonstrating new functionality in a product that doesn't lend itself easily to visual presentations. Doing so often requires a bit more creativity and agile testing experience than many shops have when they start their agile journeys. Some common solutions include:
Using executable tests for the demonstration.
Cucumber is a great example of this. Seeing well-written tests (and hence behavior-describing documentation) go green is a perfectly valid demonstration for many types of software.
Leveraging your development or QA testing harness for demonstrations.
Almost any brand of TDD/BDD or continuous integration will require some level of test abstraction. Mocks, stubs, fixtures, and factories often stand in for other pieces of the "real" architecture, even in integration tests. There's nothing stopping you from using such techniques to stub out the functionality of API or middleware clients in your Sprint Demos.
Build a "demo client."
The point is to show your product doing something. If you can't show it in situ, you can at least create a mock-up or simulator showing how an API or middleware client would interact with your code. Demo that interaction!
Documentation, pie charts, and other visual aids.
The Sprint Demo is intended to show progress, and to solicit stakeholder feedback to feed into future Sprints. While all abstractions are leaky, if you genuinely can't envision any other way to demonstrate your increment of work you can always leverage secondary artifacts. Walk people through code, commit history, living API documentation like Swagger, or other things which provide a valid view of the product's current state.
Scrum mandates that work increments be demonstrated, but isn't prescriptive about how the demonstrations need to be done. There's no mandate that a demo must require a keyboard or a graphical interface. If it's relevant to the product, skywriting or interpretive dance could be just as legitimate for the demonstration.
The framework's goal is to avoid traditional status reporting, and to give stakeholders "more show, less tell." If the team can't find a way to demonstrate the work increment, I daresay they will have a very hard time testing it, too.
Plan Demos During Planning
TDD/BDD frameworks work best when you design the tests first, rather than writing your tests post facto; it makes testing easier, and ensures the product is built to be tested ab initio. Sprint Demos are no different. During Sprint Planning, the team should factor how they plan to demo the work into their user stories and estimates on the front end rather than the back.
Sometimes planning around demonstrations may change how you slice up stories, or how you plan or estimate the work. If so, great! That means you're leveraging the framework.
Treat demos as first-class work products, not afterthoughts. When you reframe the work this way, the best way to demonstrate the work increments usually becomes self-evident.