Collect will need to stop using IMEI as deviceID and making simSerial and subscriberID available

Ah - of course I'd need to password-protect the target folder, which would make a gradual transition and back-compaibility with older versions a bit difficult! :slight_smile:
But it sounds like the installation ID will be viable, as long as I can maintain back-compatibility with my own parameter. Currently I use:

https://my.server.com/formlist/?deviceID=123456789012345

...where 123456789012345 is the IMEI. Am I right that the new form list request would automatically be set to:

https://my.server.com/formlist/?deviceId=Collect:ABCDEFGHIJKLMNOP

...where ABCDEFGHIJKLMNOP is the planned installation ID? (NB we need to be clear whether it's deviceID or deviceId! )

I think this is a positive move for another reason - not all Android devices have an IMEI, so I already use the MAC address for wifi-only devices. Furthermore, devices with multiple interfaces sometimes return different device IDs depending on the connection method - one phone I have has 2 SIM slots, but the device ID obtained by Collect isn't the IMEI for either slot - instead it's one of three different MAC addresses depending on whether it's connected by wifi or one or other of the 4G SIM cards. So a single installation ID will be a Good Thing in the long run.

One other question though - while I favour identifying Collect as the source of the deviceID in the querystring, is it wise to use a colon (":") as the delimiter? The colon normally defines a port number in a URI, and while that shouldn't matter if it's in the querystring rather than the URI, some webservers might not interpret it correctly as part of a querystring parameter...

Thanks
Nik