Currently testing my web pixels app on my development store. The accountID was hard-coded. So what is the point of this? In a production scenario is accountID unique to each store and can we use it as a unique identifier? Is it better than using shopDomain?
Thanks!
Hello,
The accountId field in an app pixel extension is just an example that comes with the default extension template. It serves as a basis to show what is possible with this configuration, but it is not required or has any uses by default.
These settings relate to metafields, custom data that can be capture by your app and it becomes available in the web pixel under the settings property of the standard API provided to the register function callback.
Hope this help clear things up a little bit! 
Ok thank you for that clarification. So then is it possible to generate a API key that is unique to the store? Otherwise I’m having a hard time figuring out how do we do authentication on the API call when sending the json response to our server? Thanks!
I believe it would be possible to generate a unique token, which would be saved in the database with the settings when the app is installed on a store.
Note that this token would end up on the frontend, inside the pixel settings, so it should not be a secret.
Ok I appreciate your response! This seems like a good way to secure the API calls. Essentially to generate an API Key when the shop owner installs the app. That’s ok if the API key is visible in the app settings, as long as only the shop owner can see it. Would it be visible in the frontend code for the shop itself? Thanks!
Anything that is passed to pixels (e.g. through settings) ends up on the frontend side. It’s in a sandbox (web worker), but it is still available on the frontend.
So, it should not be their secret API key, it could be just some non-secret API token that has no value other than in the current setup it is used (e.g. only allow calls from specific preconfigured domains, etc).
