fix(webhooks): gate the opt-in trigger outputs on their switches

`method` and `headers` exist only once their switch is on, but the reference
dropdown offered them either way, so a user could select a field the running
webhook would never send. Trigger outputs already support `condition`, which
exists for exactly this — narrowing the declared outputs to the selected
trigger configuration.

Both truthy forms are matched, because a YAML- or Copilot-authored workflow can
write the string rather than the boolean, and the dropdown should agree with
what the delivery path does with that value.

`query` stays unconditional: it has no switch to gate on.

Author: waleedlatif1

apps/sim/triggers/generic/webhook.test.ts

@@ -53,14 +53,25 @@ describe('genericWebhookTrigger', () => {
   })
 
   /**
-   * Each output says what makes it present, because two of the three are opt-in — a description
-   * that omits that reads as a promise the trigger does not keep.
+   * Two of the three outputs only exist once a switch is on, so they are conditioned on it: the
+   * reference dropdown must not offer a field the running webhook will not send.
    */
   it.each([
-    ['method', 'Accept All HTTP Methods'],
-    ['headers', 'Expose Request Headers'],
-  ])('says in the %s description which switch produces it', (key, switchTitle) => {
-    expect(genericWebhookTrigger.outputs[key].description).toContain(switchTitle)
+    ['method', 'acceptAllMethods'],
+    ['headers', 'exposeRequestHeaders'],
+  ])('gates the %s output on the switch that produces it', (key, field) => {
+    expect(genericWebhookTrigger.outputs[key].condition).toEqual({
+      field,
+      value: [true, 'true'],
+    })
+  })
+
+  /**
+   * Query parameters are the one key that is not opt-in, so offering them unconditionally is
+   * correct — gating them on a switch that does not exist would hide them entirely.
+   */
+  it('offers query unconditionally', () => {
+    expect(genericWebhookTrigger.outputs.query.condition).toBeUndefined()
   })
 
   /**

apps/sim/triggers/generic/webhook.ts

@@ -154,24 +154,29 @@ export const genericWebhookTrigger: TriggerConfig = {
   /**
    * Body fields stay undeclared because a generic webhook receives whatever JSON the caller
    * sends. The request metadata below is known ahead of time, so it can be offered for reference.
-   * Each entry says what makes it present, because two of the three are opt-in and all three
-   * yield to a body field of the same name.
+   *
+   * `method` and `headers` are conditioned on the switch that produces them, so the reference
+   * dropdown never offers a field the running webhook will not send. Both truthy forms are
+   * matched because a YAML- or Copilot-authored workflow can write the string rather than the
+   * boolean — the same tolerance `isProviderConfigFlagEnabled` applies at delivery time.
    */
   outputs: {
     method: {
       type: 'string',
       description:
-        'HTTP method of the request. Present when "Accept All HTTP Methods" is on, unless the body has its own "method" field.',
+        'HTTP method of the request. Yields to a body field of the same name if the caller sends one.',
+      condition: { field: 'acceptAllMethods', value: [true, 'true'] },
     },
     query: {
       type: 'object',
       description:
-        'Query parameters from the request URL. Present when the URL has any, unless the body has its own "query" field.',
+        'Query parameters from the request URL, when it has any. Yields to a body field of the same name if the caller sends one.',
     },
     headers: {
       type: 'object',
       description:
-        'Request headers, excluding the ones that carry credentials. Present when "Expose Request Headers" is on, unless the body has its own "headers" field.',
+        'Request headers, excluding the ones that carry credentials. Yields to a body field of the same name if the caller sends one.',
+      condition: { field: 'exposeRequestHeaders', value: [true, 'true'] },
     },
   },