Firefox add-ons contain a unique ID which is used to distinguish this add-on from any other Firefox add-on.
This article describes how add-on IDs are handled for WebExtensions.
Firefox add-ons contain a unique identifier which is used both inside Firefox itself and on the addons.mozilla.org (AMO) website. For example, it's used by Firefox to check for updates to installed add-ons and to identify which objects (such as data stores) are controlled by this add-on.
With older types of Firefox add-on, the add-on developer must set the add-on ID explicitly. XUL/XPCOM add-ons set the ID in the install manifest, while SDK add-ons set it in the package.json.
However, from Firefox 48 you can develop, debug, publish, and update WebExtensions without needing to set an explicit ID at all.
Note that the ability to develop and debug WebExtensions that don't include an ID is new in Firefox 48. If you need to use an earlier version of Firefox, then you must use the applications key to set an ID explicitly.
Basic workflow with no Add-on ID
With WebExtensions, you can set the add-on ID explicitly using the applications key in manifest.json. However, this key is optional. If you don't set it, then you can develop, debug, publish, and update your add-on without ever having to deal with an ID.
One advantage of this is that Google Chrome does not recognize the applications key and will show a warning if you include it. Conversely, if you omit the applications key, then you can use the same manifest.json in Firefox and in Google Chrome.
Developing and debugging
Starting in Firefox 48, if your manifest.json does not contain an ID then the add-on will be assigned a randomly-generated temporary ID when you install it in Firefox. If you then reload the add-on using the "Reload" button, the same ID will be used. If you then restart Firefox and load the add-on again, it will get a new ID.
Publishing
Once you have finished developing the WebExtension, you can package it and submit it to AMO for review and signing. If the packaged add-on you upload does not contain an ID, AMO will generate one for you. It's only at this point that the add-on will be assigned a permanent ID, which will be embedded in the signed packaged add-on.
Note that once a WebExtension has been given a permanent ID, you can't then update it to use the Add-on SDK or legacy XUL/XPCOM techniques. If you do switch to one of these platforms, you must submit it as a distinct new add-on, with a new ID.
Updating
Even after this point, though, you don't generally have to deal with the ID at all. You can continue to develop the add-on without an ID, and when you want to update, upload the new version by visiting the add-on's AMO page. Because you are uploading the add-on through that page, AMO knows that this is an update to this particular add-on, even though it doesn't contain an ID.
It's essential with this workflow that you update the add-on manually using its page on AMO, otherwise AMO will not understand that the submission is an update to an existing add-on, and will treat the update as a brand-new add-on.
You can do the same thing if you are updating from an older add-on type, such as a XUL/XPCOM add-on, to a WebExtension. Just visit the old add-on's page on AMO, upload the new WebExtension there, and it will be treated as an update to the old version.
When do you need an Add-on ID?
If you use AMO's API for uploading your add-on, rather than uploading it manually on its page, then you need to include the add-on's ID in the request.