# Web Services Connector Adding Content-Type Header **URL:** \ **Category:** SHF Discussion and Questions\ **Tags:** webservice-connector, sailpoint-identity-security\ **Created:** [October 31, 2024, 1:54pm UTC](https://developer.sailpoint.com/discuss/t/web-services-connector-adding-content-type-header/87494 "2024-10-31T13:54:05Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![patrickboston](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/patrickboston/32/5876_2.png) [@patrickboston](https://developer.sailpoint.com/discuss/u/patrickboston)\ **Post date:** [October 31, 2024, 1:54pm UTC](https://developer.sailpoint.com/discuss/t/web-services-connector-adding-content-type-header/87494/1 "2024-10-31T13:54:05Z")
I’ve run into an interesting scenario. I have an HTTP endpoint I need to call with a Web Services connector. The endpoint HTTP operation is a `DELETE`. Because it is a `DELETE`, the API is not expecting a payload/body, which makes sense. The issue is that if there are no headers defined for the operation in the source configuration, the connector will automatically add a `Content-Type` header with value `application/json`. This causes the endpoint to throw a 415 Unsupported Media Type which makes total sense because it’s not expecting a payload, yet the connector is basically forcing the API to think we are sending one because of the `Content-Type` header. To make it even worse, it’s doing this AFTER the WebServicesBeforeOperation rule runs, so I cannot null out the headers with that rule. I’ve verified this via the ccg logs. **Has anyone else run into this and found a workaround?** A guess a possible workaround is executing the DELETE in the before rule, but is a bit of a hack. I get that SailPoint is trying to reduce human error by automatically adding the header as it makes sense in a lot situations, but they simply just shouldn’t be doing that at the same time. It’s a bad assumption. ---
**Author:** ![pradeep1602](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/pradeep1602/32/30858_2.png) [@pradeep1602](https://developer.sailpoint.com/discuss/u/pradeep1602)\ **Post date:** [November 5, 2024, 1:53am UTC](https://developer.sailpoint.com/discuss/t/web-services-connector-adding-content-type-header/87494/2 "2024-11-05T01:53:12Z")
I guess you can try to remove this from before operation rule if this is causing the problem ---
**Author:** ![j\_place](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/j_place/32/19181_2.png) [@j\_place](https://developer.sailpoint.com/discuss/u/j_place)\ **Post date:** [November 5, 2024, 11:04am UTC](https://developer.sailpoint.com/discuss/t/web-services-connector-adding-content-type-header/87494/3 "2024-11-05T11:04:56Z")
When you say it’s a bit of a hack - I could be reading it wrong, but it looks like delete account isn’t supported out of the box and a before rule is recommended (from [HTTP Operations](https://documentation.sailpoint.com/connectors/webservices/help/integrating_webservices/http_operations.html)). That’s from the VA based Web Services Connector. However, just noticed that delete account **is** supported in the SaaS Web Services Connector, with the interesting note: “If you wish to exclude the default Content-Type header from the requests, please add `removeDefaultHeaderFromRequest:true` in the connectionParamater object” > **[Header](https://documentation.sailpoint.com/connectors/saas/web_services/help/saas_connectivity/web_services/headers.html)** > > SailPoint Connectors Documentation ---
**Author:** ![patrickboston](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/patrickboston/32/5876_2.png) [@patrickboston](https://developer.sailpoint.com/discuss/u/patrickboston)\ **Post date:** [November 5, 2024, 1:28pm UTC](https://developer.sailpoint.com/discuss/t/web-services-connector-adding-content-type-header/87494/4 "2024-11-05T13:28:24Z")
@j_place Keep in mind I am just talking about using an HTTP DELETE, doesn’t mean it’s necessarily tied to an account Delete operation (although in this case it is, and I am using a BeforeProvisioning rule to accomplish this…). Thanks for finding this on the SaaS Web Services connector. Unfortunately I am using the VA based Web Services connector, but it’s good to know this workaround is built into the other version. I ended up executing the DELETE in the WebServicesBeforeOperation rule (where I did not add any headers) and then just allowing HTTP 415 to be an allowed success code on the actual configured delete call on the source. ---
**Author:** ![system](https://global.discourse-cdn.com/sailpoint/original/2X/f/f2136700ed5e3703e0b85e02f6be799dacca7735.png) [@system](https://developer.sailpoint.com/discuss/u/system)\ **Post date:** [January 4, 2025, 1:29pm UTC](https://developer.sailpoint.com/discuss/t/web-services-connector-adding-content-type-header/87494/5 "2025-01-04T13:29:21Z")
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.