How Parsela handles your data.

Current compliance posture

Parsela is in pre-GA with active design partners. SOC 2 Type II framework is in progress. The technical controls required for certification are already implemented; the audit itself is scheduled post-GA.

Authentication & access control

Parsela uses JWT-based authentication with short-lived tokens and server-side revocation. Role-based access control (RBAC) enforces a four-tier authority matrix across every privileged endpoint: Analyst (1), Manager (2), Director (3), Admin (4). Every mutation writes a canonical audit log entry capturing actor identity, target, before/after state, and timestamp.

Data handling

Parsela processes your shipping documents to extract structured data. Here is exactly what happens to that data at each stage.

Document ingestion

Documents arrive via IMAP email polling, web upload, or REST API. At ingestion, Parsela stores the original PDF in customer-controlled object storage (AWS S3, Google Cloud Storage, or on-prem MinIO depending on deployment). Document bytes never transit uncontrolled infrastructure.

AI extraction

Extraction uses frontier AI models from Anthropic (Claude Sonnet 4 primary, Haiku 4.5 secondary). For cloud deployments, the API call is made through Anthropic's standard privacy terms (no model training on submitted data). For customers with stricter data residency requirements, Parsela can be deployed with AWS Bedrock or Google Vertex AI, keeping document data within your VPC.

Data at rest

Extracted structured data is stored in PostgreSQL (RDS for AWS, Cloud SQL for GCP, or self-hosted) with encryption at rest enabled by default. Original PDFs remain in object storage with server-side encryption. Access is limited by vendor scoping — the multi-tenant architecture ensures operators only see documents from vendors they are explicitly assigned to.

Data in transit

All external traffic uses TLS 1.2+. Internal service-to-service calls within the VPC are also TLS. Webhook delivery to your TMS includes HMAC-SHA256 signatures so your TMS can verify the payload originated from Parsela.

PII handling

Shipping documents regularly contain PII (consignee contact names, signatures on PODs). Parsela includes optional PII redaction that runs before any LLM call — controlled by the PARSELA_PII_REDACT deployment flag. When enabled, named entities are replaced with semantic placeholders before extraction, then re-associated after. Standard mode is disabled; enterprise and air-gapped modes default to enabled.

Deployment options

Different customers have different data sovereignty requirements. Parsela ships in four deployment configurations, controlled by environment variable — no code changes required to switch.

Sub-processors

Parsela uses a small set of sub-processors. Each is vetted for security posture and has a DPA in place. The list below applies to Cloud (Standard) deployments; VPC, on-premises, and air-gapped deployments have reduced or zero external sub-processors.

• Anthropic — primary AI extraction (Claude Sonnet 4, Haiku 4.5). SOC 2 Type II certified. No training on API-submitted data per Anthropic's commercial terms.
• Amazon Web Services — compute, storage (S3), queuing (SQS), and database (RDS PostgreSQL). SOC 2 Type II, ISO 27001, PCI DSS, HIPAA-eligible.
• Voyage AI — embeddings for retrieval-augmented contextual matching. Applied only to extracted field values, never to raw document bytes.
• Plausible Analytics — privacy-first web analytics for parselaai.com marketing pages only. No data collection inside the authenticated application.

Vulnerability reporting

If you believe you've found a security vulnerability in Parsela, please email [email protected] with a description and reproduction steps. We commit to acknowledging all reports within 48 hours and publishing a fix timeline within 7 days. Responsible disclosure is appreciated and we're happy to discuss bounty arrangements for substantive findings.