Keith is pretty much spot on.
The API is Event Driven, the only way to interact with it is to cause some event which it listens for and responds to. The most common event for it to respond to is the chat event. Any chat message causes an event, but usually an API command is used for making an explicit request of an API script. There is not some way of making a direct function call or anything. (You can think of API command messages as a poor man’s Remote Procedure Call (RPC), if you’re familiar with that.)
Interacting with an API script is purely forward, it does not return any values (as you can’t call it directly so there’s be nothing to return it to or from). API scripts can only change the general state of the game, and allow those state changes to propagate to all the clients. The API is asynchronous. Everything in a Macro/Ability/Chat Command gets fully evaluated in the client before the API even sees it. That’s all inline rolls, all roll queries, all macro and ability references, etc. the API will see the data from these (what was rolled, how it was modified by options, which roll template is being used, etc.), but the evaluation has taken place. Any sort of back and forth dialogue between the macro and the API will need to take place across multiple events. Often it’s easier to just implement the logic in the API script and use the macro for gathering the initial input. For really complicated things, having the API whisper further queries to the user that caused the event and continue with their answers is the best way to go.