Currently the Journal.AddItem API uses the DotNetNuke XSS Filter to remove potentially malicious code from posts into the journal. While this makes sens when end users might have access to a form field that goes directly posted to the journal through the API...it's prevents legitimate content from being posted through the API be a third party developer.

A specific example involves a recent attempt to post the video embed code from Ultra Video Gallery (BizModules.net) into the journal's FullText property so it would show a playable video inside the journal. (see screenshot). But, since the CSS filters are in place the code is stripped out. I have tested this using YouTube's newer sharing code which uses an IFRAME and get the same result.

This could be easily overcome with the addition of a property to the API to disable XSS protection. In this case, since the API is called from a third party module, error and malicious handling is the responsibility of that module...and since the developer has no control over this filter in the journal the results are very limited.