Firefox add-ons contain a unique ID which is used to distinguish this add-on from any other Firefox add-on.
With legacy Firefox add-ons, the add-on developer must set the add-on ID explicitly. But with WebExtensions, most of the time you don't need to deal with the ID at all. This article describes how add-on IDs are handled for WebExtensions, and when you need to care about setting the ID explicitly.
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 such as XUL/XPCOM or SDK add-ons, the add-on developer must set the add-on ID explicitly, as an entry in the install manifest or (with the Add-on SDK) in package.json. But with WebExtensions, most of the time you don't need to deal with the ID at all.
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
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, and 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.
Updating
Even after this point, though, add-on developers 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 its ID.
However, 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.
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.