I am short on time this week but hopefully some of what I share will point you in the right direction.
To confirm, fetching and saving data back to an external source on demand via an API currently isn’t possible with wikitext.
The main thing to be aware of is that in TiddlyWiki, widgets are volatile and can be destroyed and re-created as needed during the refresh process. Therefore, any long running or async tasks should not be handled by widgets that you write. Instead, the recommended approach is to send a WidgetMessage which goes up the widget tree and have a handler for your custom message in the root widget. Example code for this approach:
At this point you could let the existence of the newly created/updated tiddlers be the trigger if you only need to conditionally show or hide or update something.
If you need to trigger further actions, you want to write a change listener that checks for the changed tiddlers during each refresh cycle and when the appropriate tiddlers have been changed, triggers actions. The FileUploads plugin uses this approach, as does the core sync mechanism: tw5-file-uploads/upload-handler.js at db880c251923a0a9d9e9c2bb3d41cb7b328cd1ce · saqimtiaz/tw5-file-uploads · GitHub
A more reusable version of this approach with wikitext affordances is planned for the core but is probably yet a while away.
Alternatively, the widget message handler/listener you write could also trigger actions when the promise is resolved. Keep in mind that the context (i.e. variables that are defined) will be different when the actions are triggered compared to the context from which the widget message originated.
While it is possible to allow custom widgets to perform async tasks and trigger actions when they are completed, you risk that the widget might be destroyed before the task is complete and therefore when the promise is resolved there is no widget to handle it. I do take this approach in my WebDAV work as I prefer the syntax in the resultant wikitext and know the exact scenarios in which I intend to use it, but this very design decision is why it is not something I would publish for others to use.
Example wikitext code for fetching a file, modifying it and saving it to a different location and then triggering some actions when the tasks are successfully completed.
<$action-fetch-url $url=<<templateURL>>>
<$action-http-put $url={{{ [<currentDir>trim:suffix[/]addsuffix[/]addsuffix{$:/temp/sq/fs/new-wiki-name}] }}} $data={{{[<sq-fetched-data>addprefix<myplugin>]}}} $successActions=<<successActions>>/>
</$action-fetch-url>