APPSINITYAPI keys
There is no keys screen, no key format, no prefix to grep for in a repository and no per-key revocation. Any automation you build today runs as you, with your session token, for thirty days.
Open Appsinity StudioWhat does not exist
| Feature | Status | Consequence |
|---|---|---|
| Long-lived API keys | None | No credential that is safe to put in a server |
| Secret / publishable key pair | None | Nothing is safe to expose in a client |
| Key scopes or permissions | None | A token can do everything you can |
| Per-key rate limits | None | Automation shares your ordinary limits |
| Key rotation or revocation | None | A leaked token lives out its expiry |
| Usage analytics per key | None | You cannot see what a script did |
| Service or bot accounts | None | Every actor is a human account |
The credential you actually have
A bearer token from POST /api/auth/login. It is a session, not a key, and the difference matters in four places.
| Property | Session token | What an API key would give you |
|---|---|---|
| Lifetime | 30 days, no refresh | An expiry you choose |
| Blast radius | The whole account | Scoped to a purpose |
| Revocation | Local logout only | Immediate, server-side |
| Attribution | Indistinguishable from you | Separate in logs |
| Rotation | Re-login | Issue a new key |
TOKEN=$(curl -4 -s -X POST https://api.appsinity.com/api/auth/login \
-H 'Content-Type: application/json' \
-d '{"email":"[email protected]","password":"..."}' | jq -r .token)
curl -4 -s https://api.appsinity.com/api/auth/me -H "Authorization: Bearer $TOKEN"Whether to automate anyway
- Reasonable: a read-only script that pulls
/api/listing-analyticsonce a day into a sheet you keep. - Reasonable: the public catalogue endpoints, which need no credential at all.
- Risky: a job that patches listing metadata, because a bad payload merges into your live record and there is no undo.
- Risky: publishing or unpublishing on a schedule, since the status change is indistinguishable from your own click.
- Not advisable: anything on a shared machine, in a repository, or handed to a third party.
PATCH /api/docs/:collection/:id is a JSONB merge. An automation that sends a partial object will not clear omitted fields, and a typo in a key name writes a new field your listing never had.If you automate, limit the damage
- Use a dedicated account. Not your owner account. A separate developer account for tooling keeps an incident off your catalogue.
- Read first, write only on a diff. Fetch the current document, compute the change locally, send only the fields that actually differ.
- Store the token outside the repo. An environment variable in your own runner, never a file that syncs.
- Log every mutation. The API will not tell you later what changed, so keep your own record with timestamps.
- Re-auth on 401 and stop. A single retry after a fresh sign-in, then alert. Never loop against an expired session.
- Sign out when finished. Clears the stored token on that machine, which is the closest thing to revocation available.
Frequently asked questions
Where do I create an API key?
You cannot. No key is issued by any Appsinity service, including uploads and payments.
Can I at least scope a token?
No. Scoping exists only as team roles in the UI, and those constrain what a member sees, not what a token may call.
Someone found a token in my repository.
Treat it as a full compromise: change the password, sign out everywhere you can, rotate anything the account could reach (payout details, connected domains), then review your listings for changes you did not make.
Do the Cloudflare Workers need a key?
No, they need your bearer token on the presign call. The payments Worker is the only service holding real secrets, and they live in its Worker environment, not with you.
Developer publishing support: [email protected]
General support: [email protected]
Partnerships: [email protected]