Provider keys is a super-admin screen. It holds Finocket's own accounts with the vendors the product calls on everyone's behalf: GST filing, the e-invoice failover, outgoing email, Finocket's own billing, couriers and the storefront app, and Sarvam AI. Changing one here takes effect without a redeploy.
These are not a workspace's keys. A business that brings its own email, SMS, WhatsApp, AI or payment account saves it in its own settings, and that key is used for that business only.
Which key is actually in use
Every provider can be answered from two places: a key saved on this screen, and an environment variable set when the app was deployed. The saved key always wins. Delete it and the environment variable is used again, if one is set; if neither exists, the feature says it is not configured rather than calling the vendor with nothing.
Each row says which of the two is answering right now - vault or environment - not only whether a key exists. A row can be saved and still not be the one in use if it cannot be read, and the screen shows that instead of reporting it as stored.
Sarvam AI
The Sarvam key powers every AI surface billed to Finocket: Mysty, scan-to-add, voice invoicing and the assistant. A new key reaches every server within about a minute; the server that saved it uses it at once. A workspace that has saved its own Sarvam key in its AI keys settings keeps using that key for itself.
Verified, unverified, and failing
Where a vendor allows a harmless test call, the key is checked before it is saved, so a wrong key cannot be stored as a working one. Where no such check exists, the key is stored as unverified - it may well work, but nothing has proved it yet. A key that stops working later is marked with the vendor's own error.
What is recorded
Every save and delete is written to the audit log before it happens, with the provider, the environment and the field names. The key itself is never shown back on this screen, never logged, and never sent to the browser after you save it.
What does not live here
The secrets the app needs before it can reach its own database - the vault's encryption key, the database connection, and the request-signing secrets checked on every call - stay in the deployment environment on purpose. Storing them here would lock the door with the key inside.