# Secure your integration

Protect credentials, restrict access to collected data, and review the contract your application executes. The connection instructions on your saved API define the authentication available to your workspace.

## Keep credentials on your server

Server integrations use the supplied bearer credential in the `Authorization` header when machine access is enabled. Store it in your deployment platform's secret storage and inject it at runtime.

Keep credentials out of client-side JavaScript, source control, URLs, screenshots, analytics, and ordinary application logs. Do not reuse a signed-in browser session cookie as an integration credential. Browser access and server access have separate lifecycles.

When key controls are available, review the key's scope, source access, and expiry before use. Use separate credentials for applications or environments where the workspace supports them, so you can replace one integration's credential without disrupting others.

## Rotate and revoke keys

For a planned rotation:

1. Create a replacement with the access your integration needs.
2. Save it securely and update the application configuration.
3. Verify a bounded request using the replacement.
4. Revoke the previous key and remove its copies from runtime configuration.

If a key is exposed, revoke it promptly, review affected usage, and replace it in the application. Removing it from a file or clearing a displayed secret does not revoke the credential. If key creation has an uncertain outcome, inspect the key inventory before creating another.

See [authentication and limits](/docs/authentication/) for the current key and request workflow.

## Control access to results

Source previews, saved definitions, execution inputs, and records can contain information from the source. Review them before exporting or sharing, and collect only the fields your application needs.

A run link does not grant workspace access. Authorized viewers can inspect retained results, and a JSON download creates a copy whose storage and sharing your organization controls. Apply your own access and retention rules to those copies.

Public accessibility does not remove privacy obligations or third-party rights. Use source URLs you are authorized to process, and avoid passwords, private session links, or sensitive data in request URLs and support messages. Review our [Data Usage Policy](/legal/data-usage/) and [Privacy Policy](/legal/privacy/).

## Review requirements before integration

If your organization requires specific processing terms, retention schedules, data-location commitments, or a security review, [contact us](/contact/) before sending data subject to those requirements. Use the published [security overview](/security/) as the starting point for that discussion.

## Report a security issue

Email [info@cleanedweb.com](mailto:info@cleanedweb.com?subject=CleanedWeb%20security%20report) privately with the affected URL, a short description, the time observed, and a minimal reproduction using your own account and data. Include non-secret identifiers rather than credentials or unnecessary personal information.

If a credential was exposed, identify the revoked key by its non-secret identifier. Avoid accessing another customer's data or publishing sensitive reproduction details in a public issue.