Publishable keys
Armenus has two credential types. Putting the wrong one in client code is the most expensive mistake available here, so the SDKs throw at construction rather than letting it quietly work.
| Key | Lives | Can |
|---|---|---|
pk_…publishable | In your app bundle, in your JavaScript | Read dishes and models. Nothing else. |
ak_…secret | On your server, only | Create merchants, upload models, spend money. |
A publishable key is public. That is fine.
It ships inside an iOS binary and a JavaScript bundle. Anyone can read it out in about a minute, and no amount of obfuscation changes that. Its safety comes from what it is permitted to do, not from who holds it:
- Read-only — it reaches no mutating route at all.
- Scoped— to one partner’s merchants, or to a single restaurant.
- Already-public data — the same models the QR menu serves anonymously to any passer-by.
- Quota-limited per key, and revocable — a leaked key is rotated, not a breach.
Because of that we store and display the full key rather than only its hash. “Shown once, never recoverable” protects nothing for a string already sitting in the customer’s own app, and costs them the ability to look it up.
Scope
A key belongs to eithera partner or a single restaurant, never both. A partner key reads every merchant that partner owns; a restaurant key reads exactly one restaurant. A partner can also mint a key narrowed to one of its own merchants — useful for a white-label build shipped to a single chain, where a key that could read the partner’s whole book of business is more authority than that build needs.
{
"scope": "restaurant",
"ownerName": "Pizza Roma",
"merchants": [
{ "id": "14f37130-...", "slug": "pizza-roma", "name": "Pizza Roma",
"currency": "USD", "locale": "en-US" }
]
}Origin allowlisting
A key can be pinned to a list of web origins. Leave it empty for native apps, which send no Origin header at all.
{
"label": "marketing site",
"allowedOrigins": ["https://example.com"],
"rateLimitPerMinute": 600
}Rotating
Mint the replacement, ship it, then revoke the old one. Revocation takes effect on the next request; a second revoke does not move the timestamp, which is the audit record of when the key actually stopped working. A key also stops working the moment its restaurant is suspended or its partner deactivated, which is what an operator suspending an account expects.
curl -X DELETE \
https://api.armenus.app/v1/partner/publishable-keys/$KEY_ID \
-H "Authorization: Bearer ak_your_secret_key"