However, what I don't understand is how APIs are called. In other words, in a real-world scenario, people don't actually type in a URL in some input box to call APIs, so I assume the calling is done behind the scenes, by some program, and in response to some trigger event?
For a web-api, there will typically be two parts.
One part of the program will be a library, that knows how to construct HTTP requests out of some provided hints, how to address that request so that it can be delivered to another machine on the network, how to listen to messages from the network and reconstruct the HTTP responses from them, and how to parse the response to extract useful information from it.
Very broadly, these are called http client libraries. A "web browser", for example, will have some sort of http client library, as well as a bunch of code for rendering the results, processing actions by the user, keeping track of bookmarks and preferences, and so on.
The second part of the program will know the API, which is to say the semantics of the messages that should be sent and read, without necessarily knowing how to create the messages. So it will "know" what URI(s) to use, or how to create them from a template and a list of parameters, and what information should go in the body of the message, and which links to look for in the response.
If my assumption is true, is it also true that when using a client like Postman to test APIs, you are basically emulating the behavior of said program?
Right - using a http client will allow you the human being to tell the client to interact with the API on your behalf (you being a replacement for the "second part" of the program).
when an API is implemented/deployed, where does the code reside?
Usually, the code that implements the API is running within the web server process itself. It looks like the client case, but mirrored -- the generic http server framework will call into the library that implements the interface.