Can a monolithic architecture provide more than one API?
Yes. An API is a interface for defining the interactions between multiple components, modules, systems, etc. The way you expose this API is separate from how it is implemented. Having a monolith doesn’t mean you expose just one API, it means that everything is built as a single, all in one solution. So one of the problem is this: if you expose two APIs from your monolith, and you make changes to one of them, when you deploy, you have to deploy the other one also because you have everything inside the same application. In a microservice architecture, you will have the APIs separated because that’s the point, and you can deploy them separately.
is running multiple processes/services still considered monolithic as long as the codebase is the same and is shipped as “one unit”?
Yes. If everything is built on the same code base, using the same platform, framework, etc, and deployed as one unit, it is still a monolith. Even if you have things defined in processes or services, if you make a change to one of them, you have to deploy everything. So basically, everything is impacted by your change in just one part of the monolith.
Just as an aside, even though you can build your monolith with multiple processes and services and keep the decoupled and without shared responsibilities, that’s not what usually happens. Because you have everything in one place, things tend to leak from one process/service to the other and you can easily end up with one tightly coupled mess of a code base.
Does using a monolithic architecture for your web application expose its backend services? Or is it possible for a monolith to provide the web app and another API as a gateway to the internal services?
How you expose your backend services or provide APIs is your choice. This choice and having a monolith are orthogonal issues.