More information about the recent deprecation of project keys.
Project Key Deprecation Clarification

TL;DR: Nothing will break. Users of OAuth libraries may need to do some extra work when updating to a new version.

As some Apps Script power users have discovered, we recently deprecated ScriptApp.getProjectKey() and added ScriptApp.getScriptId(). Likewise the Project propertied dialog in the script editor now lists the project key as deprecated and also includes the script ID.

Both the project key and the script ID are unique identifiers for an Apps Script project, and the change was made in an effort to standardize on one of them (the script ID). Project keys are shorter and start with an "M", while Script IDs are longer, and are the same as the Drive file IDs (for standalone scripts that exist in your Drive). Here is an example:

Project key: MswhXl8fVhTFUH_Q3UOJbXvxhMjh3Sh48
Script ID: 1ZTZ2vJlryNL0o-qXE3MeD7pFaUXUA4ONiDaaN-bnmDX0yITP4kc_V3oZ

These keys and IDs are used in many places across the Apps Script universe, including:

* Adding libraries in the editor
* Making requests to the Apps Script Execution API
* Building callback URLs

What I want to make clear: we have no plans to turn off or disable the use of project keys. All your code that uses project keys will continue to work for the foreseeable future, and any plans to change that will be formally announced far in advance. Deprecation merely means that we no longer encourage their use, and instead recommend people use the Script ID.

OAuth libraries

Our mistake here was that we originally thought we could silently swap out the IDs in the UI and it wouldn't have a big impact. The one case where this definitely wasn't true is when developers using an OAuth2 library, like the ones I or +Bruce Mcpherson created. Many OAuth providers require that you register your callback URL ahead of time, and enforce that the registered one match exactly with the one sent with the request. This lead to problems when the one used by the developer during registration (fetched from the dialog) and the one sent by the library (fetched via ScriptApp.getProjectKey) started using different IDs.

The solution here was to keep both the project key and script ID accessible in the dialog and ScriptApp, so that libraries and instructions could be gradually updated. A couple of week back I updated my OAuth2 library (https://goo.gl/SEIz8w) to use getScriptId(), and updated my instructions to point to the Script ID in the dialog. Developers already using the older version can continue to do so without worrying, but new users will now be using the more modern Script ID.

The only time you might run into an issue is when you are updating the version of the OAuth2 library you are using, for example to take advantage of a bug fix or new feature. In that case, you may be upgrading from a project-key-based version to a script-ID-based version, and you'll need to make sure that you change the callback URL you have registered with your OAuth provider. The good thing is that this breakage only happens when you choose to change versions, and so will not happen out of the blue one day.

I apologize for any confusion this change has caused, and feel free to reach out to me if you have any follow up questions or find cases where project keys and script IDs aren't working as expected.
Shared publiclyView activity