We’re adjusting how authentication is handled in Stack Exchange API v2. For those unaware, Stack Exchange maintains an API that users can authenticate with to execute commands or request data on the site. Many veteran users utilize the API to perform automated actions on the site through userscripts, or to recreate certain tooling themselves to improve their personal site experience.
Currently, the key query parameter can be utilized to confer additional requests per day with registered applications, and the access_token parameter can be utilized to confer authenticated access for certain endpoints. Starting in June 2026, we’ll be removing the ability to pass authentication/API keys via query parameters. Once this change is live, all requests that require authentication will require either the API key or the access token to be passed via the Authorization request header using the Bearer scheme, which would appear as follows: Authorization: Bearer {KEY OR ACCESS TOKEN}. If you are authenticating with the SDK, please ensure you remove the key parameter. It will no longer be required to pass a key along with an access token if the intent is to make an authorized request. You need only pass an access token if you are intending on performing an action that requires authentication, and an API key if you wish to utilize additional requests per day.
Once this change is live, requests that are made with the old authentication scheme will not be accepted and we will reject them with an explanatory error message.
This change affects any script, bot, or application that performs any authenticated action on behalf of a user, such as commenting, voting, flagging, editing, etc. or otherwise requires authentication to be passed along. This will affect projects such as the Charcoal project’s Metasmoke application as it casts flags on behalf of users. It will also affect tooling that accesses the API and benefits from additional requests for day via an API key. As an example, the “View Vote totals” userscript userscript (code preview) will need to be updated to move the key parameter’s value to an Authorization header instead.
The reason for this change is to bring our API up to the industry’s best practices and ensure that your API keys are being handled securely. The API has already been changed to accept this new form of authentication, so if you maintain any applications or userscripts that authenticate with the API, you can start updating their approach to authentication now. We’ve updated all of our API documentation’s examples to demonstrate the new method of authentication so that you can see real-world examples if you’re having trouble navigating this change. You can double-check how the headers look using your browser’s dev tools if you feel unsure.
We’re announcing the deprecation as early as we can so that tool and app maintainers can update their projects over the next several months. We’re aware of just how reliant our core user base is on the tools they maintain, and we hope that adjusting for this deprecation is easily done. We're also aware that this affects a large amount of outstanding tooling. If there are any projects that are struggling to come into compliance with the new authentication scheme as June approaches, we can push the deadline a bit further into the future.
If you need any assistance updating your tools and apps to use the new method of authentication, please post an answer below, and we’ll do our best to work with you on this. We understand that the tooling you’ve built is central to you, and it’s our job to ensure you’re as supported as possible when we change the underlying mechanisms that support that tooling.
keyis not used for authentication. Thekeyis used to identify the script/app/etc. that is making the request.keyvalues are, typically, stored in public repositories. They are, thus, public for almost all applications. Anaccess_tokenvalue, which is actually the secret value, is what is used for authentication (actually, it's the combination of both the publickeyand the secretaccess_token). As such, this change does little or nothing to improve security and is guaranteed to break almost everything, because nearly everything uses akeyvalue.keyvalue are some things under the beginnings of test/development. Without akeyvalue, an application is limited to a shared 300 requests/day/IP address. However, even that's not actually available, because the quota on the SE API has been broken for many years, resulting in that 300 requests/day/IP address quota being shared with the 10k request/day/IP address which is available to requests with akey. This results in the 300 non-keyquota commonly not actually being available, so everything uses akeyvalue.access_tokenas a query parameter when this change goes live, and either the API key or the token can be passed as an Authorization header. To the point about thekeynot really being authentication, you're right, but it effectively acts as a (publicly available) key to permit additional requests per day, and this change brings it into consistency with auth'd requests. Use the API key for requests that don't require authentication, and the access token where needed.2.Xin the title to try and make that clear.curl -s --compressed "https://api.stackexchange.com/2.4/inbox/unread?key=$SE_KEY&access_token=$SE_ACCESS_TOKEN"?access_tokenas a header. You can drop the key. In your example, it'd becurl -s --compressed -H "Authorization: Bearer $SE_ACCESS_TOKEN" "https://api.stackexchange.com/2.4/inbox/unread"- I'll see if I can make some examples as an answer below.