fix: allow string form_data in CustomWebhookNotificationBlock

[zzstoatzz]

Summary

• Enables form_data to accept strings for raw body content, not just dicts for form-encoded data
• Uses httpx content= for strings (raw body) and data= for dicts (form-encoded)
• Enables forwarding pre-constructed JSON from automation bodies to external webhooks

Use case: When an automation triggers and renders JSON in the body field (using Jinja with event data), users can now forward that JSON as-is to external APIs like Datadog:

CustomWebhookNotificationBlock(
    name="datadog-events",
    url="https://api.datadoghq.com/api/v1/events",
    form_data="{{body}}",  # forwards the automation's JSON body as-is
    headers={"Content-Type": "application/json", "DD-API-KEY": "{{api_key}}"},
    secrets={"api_key": "..."},
)

Closes #19949

Test plan

• Added test_string_form_data test
• All existing TestCustomWebhook tests pass (11/11)

Reproduction script

from prefect.blocks.notifications import CustomWebhookNotificationBlock

# Simulate automation passing JSON as the body
automation_body = '{"flow_name": "my-etl-flow", "state": "Failed", "run_id": "abc123"}'

block = CustomWebhookNotificationBlock(
    name="datadog",
    url="https://httpbin.org/post",
    form_data="{{body}}",
    headers={"Content-Type": "application/json"},
)

args = block._build_request_args(automation_body, None)
print(args.get('content'))  # {"flow_name": "my-etl-flow", "state": "Failed", "run_id": "abc123"}

🤖 Generated with Claude Code

[codspeed-hq]

CodSpeed Performance Report

Merging #19953 will not alter performance

_{Comparing fix-custom-webhook-string-form-data (7eff69a) with main (5f83d24)}

Summary

✅ 2 untouched

[jbw-vtl]

Thank you very much for the rapid turnaround, this looks good to me.

We are fairly advanced in our prefect integrations with datadog, keen to eventually feedback things either to core or as a prefect-datadog integration.

Couple of things we have changed

• Have prefect server, worker and jobs log json formatted logs, with us having highjacked the dictConfig, then using a sidecar container picking up logs and sending to datadog. This was very successful in copying the logging approach used for internal services to our job orchestration.
• Tracing server, worker and job execution using ddtrace-run. So far not gone very far here, merely changing the image being run to include required dependencies and changed startup command. This lets us collect traces of e.g. web requests done within flows & debug database performance of the perfect server. We are keen to emit spans for each flow & task executions and should be able to leverage the existing otel integrations. More investigation required however

Others we are planning

• Emit datadog events whenever a flow run changes, being able to create a central dashboard in datadog to view flow success / failure etc across all our clusters. This is what we are aiming to use the above change for
• Integrate datadog API tests to run custom health checks against prefect, such as being able to query pending deployments etc
• Lastly cataloging the jobs from prefect centrally, collecting metadata about each job (description, team owning and criticality as tags within a single place, likely datadog)

[zzstoatzz]

hi @jbw-vtl - thanks for the context there! would you be willing to open a discussion where we can float different ideas for prefect/datadog integration and then break well-scoped issues out of that discussion?