Regression in Create Webhooks API?

sgolux

Hello in the past 36-ish hours, the response to the Create Webhooks API (POST /2.0/Webhooks) appears to have suffered a regression.

Prior to the change, this API (and all other POST and PUT Smartsheet APIs we have been using) would accept the following as the Content-Type header for the HTTP Request:

Content-Type: application/json; charset=utf-8

But subsequent to this change (whatever it was) the Create Webhooks API in particular (and no others that I have experimented with) will respond with the following error:

HTTP/1.1 415 Unsupported Media Type
…
{"errorCode":1124,"message":"Invalid Content-Type header. Media type not supported.","refId":"nLRdhm"}

However, if rewrite my requesting code to specify the following on the HTTP Request:

Content-Type: application/json

Without the charset (encoding) designation, then it works fine. Again, every single other API that I have tried in the Smartsheet API suite still works WITH that charset designation in the Content-Type header, it is only the Create Webhooks POST that fails.

I would call this a bug, and it is a big pain for us….. anyone else have a sense of this?

prime_nathaniel

@sgolux when did you see documentation requiring charset utf-8, I don't actually recall a time it was ever anything other than content-type: application/json. Lol that said I also just default assumed it was utf-8 this whole time.

sgolux

Thanks @prime_nathaniel - just to clarify, documentation never required charset designation, and probably the system assumes UTF-8 for encoding (that would be typical). My apologies if my initial post was unclear, what I meant to say is that for at least a couple of years, the POST to the Create Webhooks API would (IMO appropriately) handle the Content-Type header, with or without the charset designation, and given that many frameworks (in out case .NET) include that designation by default, this is a good thing. For sure there is a regression because about 48 hours ago, this one API from Smartsheet started to fall over if that charset designation was included. Also it falls over with the incorrect error - 415 is designated as error for incorrect media type, but the problem wasn't with the media type. Also, no other API from Smartsheet that I have tested fails in the same way, all of the continue to accept the charset designation. This forensic data leads me to believe that this regression is also a bug. But as far as I know there is no mention in the documentation one way or the other about the specification of encoding.