PORTAL_ENABLE_WEBHOOK_CUSTOM_HEADERS=true causes TypeScript SDK zod validation of the GET /destination-types response to fail

[dominicrathbone]

Describe the bug
When PORTAL_ENABLE_WEBHOOK_CUSTOM_HEADERS is set to true, a new config field keyed custom_headers is added to the webhook destination type in the response to GET /api/v1/destination-types:

[{"type":"text","label":"Webhook URL","description":"The URL to send webhook events to via HTTP POST","key":"url","required":true,"pattern":"^https?:\\\\/\\\\/[^\\\\s]+$"},{"type":"key_value_map","label":"Custom Headers","description":"Additional HTTP headers to include with every webhook request","key":"custom_headers","required":false}]

This is causing a zod validation in the TypeScript SDK as it doesn't seem to recognise the key_value_map type:

[{"received":"key_value_map","code":"invalid_enum_value","options":["text","checkbox"],"path":[0,"config_fields",1,"type"],"message":"Invalid enum value. Expected 'text' | 'checkbox', received 'key_value_map'"}]

To Reproduce
Steps to reproduce the behavior:

1. Set the PORTAL_ENABLE_WEBHOOK_CUSTOM_HEADERS environment variable to true
2. Install typescript SDK package and run new Outpost({ ... })..schemas.listDestinationTypes()
3. Zod validation error occurs

Expected behavior

The TypeScript SDK should recognise this enum value

[alexluong]

Thanks @dominicrathbone for opening the issue. cc @leggetter

[alexbouchardd]

@alexluong If this is a portal-only flag, it shouldn't impact the API response. However, thinking about this more, it does make me think it shouldn't be a portal-level config and instead a top-level config that would impact the API response?

The "issue" otherwise is that each UI implementation needs to filter the schema fields for this field

[alexluong]

My initial exploration is that there is a missing OpenAPI schema case for this. Enabling it on the portal = portal can set custom headers -> issue because SDK is not equipped to handle it.

We should be able to fix this at the OpenAPI/SDK layer.

[alexbouchardd]

Yes, but the fact that a flag called PORTAL_ENABLE_WEBHOOK_CUSTOM_HEADERS impacts the API response is a concrete issue that this raised, regardless.

I'd argue the valid approach is either:

• Always return the field and filter it out on the Portal UI
• Update the flag to be DESTINATION_WEBHOOK_ENABLE_CUSTOM_HEADERS which would alter the API response and also change the input validation for the destination config to reject custom_headers if not enabled

In either case, you are correct that the schema & SDKs need to be updated to account for that property