I'd like to compile in some ThingSpeak API keys that are different for each device. I don't want to include all keys for all devices. Is there a compile time mechanism to get device id or serial number so I can be selective about which keys are included?
ok I see the problem with my question as the device to be flashed isn't known at compile time. I supposed I could load a table of API keys and then delete the unused ones at run time. Any other ideas?
You could also only load the relevant key onto the device during first run or use device notes which the device could then request from the cloud.
1 Like
You could send the API key to the device using a Particle Function OR you could OTA as an asset OR (from memory and I may be wrong) you can access data in the console device view comments area - but I haven't found the function to do that (so maybe a hallucination).
1 Like
That's what's called "device notes" 
It works by Particle.publish()ing and Particle.subscribe()ing to particle/device/notes
Just like you request the device name as outlined more thoroughly here
3 Likes
Following what @ScruffR & @armor said, here is some more info about "Device Notes" which might be handy:
You might try looking at the library "CloudConfigRK":
To start, you could implement something like the "devicenotes.cpp" library example. Here is a string you might use in the console for a particular device:
which includes one key and a setting to publish a daily report. (Oops, please ignore the partial highlighting of the JSON string. 
)
1 Like
Hi, If you wanted a library that goes along with the suggestions so far:
2 Likes
another option is creating a cloud function that receives said key and stores them on device, ready to be used.
So you deploy the same firmware on your devices, then configure them with their proper key. Maybe flash them with a default key so they can start transmitting before getting the new one.
1 Like
Another one:
- can you create keys on Thingspeak that you assign the value yourself? if so, create keys with the device ID and use System.deviceID() as the key.
1 Like
Thanks for all the comments everyone. I'll investiage device notes further
@ gusgonnet: The ThingSpeak API doesn't appear to support assigning a value.
To everyone else, at the top of this thread I only wanted my firmware to contain the one ThingSpeak write API key for that device. But the Particle Security "Best Practices" guide really emphasizes that you should not store any API keys in your firmware. If I leave a key in my firmware (string constant) but try to obfuscate it with an algorithm so at least it's not in clear text, will the CPP compiler just optimize it and leave the original key in the firmware? And what type of "bad actor" could get to this? Wouldn't have to be someone who could de-compile my firmware? Is that easy to do? I'm just trying to assess the risk level that I'm comfortable. thanks.
I wonder if this is a great use case for Particle Logic:
The idea here is that every device will publish X, the Logic will subscribe to this X, then add the key needed for the device, then publish it as Y and this is what goes out to Thingspeak.
1 Like
That looks promising. It sounds like I could store my table of (encrypted) Thingspeak keys in the javascript function and then each device could call the "logic" function at startup to get the key. The advantage over device notes (assuming I understood those correctly) appears to be that I'd just have to maintain my keys in one place as opposed to in N different device notes.
thanks for this.
ok, it's not exactly what I proposed but can work too.
Hey, there is Ledger, to store values, maybe you can also leverage that feature:
Cheers
2 Likes