I've set up the Trend Micro Cloud One -> ServiceNow integration for incident creation three times now. It's failing silently on our end, and the vendor docs are useless. The incidents either don't post to ServiceNow, or they create with empty fields.
Here's our current webhook config from the Trend Micro console:
```json
{
"url": "https://ourinstance.service-now.com/api/now/v1/table/incident",
"auth": "basic",
"username": "integration_user",
"password": "********",
"headers": {
"Content-Type": "application/json"
},
"body": "{"short_description": "{{AlertTitle}}", "description": "{{FindingsURL}}"}"
}
```
The test alert from Trend Micro succeeds (returns 201), but the created ServiceNow incident has a null `short_description` and `description`. The raw findings data shows those templated variables *should* be populated.
Has anyone:
* Got this mapping actually working?
* Found the correct payload body syntax?
* Switched to using a ServiceNow Integration Hub spoke instead?
Need to know what fields Trend Micro actually sends versus what they claim they send. Logs on their side are non-existent.
Metrics don't lie.
Classic vendor templating nonsense. Your JSON body string is malformed - you've got double quotes inside double quotes, so `{{AlertTitle}}` is probably being sent as a literal string. The platform likely escapes it weirdly or just drops it.
Try this for the body field:
```json
"body": "{"short_description": "{{AlertTitle}}", "description": "{{FindingsURL}}"}"
```
But honestly, I'd bet their template variables don't even match the actual payload. I ran a proxy capture on a similar integration last month and found the actual field names were `alert_title` (lowercase) and `findings_url`. No docs mentioned it. 🙄
If that doesn't work, you're stuck enabling debug logging on a middleware proxy or using the Integration Hub spoke, which is more stable but adds latency.
Yep, you're right on the money with the malformed JSON. The original config is definitely sending a raw string with curly braces, not parsed JSON.
> try this for the body field
But I think you meant to escape the quotes differently? Your suggestion looks identical to the OP's. In my experience, you'd need to use single quotes for the outer wrapper or escape the inner doubles, but the Trend console might not even allow that syntax.
Your point about the actual field names being lowercase is the real killer. I had the same with a Qualys integration, their docs said `ScanName` but the payload was `scan_name`. A quick test with a simple webhook logger showed it instantly.
Yeah, the JSON is broken. The console's probably treating the body field as a raw string, so you need proper escaping. This is what's worked for me in similar platforms:
```json
"body": "{"short_description": "{{AlertTitle}}", "description": "{{FindingsURL}}"}"
```
But honestly, `user364`'s guess about the actual variable names being different is spot on. The test might succeed because it's just validating the request structure, not checking if the template tags resolve. If you can't get a proxy log, maybe route the webhook through a free tier of Zapier or Make first to see the raw payload from Trend Micro. That'll show you the real keys.
Webhooks or bust.
You're hitting two distinct but common integration failure modes: template variable mismatch and JSON serialization ambiguity. The 201 response with null fields confirms ServiceNow is receiving something structurally valid, but the templated values aren't resolving.
First, validate the actual payload keys from Trend Micro. The vendor's documentation is frequently wrong. Use a temporary webhook endpoint from a service like webhook.site or a simple Flask app on a cloud instance to capture the exact JSON structure Trend Micro sends. I'd bet the keys are snake_case or camelCase, not TitleCase. The test alert often uses a different, hard-coded payload.
Second, regarding the JSON body syntax, the console likely expects a JSON string for the body field, meaning you need proper escaping. The correct JSON value should be:
```json
"body": "{"short_description": "{{AlertTitle}}", "description": "{{FindingsURL}}"}"
```
But if the console's UI doesn't accept escaped quotes, try defining the body as a raw JSON object instead of a string, if the platform allows it. Sometimes these configs accept a JSON object directly, not a stringified JSON string.
If you're stuck, the Integration Hub spoke is more reliable but introduces measurable latency, typically 300-500ms extra. That's often an acceptable trade-off for guaranteed field mapping.
numbers don't lie