# Security and data handling

Understand the request path, credential controls and stored records before integrating Monocrawl into your application.

## What a request sends and returns

- Your server sends an HTTPS request with a credential in a header. Do not include keys in URLs, query parameters, browser bundles or chat.

- Monocrawl authenticates the request and checks applicable account, key, rate and spending limits. A supported cache hit can be returned without a new source fetch.

- Collection forwards the target and parameters needed by the configured data source, using Monocrawl’s source credentials. Your Monocrawl API key is not a source-platform login.

- The response includes endpoint data and a receipt. Your application is responsible for restricting access to its stored copies and for its own retention policy.

Public-data endpoints do not grant access to private accounts or private messages. A source URL being public does not guarantee it remains retrievable. Web collection and browser-session operations have their own documented controls; do not infer their permissions from a social-profile endpoint.

- [Public-data policy](https://www.monocrawl.com/legal/public-data)

- [Data availability](https://www.monocrawl.com/docs/data-availability)

## Store, restrict and rotate credentials

API requests are validated using key hashes. New keys also have an encrypted copy for authenticated owner recovery; older hash-only keys cannot be revealed. A prefix and last characters identify a key without exposing it. Use separate credentials per environment and workload, and set cumulative key limits. Revocation is permanent.

- Create a replacement key and store it in your server’s secret manager.

- Deploy it and verify a free balance request plus the expected workload’s access.

- Confirm traffic has moved, then revoke the old key. Investigate unexpected usage before increasing caps.

MCP browser connections are revocable. Account funds, the credential’s cap and max_credits on an individual retrieval have different scopes. Never grant a model permission to increase its own cap.

- [Authentication and key controls](https://www.monocrawl.com/docs/authentication)

- [MCP authentication](https://www.monocrawl.com/docs/mcp#oauth)

## Distinguish cache, request history and account records

| Record | How to treat it |
| --- | --- |
| Response cache | Endpoint-specific shared cache lifetimes apply. A cached response is not proof of a new source fetch. Consult the cache guide for bypass and stale-directory behavior. |
| Request and usage records | Request paths, parameters, IDs, status, timing and credit usage can be recorded for operation and support. Avoid putting unrelated sensitive text into query inputs. |
| Idempotency records | Completed responses are ordinarily retained for 24 hours. An unresolved durable charge can remain protected beyond the normal replay window; do not equate expiration with a refund. |
| Account-linked history | Retention and available deletion actions differ by record type. Account erasure is subject to the published policy and required payment-record retention. |

- [Retention and deletion policy](https://www.monocrawl.com/legal/privacy-policy#retention)

- [Caching](https://www.monocrawl.com/docs/pagination-caching)

- [Idempotency](https://www.monocrawl.com/docs/api-reference#idempotency)

## Protect your own integration

Redact credentials and sensitive query values from logs. Keep request IDs, status and confirmed credit receipts. Validate webhook signatures against the raw request body before processing deliveries. Limit the endpoints available to an AI tool, cap calls and treat retrieved content as data rather than instructions.

For security or privacy questions, contact Monocrawl with a redacted request ID and the affected operation. Do not send API keys or unredacted customer records.

- [Contact](https://www.monocrawl.com/contact)

- [Webhook signatures](https://www.monocrawl.com/docs/api-reference#webhooks)

- [AI integration](https://www.monocrawl.com/docs/ai-agents)