Create and manage API keys
An API key lets a script or integration access YouScaleIt without asking you to sign in for every request. Treat it like a password: anyone who has it may be able to act with the access it provides.
Create your first key
- Sign in to YouScaleIt and open API Keys.
- Select Create New Key.
- Give it a name that explains what it is for. For example, “Weekly calendar report” is more useful than “Key 1”.
- Select Generate Secret Key.
- Copy the key and save it in your integration’s secret storage before closing the dialog.
The full key is shown only when it is created. The prefix in the list helps you recognize a key later; it is not enough to authenticate a request.
You can keep up to five keys per user. Key management and use require an eligible company account under the current access policy. If the page reports that you do not have access, check your account and subscription rather than repeatedly creating new requests.
Where to put the key
The header depends on what you are connecting to.
| Connection | Header |
|---|---|
| Website REST endpoints covered in these docs | x-youscaleit-api-key: YOUR_API_KEY |
| MCP with an API key | Authorization: Bearer YOUR_API_KEY |
| MCP alternative, if your client supports custom headers | x-youscaleit-api-key: YOUR_API_KEY |
Use one authentication header, not several. The MCP server rejects requests containing both its custom API-key header and an Authorization header, even if the values match.
The documented REST paths start with /api on the YouScaleIt website origin, without a /v1 prefix. Backend header aliases such as x-api-token and xiiit-api-key are not the incoming authentication headers for these website routes. See your first request for the correct URLs.
The website REST routes also accept browser sessions. A session token takes priority when both a session and an API key are present. To check a key independently, use a server-side client without browser cookies. A missing credential produces a generic Unauthorized response; other authentication or access failures may be returned as generic 404 responses by these read routes.
YOUR_API_KEY is a placeholder, not a working credential.
Store it where only your integration can read it
For a server-side script, use an environment variable or a secret manager. For an automation service, use its credentials or secret settings.
Do not put the key in:
- Browser-side JavaScript or a public mobile application bundle.
- A URL or query string.
- An AI prompt or MCP tool argument.
- A committed configuration file.
- Logs, screenshots, or support messages.
Use a separate key for each integration where possible. If one integration is no longer needed, you can remove its access without breaking the others.
Replace a key
For a planned rotation:
- Create a replacement key.
- Update the integration’s stored credential.
- Make a read request to check that the replacement works.
- Revoke the old key.
If all five slots are occupied, remove an unused key first. If there are no unused keys, plan the replacement so the affected integration can tolerate a short interruption.
If a key has leaked, revoke it first. Avoid leaving it active just to keep an integration running while you prepare the replacement.
Revoke access
Open API Keys, find the key, select Revoke, and confirm. Requests using that key will no longer authenticate.
Revoking a key does not undo an action that already completed. For example, removing a credential is not the same as canceling a post that was already scheduled.
API keys and connected agents are separate
An OAuth agent connection has its own permissions and revocation controls in Connected agents.
Disconnecting an OAuth agent does not revoke your API keys or sign you out of the website. Likewise, deleting an API key is not how you disconnect an OAuth agent.
The API-key MCP connection is read-only, but that does not make the key itself read-only on other API endpoints. Keep it private even if your assistant only uses it to read the calendar.