The scheme name of an Authorization: header (“basic”, “bearer”, etc.) is case-insensitive. Somebody tell Calendly.

Ever have an integration suddenly break because a SaaS provider forgot to read an RFC and silently “fixed” their REST API? Just happened with Calendly and — especially since I was on vacation at the time! — kinda ticked me off.

According to RFC 7235 Section 2.1, the auth-scheme part of an HTTP Authorization header is case-insensitive.

That means Authorization: Bearer aaa111ccc and Authorization: bearer aaaccc (and also authorization: bearer aaa111ccc, since header names are also case-insensitive) must be treated identically.

Here’s the relevant RFC section, highlights added:

HTTP provides a simple challenge-response authentication framework that can be used by a server to challenge a client request and by a client to provide authentication information. It uses a case-insensitive token as a means to identify the authentication scheme, followed by additional information necessary for achieving authentication via that scheme. The latter can be either a comma- separated list of parameters or a single sequence of characters capable of holding base64-encoded information.

auth-scheme = token
auth-param = token BWS "=" BWS ( token / quoted-string )
token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) "="
...
challenge = auth-scheme [ 1SP ( token68 / #auth-param ) ]

But about a week ago, with no announcement nor justification, the Calendly API started throwing HTTP 403 errors unless Bearer was in title case.

Obviously, as an emergency fix, we changed to the required spelling but this meant downtime that looked bad for us.

This is not how APIs are done, Calendly.