If you follow where I’m going with the Universal Webhook idea … you will only need the WebhookAPI NameID and the prompt. The WebhookAPI record has all the info related to it, including MIME type, so you would already know that it is an image that you are expecting.
[Webhook API NameID: prompt ]
If you want or need to specify image for your internal programming purposes, then you can put the type before it:
[text|Webhook API NameID: prompt ]
or
[img-src-base64|Webhook API NameID: prompt ]
but the user would have already indicated the Mime-type in the Webhook/API record, so indicating it here might seem repetitive and unnecessary. However, it still might be a good idea to specify [img-src-base64|APIname…] considering an image-src base64 could theoretically be returned inside of a JSON string … no? This way they can specify the MIME type here in case it is different than what the payload MIME type is. This should be as flexible as possible.
If you read my latest comment on the Allow Inline thread … this also solves that issue you brought up as well with having too many parameters.
Just make sure the Webhook system has can read/write to all the User’s %macro variables%. Problem solved.
PS: A Universal Webhook idea, makes SCM extremely flexible and allows it to work not just with AI, but just about any data source on the web. And it eliminates the need for you having to program for every future API on the planet. The more I think about it, the more sense it’s making to include a Universal Webhook API feature.