Summary
Edit-FalconScript and Send-FalconScript currently use the v1 RTR scripts endpoint and do not expose the workflow_input_schema or workflow_output_schema fields available on the v2 endpoint. This means there is no native PSFalcon way to attach input/output schemas to custom RTR scripts — a capability the Falcon API supports today.
Notably, Get-FalconScript already uses the v2 endpoint (/real-time-response/entities/scripts/v2:get) when retrieving scripts by ID, so v2 is already partially represented in PSFalcon. Making the write-side commands consistent with this would complete the CRUD surface at v2.
Current Behavior
| Command |
Endpoint |
Schema support |
Send-FalconScript |
/real-time-response/entities/scripts/v1:post |
❌ |
Edit-FalconScript |
/real-time-response/entities/scripts/v1:patch |
❌ |
Get-FalconScript |
/real-time-response/entities/scripts/v2:get |
✅ (returns fields) |
The v2 PATCH endpoint (/real-time-response/entities/scripts/v2) accepts workflow_input_schema and workflow_output_schema as multipart form-data fields alongside the existing script fields.
Requested Changes
Edit-FalconScript — upgrade to the v2 PATCH endpoint and add -InputSchema and -OutputSchema parameters that map to workflow_input_schema and workflow_output_schema
Send-FalconScript — if a v2 POST endpoint exists, make the same addition for script creation
Motivation
Without this support, consumers who want to attach structured JSON schemas to their RTR scripts must bypass Edit-FalconScript entirely and call the v2 endpoint manually. In our case, we maintain a workaround script (Update-RtrScript.ps1) that calls /real-time-response/entities/scripts/v2 directly while reusing PSFalcon's token handling — something that should not be necessary if PSFalcon exposed the full v2 API surface.
Input/output schemas are useful for any automation or SOAR workflow that needs to validate script inputs and parse structured script outputs programmatically.
Summary
Edit-FalconScriptandSend-FalconScriptcurrently use the v1 RTR scripts endpoint and do not expose theworkflow_input_schemaorworkflow_output_schemafields available on the v2 endpoint. This means there is no native PSFalcon way to attach input/output schemas to custom RTR scripts — a capability the Falcon API supports today.Notably,
Get-FalconScriptalready uses the v2 endpoint (/real-time-response/entities/scripts/v2:get) when retrieving scripts by ID, so v2 is already partially represented in PSFalcon. Making the write-side commands consistent with this would complete the CRUD surface at v2.Current Behavior
Send-FalconScript/real-time-response/entities/scripts/v1:postEdit-FalconScript/real-time-response/entities/scripts/v1:patchGet-FalconScript/real-time-response/entities/scripts/v2:getThe v2 PATCH endpoint (
/real-time-response/entities/scripts/v2) acceptsworkflow_input_schemaandworkflow_output_schemaas multipart form-data fields alongside the existing script fields.Requested Changes
Edit-FalconScript— upgrade to the v2 PATCH endpoint and add-InputSchemaand-OutputSchemaparameters that map toworkflow_input_schemaandworkflow_output_schemaSend-FalconScript— if a v2 POST endpoint exists, make the same addition for script creationMotivation
Without this support, consumers who want to attach structured JSON schemas to their RTR scripts must bypass
Edit-FalconScriptentirely and call the v2 endpoint manually. In our case, we maintain a workaround script (Update-RtrScript.ps1) that calls/real-time-response/entities/scripts/v2directly while reusing PSFalcon's token handling — something that should not be necessary if PSFalcon exposed the full v2 API surface.Input/output schemas are useful for any automation or SOAR workflow that needs to validate script inputs and parse structured script outputs programmatically.