Security
Security & Responsible Disclosure
API keys are bcrypt-hashed and shown once. Request payloads are not logged by default. Here's how we handle data, store credentials, and what to do if you find a vulnerability.
Data Handling
Endpointwise processes API requests on behalf of platform teams. Our data handling practices are designed with the principle of minimal retention and controlled access.
- Request bodies are not logged by default. Gateway access logs capture method, path, status code, and latency — not payload content.
- Access logs are retained for 30 days. Analytics aggregates (hourly/daily rollups) are retained for 12 months.
- Customer OpenAPI spec contents are stored in an isolated namespace per organization and are not shared between organizations.
- All data is encrypted at rest using AES-256. All data in transit is protected by TLS 1.2 or higher.
API Key Storage Design
API keys issued by Endpointwise are designed with the following constraints:
- Key values are shown to the issuing user exactly once at creation time. After that, only the truncated prefix (
sk_live_abc12…) is visible — in the dashboard, in audit logs, and in API responses. - Keys are stored as bcrypt hashes. Our systems cannot retrieve the plaintext key value after creation. If a key is lost, it must be rotated, not recovered.
- Every authentication event — successful or failed — is recorded in the audit log with the key prefix, timestamp, endpoint path, and response status code.
- Keys can be scoped to specific endpoint paths and HTTP methods (
GET /v1/invoicesonly, for example), limiting the blast radius of a compromised credential. - Rotation follows an overlap-window model: old and new keys can be valid simultaneously for up to 30 days while traffic migrates, with no downtime required.
Infrastructure
We build with security controls appropriate for an API infrastructure product handling sensitive access credentials. Current implementation notes:
- Gateway components run in isolated containers with least-privilege roles. Network egress is restricted to the configured upstream service per organization.
- Internal services communicate over mTLS. External API endpoints are served exclusively over TLS 1.2+.
- Dependencies are pinned and scanned on each build. We maintain a software bill of materials (SBOM) for the gateway component.
- Access to production infrastructure requires multi-factor authentication and is limited to two engineers.
What We Don't Claim
We build with security controls in mind. We do not currently hold third-party security certifications. If your compliance requirements depend on specific third-party attestations, contact us at [email protected] to discuss your requirements directly.
Responsible Disclosure
If you believe you've found a security vulnerability in Endpointwise, we ask that you disclose it responsibly. We will work with you to understand and remediate the issue before any public disclosure.
How to report a vulnerability
Email [email protected] with subject line: Security Report: [brief description]
Include:
- A description of the vulnerability and its potential impact
- Steps to reproduce (if applicable)
- Any supporting evidence (screenshots, logs, payloads)
We aim to acknowledge reports within 2 business days and provide a remediation timeline within 7 days.
Out of Scope
- Vulnerabilities in third-party services we use (report these to those vendors directly)
- Social engineering attacks against Endpointwise employees
- Denial of service attacks against our infrastructure
- Physical attacks against our team or offices
For general security questions, contact [email protected]. For urgent issues affecting an active account, use the in-dashboard support channel.