Security and data boundaries
ShipTale uses provider credentials only to read the projects and event types required for release timelines. Credentials are validated before storage, encrypted at rest, excluded from application logs, and removed when an integration disconnects. ShipTale narrows retained provider data to timeline context and does not retain Sentry stack traces, breadcrumbs, or attachments.
Last reviewed:
Vercel and Sentry tokens and Stripe restricted keys are validated against provider access before they are encrypted. Application logs must not include credentials, authorization headers, cookies, or raw provider payloads. Disconnecting removes stored credentials.
Provider responses are normalized into the fields needed for timelines and release correlation. Sentry stack traces, breadcrumbs, and attachments are not retained. A downgrade hides Stripe history and stops synchronization without deleting the existing normalized history.
| Area | Supports | Does not claim or do |
|---|---|---|
| Credentials | Validated, encrypted at rest, removable on disconnect | Plaintext credentials in logs |
| Provider access | Read access required for the selected integration | Deployment, issue, or billing mutations |
| Sentry retention | Normalized issue-change context | Stack traces, breadcrumbs, or attachments |
Use the documented read permissions and select only the projects you want monitored.
ShipTale checks access before saving the encrypted credential.
Removing an integration deletes its stored credential and stops future synchronization.
These primary sources describe provider capabilities. ShipTale behavior is described separately above.
Review personal-data and analytics handling.
See the Sentry retention boundary.
Review restricted-key permissions.
Connect Vercel and Sentry free. Add Stripe customer context on Pro.