Thanks to visit codestin.com
Credit goes to docs.context.dev

Skip to main content
Use primary evidence for a security or procurement review. Product documentation explains how controls affect your integration; the Trust Center, status page, and signed agreement remain authoritative for compliance and contractual commitments. Last verified: September 4, 2026.

​
Find the evidence

​
Compliance status

The Trust Center currently lists:
  • SOC 2 Type I: compliant.
  • SOC 2 Type II: in progress.
  • Published security policies, controls, and subprocessors for review.
Request access to controlled evidence through the Trust Center. Do not rely on this summary if your review requires the latest report, scope, observation period, or exceptions.

​
Data handling choices

Context.dev is a hosted service. Request and response data is sent to Context.dev for processing; there is no self-hosted edition documented today. For eligible scraping and parsing workloads, Zero Data Retention can bypass shared caches and retained request or response content logs. ZDR is an organization entitlement and must be requested per call. Your application should verify X-Context-ZDR: true before recording that the control was honored. API keys are organization bearer credentials. Keep them in a server-side secret store, rotate them after suspected exposure, and do not place them in browser or mobile bundles.

​
Reliability and support

  • The status page publishes current state and incident history.
  • The pricing page currently lists a 99.9% uptime SLA as an Enterprise feature. The signed agreement defines the actual scope, exclusions, credits, and measurement window.
  • Support channels vary by plan. Use [email protected] for documentation and integration questions.
Customer stories show real integration patterns, but they are not service-level evidence. Use the status history and contract for a reliability review.

​
Portability boundaries

Responses use common formats such as JSON, Markdown, HTML, image URLs, and JSON Schema. This reduces migration work, but portability still depends on which product behavior your application adopts. Plan for:
  • Mapping Context.dev-specific Brand and monitor response fields.
  • Replacing cache, proxy, browser-action, and classification behavior if another provider differs.
  • Storing data your application needs after the request, subject to your rights and retention policy.
  • Testing raw HTTPS separately from an SDK so package-specific serialization is not your only contract test.
The public OpenAPI document is the server-contract source. SDK packages version and publish separately and can lag an API change; see API stability.

​
Procurement checklist

  • Review the current Trust Center evidence and subprocessors.
  • Confirm whether the DPA, MSA, SLA, SSO, or SCIM is required.
  • Document which requests need ZDR and test the confirmation header.
  • Define API-key ownership, rotation, and incident response.
  • Set acceptable cache age, timeout, retry, and fallback behavior.
  • Run representative data-quality tests for your actual domains and pages.
  • Confirm the plan’s current credit, rate, batch, and monitor limits.
For requirements not covered by public evidence, contact [email protected] before treating them as commitments.