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, GitHub, and Sentry tokens, PostHog personal API keys, and Stripe restricted keys are validated before encrypted storage. Logs exclude credentials, authorization headers, cookies, and 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 applies the Free project's history limits without deleting existing normalized history or disabling Stripe.
| 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.
Free tool
Generate a practical release checklist tailored to your deployment type, stack, and risk areas.
Review personal-data and analytics handling.
See the Sentry retention boundary.
Review restricted-key permissions.
Connect Vercel, GitHub, Sentry, PostHog, and Stripe for free. Choose Pro or Pro Lifetime for more project capacity and history.