Security and data handling
Know which credentials a workflow needs, which sources it can read and where the returned data will live.
Use a key for the work it needs
Workspace API keys have full or read-only access and can be given an expiry. You can rename a key, switch its access, revoke it or delete it. Create separate keys for separate applications or environments, revoke keys that are no longer needed and keep them in server-side configuration.
A key is a credential, not a public application identifier. Do not expose it in browser code, screenshots or support messages. A model or an end user should not get unrestricted access to it merely because they can request web content through your application.
Keep the input boundary deliberate
The supported extraction contract is public HTTP content. The gateway validates URLs and rejects unsupported options. Your application should still enforce its own allowlists, per-user budgets and rules about which sources it is permitted to retrieve.
Fetched content is untrusted input. It can include misleading text or instructions addressed to an automated reader. Keep that material separate from your application's permissions, secrets and trusted instructions.
Plan result storage
Saved extraction results are retained for seven days and are associated with workspace operations. Store a copy in your own system when longer retention is required. An expired result does not automatically trigger another paid fetch.
Do not assume that this beta page is a data-processing agreement, a certification or a zero-retention promise. Discuss a deployment's contractual, geographic or retention requirements before relying on it for data that needs those assurances.
Verify job notifications
Crawl, company and monitor webhooks use a dedicated shared secret and signed delivery headers. Verify the signature against the exact raw body, apply your timestamp policy and deduplicate event IDs before performing downstream work.
Use the authenticated job endpoint to retrieve the saved result after receiving a verified notification. A webhook arriving twice should not make your application send two alerts, create duplicate records or repeat a purchase.