Credential handling
Use project credentials only from a server-side secret store. Do not place a real token in client JavaScript, screenshots, tickets, or public repositories.
Transport
Public examples use HTTPS. Validate certificates, set explicit timeouts, restrict outbound destinations, and avoid logging credential values.
Least exposure
Request only needed fields, constrain access inside your system, and remove credentials and unnecessary personal fields from support evidence.
INTEGRATION CHECKLIST
Controls to confirm before launch
| Area | Public baseline | Project confirmation |
|---|---|---|
| Credentials | Placeholder-only public examples; server-side storage guidance | Format, delivery, rotation, revocation, and scope |
| Network | HTTPS public origin | Allowlist, egress, timeout, retry, and region |
| Logging | Do not expose credentials | Logged fields, access, retention, and deletion |
| Delivery | Structured API responses | Field list, export format, encryption, and recipients |
| Incidents | Status scope is explicit | Contacts, severity, notification, and evidence format |
Report a security issue
Use the public inquiry form and label the request “Security report”. Include affected route, impact, reproducible steps, timestamps, and redacted evidence. Keep real credentials and personal data out of the submission.
Machine-readable policy
The public discovery file is available at /.well-known/security.txt. It points to the same verified form and this policy page.
Project security reviewCertification materials, penetration testing, a DPA, or a security appendix can be scoped during project evaluation with the required evidence and delivery format.