No. 23Product systems3 min readOCTYN
Keeping API keys off the device in a consumer app gives you an off switch.
Keeping API keys off the device in a consumer app means every outside call goes through a small function on your own server. The download then holds no key at all, and changing one needs no store release. The price is one more stop on every call, which is worth measuring from the first day.
The quickest way to get a model feature into a customer app is to paste the provider's key into the app itself, and the demo will go very well. That key is a password that bills your company for every call. Once it sits inside a download from a public store, anyone patient enough can unpack the app and read it, and the bill for whatever they do next comes to you.
Say you run a chain of home improvement stores (a made up example), and the app is getting a feature where a customer describes a job out loud and gets back a list of parts. The decision lands on whoever owns that feature on a bad Saturday, since where the key lives decides what you can change without a store release.
One more stop on the way out
The usual answer is a small function on a server you control. The phone asks the function, the function holds the key and asks the provider, and the answer comes back along the same road. Every outside call in Mooney goes this way, Mooney being the expense app OCTYN runs on Google Play, with sixteen of those functions in production as of 20 June 2026 and no key anywhere in the app. Inkling, OCTYN's writing app, sends its assistant through a proxy, so the key can be rotated and the feature switched off without anybody reinstalling anything.
What each choice does on a bad Saturday
| What happens | Key inside the app | Key on your server |
|---|---|---|
| The key gets out | a new release, and old versions still carry it | swapped, no release |
| One account hammers the feature | the limit sees one phone | the limit sees every user |
| The feature misbehaves | a release, through store review | switched off remotely |
The right hand column comes from those two apps. In Mooney, keys, daily caps and the primary provider are all configuration, and a server side change reaches every phone already running the app with no store review.
A key that hits a limit or an error in Mooney sits out for 60 seconds while traffic moves to the least loaded one, which no single phone could arrange, having no idea what the other phones are up to.
What the extra stop costs
Every call now goes to your server before it goes to the provider, and that time has to come from somewhere. Mooney takes under five seconds from the end of speech to a saved row, a figure from screen recordings on a phone over a live network. Timing for each stage was still not recorded in the app on 14 September 2026, so OCTYN cannot tell you what this stop costs in its own product, and the write up lists that as the first thing to change. Ask for p95 latency on your feature, by stage, from the first release.
A call that never leaves the phone needs no key. Mooney added its on device path after the cloud path existed, and the write up says it should have come first. So before anyone argues about where the key goes, find out which steps need to leave the phone at all.
If a builder is quoting you for the feature, ask where the keys live and what changing one costs. The page on a production ready system has the rest of that list.
Speech in Mooney has no second provider, so if both keys on that leg fail, voice stops. It is written down, which is about the most that can be said for it.
Bring the version of this that is about your company.
The first conversation is with the people who would build it. If there is a fit, the Consult comes next.