Issue API Keys and Access Policies

API keys let an external integration access selected CleanOver data without sharing a person’s login. Use one key per integration and apply the smallest access policy that still supports the workflow.

What you will accomplish

By the end of this guide, you will be able to complete an API key from the correct CleanOver screen, understand the important checks before saving, and verify that the result is visible to the people who use it next.

Before you begin

• Create or review the access policy first.
• Know the integration owner, purpose, required scopes, and planned expiry date.
• Sign in to the Admin workspace and confirm you are in the correct business context.
• Use real operational dates and the property’s local timezone when the workflow includes time.

Step 1: Open API Keys

Go to General Settings and select API Keys. Review active keys, prefixes, policies, creation dates, and expiry before adding another key.

Expected result: No existing key already serves the same integration.

Step 2: Select Create API Key

Open the creation form and enter a clear name that identifies the system and environment, for example “Reporting – Production.”

Expected result: The owner can identify the key later.

Step 3: Choose the access policy

Select the policy containing only the required permissions. Avoid owner-level or full-access policies for a narrow integration.

Expected result: The key cannot access unrelated modules.

Step 4: Set an expiry

Use a practical expiry date when the integration can rotate credentials. Permanent keys require a documented review process.

Expected result: The credential lifecycle is intentional.

Step 5: Create and copy the secret once

Create the key and copy the full secret from the one-time display. After the modal closes, CleanOver shows only a prefix.

Expected result: The secret is stored securely before leaving the screen.

Step 6: Configure the destination system

Paste the secret only into the approved integration’s secure credential field or secret manager. Do not place it in source code, chat, or documentation.

Expected result: The integration can authenticate without exposing the secret.

Step 7: Test the minimum workflow

Run a read or write operation the policy should permit, then confirm an unrelated restricted operation is denied.

Expected result: The policy is neither too narrow nor too broad.

Step 8: Rotate or revoke when needed

Revoke a key immediately if exposed, unused, or no longer owned. Create the replacement first when downtime must be avoided.

Expected result: Only active, accountable integrations retain access.

How to confirm the workflow is complete

• Refresh the destination list or calendar and confirm the saved record appears only once.
• Check the unit, date, status, owner or assignee, and any linked record before leaving the page.
• Open the next downstream view mentioned in the guide and confirm it shows the same information.
• Record an internal note when the action corrects historical data or changes another person’s responsibility.

Common issues and what to do

The expected record is missing

Clear old filters, check the date and business context, then search by the most specific identifier available. If the data comes from a connected provider, check connection and mapping status before recreating it manually.

A button is disabled

Look for a required field, incomplete checklist item, missing permission, locked lifecycle status, or unresolved linked task. Complete the highlighted requirement instead of trying to bypass it.

The page shows different information after refresh

Another user or integration may have updated the record. Compare timestamps and the source system, then apply the correction in the system that owns the data.

You are unsure whether to continue

Stop before cancelling, overwriting, revoking, or issuing a financial document. Ask the workflow owner to confirm the intended outcome and add that decision to the internal record.

Best practices

• Use clear names that make sense to a new team member without extra context.
• Prefer the smallest safe scope for bulk actions, filters, permissions, and date ranges.
• Keep guest-facing communication separate from internal diagnostic notes.
• Verify a high-risk change in a second view before considering it finished.
• Update the source configuration when the same correction is needed repeatedly.