sendChat with a `@{target|}` prompt in it?

I'm trying to write a script that eventually prompts the user to select a token. Specifics aren't that important; I've already found a workaround, now I just want to understand how the API works :) Simplified version: on("chat:message", msg => {       const [cmd, args] = msg.content.split(" "); log({cmd});       switch (cmd.toLowerCase()) {         case '!input': { // if content is unescaped i get this error: // "ERROR: Unable to find character target in chat command."             sendChat(msg.who, `!output ${escape("@{target|token_id}")}`);             break;         }         case '!output': {             log({args}); break;         }       }   }) Console output: {"cmd":"!input"} {"cmd":"!output"} {"args":"@{target|token_id}"} So it looks like messages delivered via API aren't interpreted in quite the same way as they are via the chat box. For the record, my current workaround is to return a button with a macro: "[select token](!
#run-output)" But I'm specifically asking if there's a way to eliminate the additional button click. Is there a way to accomplish this?

There isn't a way to eliminate the extra button click.  The API doesn't have a way to access the UI in a client without user interaction.  This is pretty much the method I use, if I need to prompt a player mid API command.  I'll often store the state of the current command in a lookup with a unique identifier, then include that identifier in an API Command Button so I can resume the operation when they provide input.  You can see an example of that workflow in the "Push" functionality in my MutantYearZero script. Just a little more detail, the @{target} and ?{selected} references prompt the current player for input.  At the time that they are output by the API, the current player is "api", which can't respond to them.

> At the time that they are output by the API, the current player is "api", which can't respond to them. Ah, that was the concept I was missing. Thanks so much!

Cool!  No problem.  Something else to consider is that the API Sandbox is like its own client running on a server off in the cloud.  It doesn't actually have a display, and just sees the events that come in from other clients.

Nice.  This is almost exactly the problem I was running into - any API 'chat' calls were just getting swallowed up. I'm trying to write an API that needs (selected, target, Modifiers from the player, Modifiers from the GM (unknown to the player). So, from your guy's exchange - it be best to start it with those on the chat command line and pass those as parameters to the API function: e.g. (pseudo coded) !doThing (/w gm ?{Defender Modifiers +/-|0}) @{selected|token_id} @{target|token_id} ?{Attack Modifiers +/-|0} Then just have everyone create a macro for the above command.

Yeah, basically.   One thing to be aware of is that when you use @{target} anywhere in a chat message (multi-line included) with an API command, the api will not receive the msg.selected array.  You're on the right track by passing @{selected}.  In your case, if the GM needs to add modifiers the players are not aware of, you'll either want to have the GM initiate the command by providing the modifies to the API, which then sends a request to the player, or the other way around.

Darn, I was hoping the "(/w gm ?{xxxxx})" would force an Synchronous call to the GM, where the chat variables are all evaluated prior to passing to the API. @{target} does seem to be getting evaluated correctly.  (at least I'm getting 2 different token ids in my debug, haven't dug too much deeper yet) It seems using your guy's button trick and making it a multi step API is the way to go.  It's a good idea, then I can put enough context in the button text to make sure the GM is putting in the correct modifiers. e.g. !doPlayerThing ?{Player modifiers} @{selected} @{target} which then sends a chat button to the GM that does !doGMResponse ?{GM Modifiers} info from the player calls - which then does the final calculations Thanks for all the help!

You've got it!  Take a look at MutantYearZero's handling of Push for an example of deferred operations. Tagmar has a similar case, though it's more automatic (getting 3d dice in an api roll).