Erasure requests · checked
How to carry an erasure request through your sub-processors
Not legal advice. When a person asks you to erase their data (GDPR Art. 17), deleting it from your own database is half the job: every sub-processor that holds a copy has to delete it too, and you answer the person within one month. Each vendor does it differently (an API call, a dashboard page, an email to its privacy team), and some never tell you it is done. The map below gives the route at 69 vendors, from each one's own documentation, with the day it was read.
$ npx --allow-remote=root https://agentwares.vercel.app/dl/subprocessors-0.1.1.tgz erasure
Reads your repository on your machine, finds the vendors your code uses, and prints this checklist for those vendors only: the steps at each, its retention, whether it confirms, and which ones will not. It calls no vendor and deletes nothing; --md gives a task list to paste into a ticket, --json the same for an agent.
Six steps
- Record the request. Who asked, for what, and the day it arrived. GDPR Art. 12(3) gives you one month from receipt to act and tell the person, extendable by two more months where necessary.
- Check what you must keep. Art. 17(3) lets you keep data you hold for a legal obligation, such as invoices; note what you keep and why.
- Delete it in your own systems first: your database, file storage and any logs you keep. Note the ID each vendor knows the person by: a customer ID, a user ID, an email address.
- Then at each sub-processor that holds a copy, by the route its documentation gives: an API call, a dashboard page, or a request to its privacy team. The map below has the route for each vendor it covers.
- Get the confirmation, or record that none came. Where a vendor confirms, keep what it returns. Where it does not, look the data up again after the deletion; where its documentation does not say, ask in writing.
- Tell the person what you did, within the month, and keep the record: per vendor, what was deleted, on which day, and its confirmation or its absence.
The erasure map
For each vendor: how one person's data is deleted there, the default retention its documentation states for that data, and whether it tells you the deletion is done. "Yes" means its documentation says the delete call reports the deletion, a status reaches done, or it sends a confirmation.
| Vendor | How to delete one person's data | Default retention | Confirms? | Source |
|---|---|---|---|---|
| Hosting | ||||
| Vercel | Delete the person's files from Vercel Blob with the SDK's del(urlOrPathname), which takes a URL, a pathname or an array of them; cached copies can take up to one minute to leave the Vercel CDN. Runtime logs (which hold request IP addresses) have no per-person delete in the docs: they expire after the plan's retention. For anything you cannot delete through the self-service functionality, ask Vercel for assistance under section 11 (Data Subject Requests) of its DPA.del() returns a void response, and a delete action won't throw if the blob URL doesn't exist. | Runtime logs: 1 hour on Hobby, 1 day on Pro, 3 days on Enterprise, 30 days with Observability Plus; Web Analytics visitor sessions are discarded after 24 hours. | Not documentedask in writing | docsread 10 October 2026 |
| Cloudflare | Delete the person's KV keys with env.NAMESPACE.delete(key) in a Worker or the REST endpoint below, and their R2 objects with the R2 binding's delete(key). Workers Logs have no per-person delete in the docs: they are retained 3 days on Workers Free and 7 days on Workers Paid. For anything you cannot remove yourself, Cloudflare's customer DPA commits it to reasonable assistance with data subject requests, including erasure.DELETE /accounts/{account_id}/storage/kv/namespaces/{namespace_id}/values/{key_name}R2 deletes are strongly consistent once the promise resolves, but a deleted KV key may take some time to disappear from every point of Cloudflare's network, and D1 Time Travel can restore a database up to 30 days back (7 on Free). | Workers Logs: 3 days on Workers Free, 7 days on Workers Paid; D1 Time Travel restore window: 30 days (Paid), 7 days (Free). | Not documentedask in writing | docsread 10 October 2026 |
| Netlify | Delete the person's Netlify Forms submissions with DELETE /api/v1/submissions/{submission_id} (or tick them in the form's submissions list and select Delete submission), and their Netlify Blobs entries with store.delete(key). The docs offer no per-person deletion of function or edge function logs; they expire with the plan's log retention. If the person writes to Netlify directly, Netlify refers the request to you as the customer; privacy questions go to privacy@netlify.com.DELETE /api/v1/submissions/{submission_id}Blobs deletions reach all edge locations within 60 seconds, and after you delete a form its file uploads stay reachable by direct URL for 24 hours. | Function logs: at least 24 hours, up to 7 days on certain plans | Not documentedask in writing | docsread 10 October 2026 |
| Fly.io | Delete the person's records in your app's data on the Fly Volume; the volume's automatic daily snapshots keep them until each snapshot's retention ends, because snapshots are only removed at the end of their retention periods (flyctl offers only create and list for snapshots). The docs offer no per-person deletion of logs; Fly's log search keeps them 7 days. Destroying the volume with fly volumes destroy permanently deletes its data, but snapshots taken before deletion stay restorable for their retention period.Changing a volume's snapshot retention applies only to new snapshots, so existing snapshots keep their original period. | Volume snapshots: 5 days by default (settable 1 to 60 days); log search: 7 days | Not documentedask in writing | docsread 10 October 2026 |
| Render | Delete the person's rows in your Render Postgres database yourself; they stay recoverable through point-in-time recovery for the plan's recovery window and in logical backups for seven days. The docs offer no per-person deletion of logs; they expire after the workspace plan's log retention period. Deleting the whole database (its Info page > Delete Database) also removes its backups and snapshots. | Logs: Hobby 7 days, Pro 14 days, Scale/Enterprise 30 days; Postgres point-in-time recovery: Hobby 3 days, Pro or higher 7 days; logical backups: 7 days | Not documentedask in writing | docsread 10 October 2026 |
| Railway | Delete the person's rows in your database on the Railway volume, then delete any backups that still hold them from the service's Backups tab; scheduled backups otherwise expire on their schedule. The docs offer no per-person deletion of logs; they expire after the plan's log retention. A deleted volume is queued and permanently deleted within 48 hours.Upgrading the plan immediately restores logs that were outside the old retention period, so logs past retention are not necessarily gone. | Logs: Free 3 days, Trial and Hobby 7 days, Pro 30 days, Enterprise up to 90 days; volume backups: daily kept 6 days, weekly 27 days, monthly 89 days | Not documentedask in writing | docsread 10 October 2026 |
| Cloud infrastructure | ||||
| DigitalOcean | Delete the person's data inside your Droplet, volume or database yourself (DigitalOcean's DPA points customers to its self-service features), and delete their files from Spaces with the S3-compatible DeleteObject request. Copies stay in Droplet backups until those expire: destroying a Droplet does not destroy its automated backups, and its snapshots and volumes are destroyed with it only if you select them. Deleting a volume or destroying a Droplet is irreversible.On account deactivation DigitalOcean deletes all Personal Data within 30 days, but may keep data archived on back-up systems until their automated retention and disposal removes it. | Droplet backups: weekly kept four weeks, daily seven days, usage-based a custom period | Not documentedask in writing | docsread 10 October 2026 |
| Amazon Web Services | Delete the person's S3 objects with DeleteObject; in a versioned bucket include each version's versionId, because without it S3 only inserts a delete marker. Delete their DynamoDB items with DeleteItem (by primary key) and remove their address from the SES suppression list with DeleteSuppressedDestination. AWS states that you control your content and that it provides capabilities to delete it.DELETE /Key+?versionId=VersionIdDeleteObject returns HTTP 204 on success; in a versioned bucket a delete without versionId only inserts a delete marker that becomes the object's current version. | SQS messages: 4 days by default (60 seconds to 14 days); DynamoDB point-in-time recovery: up to 35 days of recovery points. | Not documentedask in writing | docsread 10 October 2026 |
| Google Cloud | Delete the person's Cloud Storage objects with objects.delete; in a bucket with a soft delete policy (on by default) the object becomes soft deleted, stays restorable until its hardDeleteTime, and this API cannot delete it permanently sooner. In BigQuery, data you delete stays recoverable through the time travel window (seven days by default) and then a further seven-day fail-safe period. Google Cloud commits to delete customer data within about six months (180 days), backups included.DELETE https://storage.googleapis.com/storage/v1/b/bucket/o/objectDeletion from Google's active systems generally takes about two months and from data center backups up to six months after the deletion request. | Cloud Storage soft delete: 7 days by default (7 to 90 days configurable); BigQuery time travel: 7 days by default, plus 7 days fail-safe | Not documentedask in writing | docsread 10 October 2026 |
| Microsoft Azure | Delete the person's blobs with the Delete Blob operation; with blob soft delete on (the default for storage accounts created in the Azure portal) they stay restorable until the retention period you set elapses, then are permanently deleted. Data that Azure OpenAI features store for you (Files API, Responses API, Assistants threads, stored completions) can be deleted by the customer at any time. The docs offer no customer deletion of prompts and completions held in the abuse-monitoring data store for human review; only approval for modified abuse monitoring stops that storage.DELETE https://myaccount.blob.core.windows.net/mycontainer/myblobA successful Delete Blob returns 202 (Accepted), not a completed-deletion status. | Blob soft delete: retention period you set between 1 and 365 days (on by default for portal-created accounts) | Not documentedask in writing | docsread 10 October 2026 |
| Database | ||||
| Neon | Delete the person's rows with SQL DELETE ... WHERE ... on every branch that holds them, since a branch is a copy-on-write clone of your data. The rows stay in Neon's change history until they fall outside the project's history window (set with the History window slider), and in snapshots: scheduled ones are kept up to 35 days and manual ones never expire unless given an expiration, so delete those snapshots too.The DELETE statement returns the number of rows deleted; the rows stay in the history window and in snapshots until those age out, and in Neon's own customer-data backups for 30 days. | History window: 6 hours on Free; 1 day by default on Launch and Scale (up to 7 and 30 days); scheduled snapshots 35 days; Neon's own backups 30 days. | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Supabase | Delete the person's Storage files through the Storage API with supabase.storage.from(bucket).remove(paths), not with SQL, which only orphans them; an Auth user who still owns Storage objects cannot be deleted. Then delete the Auth user on the server with auth.admin.deleteUser(id) and a service_role key (or in the dashboard at Authentication > Users), and delete their rows in your own tables with .delete() plus filters.Storage's remove() returns an array of FileObject entries for the deleted files, while deleted rows stay in daily database backups for the plan's backup window. | Daily database backups: 7 days on Pro, 14 days on Team, up to 30 days on Enterprise; backups do not include Storage objects. | Not documentedask in writing | docsread 10 October 2026 |
| PlanetScale | Delete the person's rows yourself, then delete the backups that still hold them with pscale backup delete <DATABASE_NAME> <BRANCH_NAME> <BACKUP_ID> or the Delete a backup API call, and delete any branch that copied the data with pscale branch delete <DATABASE_NAME> <BRANCH_NAME>. Otherwise the default PlanetScale Postgres backups are kept 2 days, and Postgres point-in-time recovery can restore any moment back to the oldest backup.DELETE https://api.planetscale.com/v1/organizations/{organization}/databases/{database}/branches/{branch}/backups/{id}Custom-schedule and manual backups can carry longer retention, and any backup can be protected from deletion with the Prevent backup deletion toggle. | Postgres: default backups every 12 hours, kept 2 days, WAL kept as long as the oldest backup; Vitess: backups every 12 hours on the Base plan, retention not stated | Not documentedask in writing | docsread 10 October 2026 |
| Turso | Delete the person's rows with SQL DELETE; point-in-time recovery keeps restorable history for the plan's window, and the docs offer no way to purge one person from it short of deleting the database. Deleting the database (DELETE /v1/organizations/{organizationSlug}/databases/{databaseName}) still leaves it restorable for up to five days on paid plans; turning off the Allow restore toggle makes restores fail, but the deleted database stays listed until the five-day window ends.DELETE /v1/organizations/{organizationSlug}/databases/{databaseName}The Delete Database response names the database that was deleted, but on paid plans it remains restorable for five days. | Point-in-time recovery: Free 24 hours, Developer 10 days, Scaler 30 days, Pro 90 days; deleted databases: restorable 5 days on paid plans | Not documentedask in writing | docsread 10 October 2026 |
| MongoDB Atlas | Delete the person's documents yourself, then delete each backup snapshot that still holds them with atlas backups snapshots delete <snapshotId>, the Atlas Administration API or the Atlas UI; otherwise snapshots expire on the cluster's backup policy. If a Backup Compliance Policy is enabled you can't delete a backup snapshot, so the data stays until those snapshots expire.DELETE /api/atlas/v2/groups/{groupId}/clusters/{clusterName}/backup/snapshots/{snapshotId}Deleting a snapshot is permanent, and to remove every copy under a multi-region Snapshot Distribution policy you delete it from its original region. | Default backup policy: hourly snapshots kept 7 days, daily 7 days, weekly 4 weeks, monthly 12 months, yearly 1 year | Not documentedask in writing | docsread 10 October 2026 |
| Firebase (Google) | Delete the person's Authentication account with the Admin SDK's deleteUser(uid). Delete their Cloud Firestore, Realtime Database and Cloud Storage data yourself or with the Delete User Data extension, which deletes data keyed on the user ID when the user is deleted from Firebase Authentication. Deleted Firestore data stays readable through point-in-time recovery (1 hour with PITR off, 7 days with it on) and in any scheduled backups until they expire or you delete them.deleteUser returns an empty result once the deletion completes and throws an error otherwise; Firebase Extensions, which include Delete User Data, shut down on March 31, 2027. | Firestore point-in-time data: 1 hour with PITR disabled, 7 days with PITR enabled; scheduled Firestore backups: retention up to 14 weeks | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Cache and queues | ||||
| Upstash | Delete the person's Redis keys with DEL. Delete any Redis backups that still hold them from the database's Backups tab; daily backups are otherwise stored 1 or 3 days. For QStash, delete their failed messages from the DLQ (DELETE /v2/dlq/{dlqId}); the docs offer no per-message deletion of QStash logs, which expire with the plan's log retention.DEL's reply counts the keys that were really removed; copies in Redis backups and QStash logs remain until they expire or the backup is deleted. | Redis daily backups (opt-in): 1 or 3 days; QStash logs: Free 3 days, Pay as you go 7 days, Fixed 1M and 10M 14 days; QStash DLQ: Free 3 days, Pay as you go 7 days, Fixed 1M 30 days, Fixed 10M 3 months | Yeskeep what it returns or sends | docsread 10 October 2026 |
| File storage | ||||
| Cloudinary | Delete the person's assets with the Admin API's Delete resources method (DELETE /resources/:resource_type/:type with their public_ids), or one at a time with the Upload API's destroy method. Pass invalidate=true so cached CDN copies are invalidated; Cloudinary says that parameter is off by default and is enabled through a support request. If automatic backup is enabled, also delete the asset's backed-up versions with DELETE /resources/backup/:asset_id.DELETE /resources/:resource_type/:typeThe documented response maps each public ID to "deleted"; with automatic backup enabled a deleted asset can still be restored from backup until its backed-up versions are deleted. | not stated | Yeskeep what it returns or sends | docsread 10 October 2026 |
| UploadThing | Call utapi.deleteFiles with the fileKeys (or customIds, with keyType: "customId") of every file the person uploaded, or POST /v6/deleteFiles with fileKeys or customIds. The API marks the files for deletion, and UploadThing deletes them at the storage provider shortly after.POST /v6/deleteFilesThe documented 200 response ({ success, deletedCount }) means the files were successfully marked for deletion, not that the storage provider has deleted them. | not stated | Not documentedask in writing | docsread 10 October 2026 |
| Mux | Delete each video asset of the person with DELETE /video/v1/assets/{ASSET_ID}, and listen for the video.asset.deleted webhook. For Mux Data viewer data, email an erasure request to gdpr@mux.com.DELETE /video/v1/assets/{ASSET_ID}The video.asset.deleted webhook reports that the asset has been deleted; for Mux Data, Mux replies that the viewer's data is being removed, if any can be identified. | Mux Data pseudonymized view data: up to 100 days | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Payments | ||||
| Stripe | Delete the person's Customer with DELETE /v1/customers/:id, which also cancels their active subscriptions. For a consumer deletion request Stripe recommends a redaction job instead (public preview): create one on the customer with POST /v1/privacy/redaction_jobs, resolve any validation errors, then run it.DELETE /v1/customers/:idThe delete returns an object with a deleted parameter, but the deleted Customer stays retrievable through the API to track its history; a redaction job reports status succeeded when done, can take up to 30 days, cannot redact most transactions until 90 days after creation, and Stripe may still retain data as legally required. | not stated | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Paddle | Send the buyer to Paddle's Request Data Deletion form (https://preferences.paddle.com/form/deletion); Paddle and you are independent controllers, so Paddle deletes only the buyer data it holds. The Paddle API cannot delete a customer, only archive it.Paddle sends its confirmation to the buyer, not to you, and keeps certain transactional data for five years. | not stated | Not documentedask in writing | docsread 10 October 2026 |
| Lemon Squeezy | The docs offer no way to delete a customer: the API only archives one (PATCH /v1/customers/:id with status archived, which stops marketing emails). Ask Lemon Squeezy to delete the person's data under its DPA, which commits it to help with data subject requests (the privacy policy's contact address is hello@lemonsqueezy.com), or have the person request deletion under Lemon Squeezy's privacy policy.Lemon Squeezy may retain personal information to meet a legal, accounting or reporting obligation. | not stated | Not documentedask in writing | docsread 10 October 2026 |
| Email delivery | ||||
| Resend | Delete the person's contact with DELETE /contacts/:contact_id, passing either the contact ID or their email. Sent emails (content, metadata, delivery events, logs) are kept for 30 days on Free, Pro and Scale; to have a specific message removed before that window ends, contact Resend via the "contact us" link on its GDPR page.DELETE /contacts/:contact_idThe contact delete returns the contact ID with deleted: true, while sent-message data only expires after 30 days unless Resend removes it on request, and after account termination remaining data is deleted within 90 days with backups persisting for 7 days. | Email content, metadata, delivery events and logs: 30 days on Free, Pro and Scale; Enterprise flexible | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Twilio SendGrid | Call the Recipients' Data Erasure API with the person's email address; it deletes their names, email addresses, subject lines, categories and IP addresses for the calling account only (use the on-behalf-of header for each Subuser). If they are a Marketing Campaigns contact, also delete the contact with DELETE /v3/marketing/contacts?ids={contact_id}. The erasure API is not enabled for every account: if the recipients.erasejob scopes are missing, ask SendGrid Support to enable them.POST /v3/recipients/erasejobThe erasure call returns 202 'accepted for processing' with a job_id, and contact deletion jobs are processed asynchronously. | Most personal data incl. recipient data: max 37 days; sent-email events: up to a year for security and fraud detection | Not documentedask in writing | docsread 10 October 2026 |
| Postmark | Ask Postmark support to enable the Data Removal API (it is available by request only), then POST /data-removals with your account token, RequestedBy (you) and RequestedFor (the person's email). Without the API, email support@postmarkapp.com to request deletion of the person's data.POST /data-removalsThe request's status reads Pending until the removal completes and then Done, and NotifyWhenCompleted emails RequestedBy when it is complete. | Email content, events and metadata: 45 days by default (7 to 365 days with the Retention Add-on) | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Mailgun | Mailgun documents no per-recipient erase call: stored message bodies and message metadata are removed automatically after their retention period. Remove the person's suppression records, e.g. DELETE /v3/{domain_name}/unsubscribes/{address} and DELETE /v3/{domain_name}/bounces/{address}; removed suppressions are permanently deleted.DELETE /v3/{domain_name}/unsubscribes/{address}Removed suppressions may stay in a disaster-recovery backup for up to 30 days. | Message bodies: up to 7 days; message metadata (sender, recipients, subject, IP): 30 days; suppressions: until you remove them | Not documentedask in writing | docsread 10 October 2026 |
| Loops | Delete the contact with POST /v1/contacts/delete (base https://app.loops.so/api), passing either email or userId. Or in the app, on the Audience page click the ••• menu on the contact and select Delete.POST /v1/contacts/deleteA successful call returns 200 'Successful delete.' with success: true and the message "Contact deleted.". | not stated | Yeskeep what it returns or sends | docsread 10 October 2026 |
| SMS and voice | ||||
| Twilio | Delete each of the person's messages with a DELETE on the Message resource (this also deletes its Media and MessageFeedback) and each call recording with DELETE https://api.twilio.com/2010-04-01/Accounts/{AccountSid}/Recordings/{Sid}.json. To delete many recordings, use Twilio Console > Monitor > Logs > Voice > Call recordings.DELETE https://api.twilio.com/2010-04-01/Accounts/{AccountSid}/Messages/{Sid}.jsonMessage bodies may persist up to 30 days in database backups after the DELETE, and a deleted recording's metadata is kept for 40 days. | Message logs and API: 13 months after creation; older records stay backed up for Bulk Export, except media (changelog, Oct 2020) | Not documentedask in writing | docsread 10 October 2026 |
| LLM inference | ||||
| Anthropic | Anthropic does not support ad hoc deletion of API inputs and outputs: it deletes them on its backend within 30 days of receipt or generation (up to 2 years if flagged as a Usage Policy violation). Delete any file you uploaded for the person with DELETE /v1/files/{file_id}.DELETE /v1/files/{file_id}The Files delete returns a DeletedFile with type "file_deleted", but deleted files may persist in active Messages API calls and are then deleted in accordance with Anthropic's data retention policy. | API inputs/outputs: deleted within 30 days; up to 2 years if flagged as a Usage Policy violation; Files API files: until deleted or expires_at | Yeskeep what it returns or sends | docsread 10 October 2026 |
| OpenAI | Delete each stored object that holds the person's data by its ID: responses (DELETE /responses/{response_id}), stored chat completions, conversations and then each of their items (deleting a conversation leaves its items), files and vector stores. Abuse monitoring logs, which can contain prompts and responses, are given a retention period (up to 30 days), not a deletion route.DELETE /responses/{response_id}The response delete returns {"object": "response.deleted", "deleted": true}, but Assistants API objects (including vector stores) are only removed from OpenAI's servers 30 days after you delete them. | Abuse monitoring logs: up to 30 days; stored Responses: at least 30 days by default; Assistants API objects: removed 30 days after you delete them | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Google Gemini API | Delete the person's stored interactions with DELETE /v1beta/interactions/{interactionsId} (or from the Logs page in AI Studio), and their uploaded files with files.delete; uploaded files are also deleted automatically after 48 hours. The docs give no per-person delete for the prompts and responses Google logs for 55 days for abuse monitoring. Deleting a tuned model also deletes its tuning content.DELETE /v1beta/interactions/{interactionsId}On unpaid quota outside the EEA, Switzerland and the UK, Google uses prompts and responses to improve its products and says not to submit personal information. | Abuse-monitoring logs: 55 days; stored interactions: 55 days (paid tier), 1 day (free tier); AI Studio logs: 55 days by default; uploaded files: 48 hours | Not documentedask in writing | docsread 10 October 2026 |
| Mistral AI | Delete files holding the person's data (including fine-tuning data) with DELETE /v1/files/{file_id} and stored conversations with DELETE /v1/conversations/{conversation_id}. Inputs and outputs of other API calls are kept 30 rolling days for abuse monitoring (not at all under zero data retention) and the docs give no per-request delete for them; for anything else, ask Mistral for assistance under DPA section 4.2.DELETE /v1/files/{file_id}The file delete returns the file id with deleted: true, documented as the deletion status. | API inputs/outputs: 30 rolling days for abuse monitoring (none with ZDR); Agents API: until account termination; fine-tuning data: until you delete it | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Cohere | Delete any dataset holding the person's data with DELETE /v1/datasets/{id} or in the Dashboard. The docs give no per-person delete for logged prompts and generations: they are deleted automatically after 30 days, and you can ask for deletion by emailing privacy@cohere.com.DELETE /v1/datasets/{id}Prompts and generations can be kept past 30 days for a legal requirement, a customer contract, or usage flagged as violating Cohere's terms. | Logged prompts and generations: 30 days (none with approved zero data retention); datasets: 30 days after creation | Not documentedask in writing | docsread 10 October 2026 |
| xAI | Delete the person's stored Responses with DELETE /v1/responses/{response_id} and their uploaded files with DELETE /v1/files/{file_id}. All API requests and responses are also kept 30 days for abuse auditing and then deleted automatically; the docs give no per-person delete for that copy.DELETE /v1/responses/{response_id}Both deletes return the object's id with deleted: true; after a file delete the file no longer appears in GET /v1/files and its download returns 404. | API requests and responses: 30 days (not with ZDR); stored responses: 30 days | Yeskeep what it returns or sends | docsread 10 October 2026 |
| OpenRouter | OpenRouter stores prompts and responses only if you opted in to Input & Output Logging (or to OpenRouter's use of your inputs/outputs). If you did, email support@openrouter.ai to request deletion of the stored data. The provider the request was routed to is a further recipient with its own logging and retention policy, so handle deletion there too.Logged data may be kept beyond 3 months at OpenRouter's discretion unless you request deletion. | Prompts and responses: not stored by default; with Input & Output Logging on, at least 3 months | Not documentedask in writing | docsread 10 October 2026 |
| Together AI | Delete stored prompts and responses with the delete option in settings, or email privacy@together.ai with a deletion request; they are stored by default unless Store prompts and model responses is set to No. Delete fine-tuning or batch files holding the person's data with DELETE /files/{id}. Passthrough models send data to the upstream provider, which handles it under its own policy.DELETE /files/{id}The file delete's 200 response is documented as File deleted successfully and returns id and deleted; this applies to files, not to the settings or email route for stored prompts. | Prompts and responses: stored by default (no period stated); uploaded files: until you delete them | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Replicate | For predictions created through the API, inputs, outputs, output files and logs are removed automatically after an hour by default, so no per-person step is needed. Predictions created on the website are kept indefinitely: delete them from your dashboard with the Delete button on the prediction page.A prediction's data_removed field is true once its input and output data has been deleted. | API predictions: 1 hour; web predictions: indefinitely | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Hugging Face | Inference Providers does not store request bodies or responses, so there is nothing per person to delete at Hugging Face; the provider that served the request handles data under its own policy. Inference Endpoints does not store payloads but keeps logs for 30 days, and the docs give no per-person log deletion; send any erasure request to privacy@huggingface.co. | Logs: up to 30 days with no user data (Inference Providers); 30 days (Inference Endpoints) | Not documentedask in writing | docsread 10 October 2026 |
| AI speech and media | ||||
| ElevenLabs | Delete each of the person's generations with DELETE https://api.elevenlabs.io/v1/history/{history_item_id} (find them with the Get generated items endpoint), and their agent conversations with DELETE https://api.elevenlabs.io/v1/convai/conversations/{conversation_id}. To keep new API requests out of history, select Enterprise customers can send enable_logging=false (Zero Retention Mode).DELETE https://api.elevenlabs.io/v1/history/{history_item_id}A successful delete returns status 'ok' and immediately removes the audio and text from the database, but debugging and moderation logs may still hold related data and backups keep deleted items for up to 30 days. | Generation history: kept by default (history preservation enabled); agent conversations: 2 years by default | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Deepgram | Deepgram documents no deletion API or self-serve deletion: it retains request audio and transcripts for its Model Improvement Program by default and deletes Customer Data only at the customer's request, so send that request to Deepgram (its privacy notice's contact is security@deepgram.com). To stop retaining new data, add mip_opt_out=true to every request.Request metadata and usage logs, which contain no audio, text or transcripts, stay retrievable for 90 days. | Audio and transcripts: retained for model improvement by default (no period stated); with mip_opt_out=true, only for the duration needed to process the request | Not documentedask in writing | docsread 10 October 2026 |
| Vector database | ||||
| Pinecone | Delete the person's records by ID or by a metadata filter with POST /vectors/delete in each namespace that holds them. An index with a document schema uses the Documents API delete instead. If the person has their own namespace, delete the whole namespace, and deal with any backup taken before the delete, since a backup is a static copy of the index.POST /vectors/deletePinecone is eventually consistent: the delete response carries an x-pinecone-request-lsn header, and a query whose x-pinecone-max-indexed-lsn is at least that value reflects the delete. | not stated | Not documentedask in writing | docsread 10 October 2026 |
| Error monitoring | ||||
| Sentry | Sentry cannot delete a single event: delete the issue that holds the person's events (trash icon on the Issue Details page, or DELETE /api/0/organizations/{organization_id_or_slug}/issues/{issue_id}/), and if their data was sent as a tag, remove it under Project Settings > Tags. If the data is spread across many issues, Sentry's docs say you may need to delete and re-create the project; its security page also says data can be deleted upon request.DELETE /api/0/organizations/{organization_id_or_slug}/issues/{issue_id}/The issue delete API only queues the issue for asynchronous deletion, and Sentry deletes its backups of event data 90 days after creation. | Errors: 30 days on Developer, 90 days on Team and Business/Enterprise; backups deleted 90 days after creation | Not documentedask in writing | docsread 10 October 2026 |
| Logs and observability | ||||
| Datadog | For logs, have an Org Admin toggle on Logs Data Deletion (Organization Settings > Preferences); then under Organization Settings > Data Deletion select the Logs product and a time frame, query for the person's events, click Delete and Confirm. To delete data from any other Datadog product, contact Datadog Support (https://www.datadoghq.com/support/).The Deletion History tab shows each job's status (for example Done (Recoverable)); deleted logs stay recoverable for 10 days before deletion is permanent, and data derived from them, such as metrics generated from logs, is not deleted. | Logs: determined by customer plan | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Better Stack | Better Stack's docs offer no way to delete one person's logs: logs expire after the source's logs_retention (in days), or you can delete the whole source (DELETE https://telemetry.betterstack.com/api/v2/sources/{source_id}). For a single data subject, ask Better Stack (hello@betterstack.com), whose DPA commits it to reasonable assistance with data subjects' erasure and deletion requests. | Logs: 3 days on the included free volume; 30 days in every Telemetry bundle; set per source in days | Not documentedask in writing | docsread 10 October 2026 |
| Axiom | Axiom's docs offer no per-event or per-person deletion: trim the dataset (Settings > Datasets and views > Trim dataset, or POST /v1/datasets/{dataset_name}/trim), which deletes data blocks older than a date you pick, shorten the dataset's retention, or delete the dataset. For help with one person's erasure request, write to privacy@axiom.co under the DPA, which commits Axiom to assist with data subject requests (it may charge a reasonable fee).A trim returns 200 once queued and can take hours, its result cannot tell you how much was deleted (query the trimmed time range or poll the dataset info endpoint), and deleting a field only hides its values, which stay in storage. | Personal plan: 30 days by default, shorter only; Axiom Cloud: any period per dataset, including Forever | Nolook the data up again afterwards | docsread 10 October 2026 |
| Langfuse | Find the person's traces (for example by their userId) and delete them: in the UI, filter the traces list, select all items and choose Delete in the Actions dropdown, or call DELETE /api/public/traces with a JSON body {"traceIds": [...]}. Trace deletion also removes their observations and scores but not datasets, so delete any dataset items holding their data as well.DELETE /api/public/tracesTrace deletion is asynchronous, usually done within 15 minutes of the delete call; to verify, query the data again. | Kept until deleted unless a project data-retention policy (minimum 3 days) is set | Nolook the data up again afterwards | docsread 10 October 2026 |
| Helicone | Helicone's docs offer no API or dashboard deletion of individual logged requests; logs are kept for the plan's retention period. Email help@helicone.ai, the address its privacy policy gives for having personal data removed, and use Omit Logs to stop storing request and response bodies. | Request logs: Hobby 7 days, Pro 1 month, Team 3 months, Enterprise forever | Not documentedask in writing | docsread 10 October 2026 |
| Product analytics | ||||
| PostHog | Call DELETE /api/projects/:project_id/persons/:id with the person's UUID and add delete_events=true (plus delete_recordings=true for their session recordings); in the UI, select Persons, find the person, click view, then Delete person. Event deletion runs asynchronously, so poll the persons deletion status endpoint until it reports completed.DELETE /api/projects/:project_id/persons/:idThe person is removed during the request (empty 202) but events are cleared asynchronously during non-peak hours (weekends on PostHog Cloud), and the deletion status endpoint reports pending or completed with delete_verified_at. | Events: 1 year on Free, 7 years on paid plans (PostHog Cloud); recordings: up to 30 days on Free, up to 90 days on pay-as-you-go, longer with add-ons | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Mixpanel | Submit a GDPR deletion for the person's distinct_id: in Mixpanel go to Organization Settings > Data & Privacy and click Request Deletion, or call the GDPR API with a GDPR OAuth token. Poll GET https://mixpanel.com/api/app/data-deletions/v3.0/<tracking_id>?token=<your_project_token> until the status is SUCCESS, or ask Mixpanel to enable signed status callbacks.POST https://mixpanel.com/api/app/data-deletions/v3.0/?token=<your_project_token>A deletion can take up to 30 days, the status endpoint's SUCCESS means "The deletion task is complete", and Mixpanel may keep records of deletion tasks for legal compliance. | Events: deleted after 2 years (5 years for projects created before 1 Sep 2025 until they change plan or move to Free); user profiles: for the duration of the subscription | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Amplitude | POST the person's user_ids or amplitude_ids to the User Privacy API at https://amplitude.com/api/2/deletions/users, with delete_from_org set to true to cover every project (v2, in beta: POST https://privacy.amplitude.com/api/user-deletions/org/{orgId}/requests). Then list deletion jobs with GET /api/2/deletions/users?start_day=YYYY-MM-DD&end_day=YYYY-MM-DD until the job's status is done.POST /api/2/deletions/usersDeletion runs as a scheduled batch job within 30 days, and the job's status changes to done only after backups are removed (Amplitude waits 5 days after the scrub); account admins are emailed when the request is made. | not stated | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Twilio Segment | Create a SUPPRESS_WITH_DELETE (or DELETE_ONLY) regulation for the person's userId, in the Segment app under Settings > End User Privacy or with the Public API (POST /regulations). Check its status under Privacy > Deletion and Suppression > Deletion or through the API, and contact any destination that does not support programmatic deletion yourself.POST /regulationsThe API reports one overall status (FINISHED when done, but FAILED if an unsupported destination failed even when Segment's own deletion succeeded), and the 30-day SLA covers only Segment's internal stores, not your warehouse, S3 or other destinations. | Archive event data: 3 years on Business, 365 days on Team, 180 days on Free | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Google Analytics | Call the Admin API's properties.submitUserDeletion with the person's userId, clientId, appInstanceId or userProvidedData (the legacy userDeletionRequests:upsert API was sunset with Universal Analytics). Or in Explore, open a user explorer, select the person's ID in the "Effective user ID" column, click the Delete user icon, then Delete.POST https://analyticsadmin.googleapis.com/v1alpha/{name=properties/*}:submitUserDeletionThe API response carries only deletionRequestTime (when the request was received); a deletion from the user explorer stops showing within 24 hours and is permanently removed within the next 63 days. | User-level data: 2 or 14 months, as set in Data Retention; expired data is deleted monthly | Not documentedask in writing | docsread 10 October 2026 |
| Plausible Analytics | Plausible offers no per-person deletion: it stores event and session records but no raw IP addresses or User-Agent strings, and custom property values can't be deleted on their own. If personal data was sent (for example in a custom property), the only way to remove it is to reset the site's stats (website settings > Danger zone > Reset) or delete the site.Unique visitors are counted with a daily hash whose salt is rotated and deleted every 24 hours, and a reset removes all of the site's stats, not one person's. | not stated | Not documentedask in writing | docsread 10 October 2026 |
| Authentication | ||||
| Clerk | Delete the user with the Backend API's DELETE /users/{user_id} (or the SDK's deleteUser()); in the Clerk Dashboard, go to Users, select the user, open the Actions dropdown and select Delete user.DELETE /users/{user_id}The Backend API's 200 response is a DeletedObject, which Clerk describes as an item that has been deleted from the database, with a deleted boolean. | Dashboard Application Logs and Email Logs: 1 day on Hobby, 7 days on Pro, 30 days on Business | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Auth0 (Okta) | Delete the user with DELETE /api/v2/users/{id} on the Management API, or in Auth0 Dashboard > User Management > Users click Actions > Delete User. Erase the person yourself from any other databases Auth0 is not connected to.DELETE /api/v2/users/{id}The documented response is 204 "User successfully deleted." and the action cannot be undone. | Tenant logs: 1 day Starter, 5 days Essentials, 10 days Professional, 30 days Enterprise | Yeskeep what it returns or sends | docsread 10 October 2026 |
| WorkOS | Delete the user with DELETE /user_management/users/:id; it is permanent. For Directory Sync data, deleting the directory deletes its users and groups in WorkOS. For anything else, reach out to WorkOS support (the docs link support@workos.com) to request deletion of data.DELETE /user_management/users/:id | Audit Log Events: 30 days by default, configurable per organization | Not documentedask in writing | docsread 10 October 2026 |
| Customer support | ||||
| Intercom | Go to Settings > Data > People > Delete Data, enter the person's user ID or email, select them and click 'Permanently delete'. Or call DELETE /contacts/{contact_id} with their Intercom user ID.DELETE /contacts/{contact_id}The API response is the contact with deleted: true; Intercom can still retrieve a mistaken deletion for 7 days, after which the data is permanently destroyed, and CSAT ratings and comments are not deleted. | Visitors not seen in 9 months: data expired automatically | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Crisp | In Crisp, go to Contacts, find the person, select their profile, open Actions and click Remove selected profiles; then delete their conversations from the Inbox list. By API: DELETE /v1/website/{website_id}/people/profile/{people_id} (the people email is also allowed) and DELETE /v1/website/{website_id}/conversation/{session_id}.DELETE /v1/website/{website_id}/people/profile/{people_id}Crisp's encrypted platform backups are retained for a maximum of 1 week. | Conversations: kept until you delete them (not deleted automatically) | Not documentedask in writing | docsread 10 October 2026 |
| Team messaging | ||||
| Slack | Delete each message your app posted with chat.delete (channel and ts); a bot token deletes only that bot's messages, and a user token deletes only messages that user can delete in Slack. Incoming webhooks cannot delete a message once posted (Slack says to use chat.postMessage if you need deletion); the workspace's retention settings can auto-delete all messages after a set time.POST https://slack.com/api/chat.deleteA successful call returns ok: true with the channel and timestamp of the deleted message. | Paid plans: kept for the workspace's lifetime by default (adjustable); free plan: 90 days or one year | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Discord | Delete each message the webhook sent with DELETE /webhooks/{webhook.id}/{webhook.token}/messages/{message.id}, adding thread_id if the message is in a thread. It deletes only messages created by that webhook.DELETE /webhooks/{webhook.id}/{webhook.token}/messages/{message.id} | not stated | Not documentedask in writing | docsread 10 October 2026 |
| Search | ||||
| Algolia | Delete every record that holds the person's data with DELETE /1/indexes/{indexName}/{objectID} (or the batch or deleteBy operations), then check the returned taskID with Check task status (GET /1/indexes/{indexName}/task/{taskID}) until it reads published. Delete their Insights events with DELETE /1/usertokens/{userToken}; that deletion is asynchronous and processed within 48 hours.DELETE /1/indexes/{indexName}/{objectID}The delete response only means a task was queued; the task status reads published once the task is completed, while the Insights user-token deletion is only promised within 48 hours. | Search API logs: 90 days; Insights API logs: 90 days, extendable to 365 days | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Background jobs | ||||
| Trigger.dev | The docs document no API or dashboard action that deletes a single run or its payload and output; run logs expire after the plan's log retention, while payload and output stay visible. Where you cannot erase the data yourself, ask Trigger.dev to co-operate under its DPA, which commits it to help you comply with data subject requests.The DPA says Trigger.dev deletes customer personal data within 90 days of the agreement ending unless the law requires it to keep it. | Logs: 1 day on Free, 7 days on Hobby, 30 days on Pro; a run's payload and output stay visible after its logs are deleted | Not documentedask in writing | docsread 10 October 2026 |
| Inngest | The docs offer no API or dashboard action that deletes one person's events or runs today: the event reference says the user object will support programmatic right-to-be-forgotten deletion via an API endpoint only "in the future". Until then, trace and log history expires after your plan's window.For sensitive data Inngest recommends its encryption middleware: event.data.encrypted and step and function output are encrypted before they leave your servers, and Inngest can never read them. | Trace and log history: 24 hours on Free, 7 days on Pro, 14 days on Business, up to 365 days on Enterprise | Not documentedask in writing | docsread 10 October 2026 |
| Realtime | ||||
| Pusher | Pusher Channels does not store messages, except Cache Channels values, which are removed after 30 minutes, so there is nothing to delete there. For Beams, delete the person and all their devices with deleteUser(userId) in a server SDK or the Customer API's Deleting a User endpoint.DELETE https://<YOUR_INSTANCE_ID>.pushnotifications.pusher.com/customer_api/v1/instances/<YOUR_INSTANCE_ID>/users/<YOUR_USER_ID>In the Node.js SDK, deleteUser's promise rejects if deletion fails, and the documented example logs "Successfully deleted the user!" when it resolves. | Channels: data is ephemeral and not stored; Cache Channels values are removed after 30 minutes | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Ably | Ably provides no API to delete persisted messages from history; messages expire after the default two minutes, or after the persisted-history period your package sets. To delete specific messages from history, contact Ably support (https://ably.com/support) to discuss requirements; deleteMessage() is only a soft delete that leaves the message on the server.Once stored with persisted history enabled, messages remain for the entire configured storage period. | Messages: 2 minutes by default; with persisted history, 24 hours on Free, 72 hours to 30 days on Standard, 72 hours to 365 days on Pro | Not documentedask in writing | docsread 10 October 2026 |
| Liveblocks | Delete the person's comments with the Delete comment endpoint (or whole threads with DELETE /v2/rooms/{roomId}/threads/{threadId}) and their inbox notifications with DELETE /v2/users/{userId}/inbox-notifications. Delete rooms or Storage documents that hold their data with DELETE /v2/rooms/{roomId} or DELETE /v2/rooms/{roomId}/storage. Presence data persists until a deletion request is submitted.DELETE https://api.liveblocks.io/v2/rooms/{roomId}/threads/{threadId}/comments/{commentId}Each delete returns 204 documented as success with the item deleted (for example "Success. The room was deleted"); a deleted room or comment cannot be restored. | Comments, Sync data and notifications: until explicitly deleted; presence: until a deletion request is submitted; webhook data: 90 days | Yeskeep what it returns or sends | docsread 10 October 2026 |
| Automation platform | ||||
| Apify | Datasets are append-only, so delete the whole dataset that holds the person's items with DELETE /v2/datasets/:datasetId, and delete the finished run with DELETE /v2/actor-runs/:runId. Delete individual key-value store records with DELETE /v2/key-value-stores/:storeId/records/:recordKey.DELETE /v2/datasets/:datasetIdThe storage overview says retention depends on the plan (on Free the 10 most recent runs are retained for 4 months) and that named storages are retained indefinitely, so a named dataset holding the person's data must be deleted explicitly. | Unnamed datasets and key-value stores: 7 days unless otherwise specified; named storages: indefinitely | Not documentedask in writing | docsread 10 October 2026 |
| Code hosting and CI | ||||
| GitHub | Delete the logs of each workflow run that read the person's data with the endpoint below, and each artifact with DELETE /repos/{owner}/{repo}/actions/artifacts/{artifact_id}; or delete the whole run with DELETE /repos/{owner}/{repo}/actions/runs/{run_id}, which also deletes its artifacts from storage. Write access to the repository is required. Otherwise logs and artifacts are deleted automatically after the retention period, 90 days by default.DELETE /repos/{owner}/{repo}/actions/runs/{run_id}/logsA shortened retention period does not retroactively apply to existing runs, artifacts and logs, and a deleted artifact cannot be restored. | Workflow logs and artifacts: 90 days by default (configurable 1 to 90 days for public repositories, 1 to 400 days for private). | Not documentedask in writing | docsread 10 October 2026 |
69 vendors mapped: 28 confirm a deletion, 2 say they do not, and 39 do not say. Each entry comes from the vendor's own page, read on the day shown; "not stated" and "not documented" mean the documentation does not say, not that the answer is no. Not mapped yet: Groq. As JSON (each vendor's erasure).
Vendors that will not confirm
- Axiom: A trim returns 200 once queued and can take hours, its result cannot tell you how much was deleted (query the trimmed time range or poll the dataset info endpoint), and deleting a field only hides its values, which stay in storage. Its documentation (read 10 October 2026).
- Langfuse: Trace deletion is asynchronous, usually done within 15 minutes of the delete call; to verify, query the data again. Its documentation (read 10 October 2026).
For these, the record you keep is your own: the day you deleted, and the lookup afterwards that came back empty. Vercel, Cloudflare, Netlify, Fly.io, Render, Railway, DigitalOcean, Amazon Web Services, Google Cloud, Microsoft Azure, Supabase, PlanetScale, Turso, MongoDB Atlas, Pinecone, Paddle, Lemon Squeezy, Twilio SendGrid, Mailgun, Twilio, Google Gemini API, Cohere, OpenRouter, Hugging Face, Deepgram, Sentry, Better Stack, Helicone, Google Analytics, Plausible Analytics, WorkOS, Discord, Crisp, UploadThing, Trigger.dev, Inngest, Ably, Apify and GitHub do not say either way; ask them in writing and keep the answer.
When you are the processor
If you process the data for a business customer, the request reaches you through that customer, the controller, and your part is to help it answer (Art. 28(3)(e)). The steps are the same: delete in your systems, carry it through your own sub-processors, and send your customer the record.
Why a map and not a tool that deletes
Each deletion needs that vendor's key for your account, and each one is permanent. A checklist keeps both with you. Fides, Ethyca's open-source privacy-request engine, has been archived on GitHub since 28 August 2026: its repository is read-only.
Not legal advice. Whether a vendor is your sub-processor depends on the personal data you send it and on your contracts; a list drafted from code is a draft for you to confirm, row by row. It also misses vendors outside the code (your workspace, support desk, CRM, payroll): add those by hand.
A hosted, dated sub-processor page that emails your customers each change is not built.
It would publish the list you approved at a public URL, keep every change with its date, email your subscribers the notice with the day their objection window closes, and record who was told when. agentcheck runs scheduled checks of endpoints today; this is not one of them. If you would pay for it, say so with one click. The click is counted, and nothing else is sent or stored unless you then leave an email.
Counted. Thank you; nothing else was sent.
Sources
- GDPR Art. 17: right to erasure (read 10 October 2026)
- GDPR Art. 12(3): one month to act (read 10 October 2026)
- GDPR Art. 19: telling each recipient of an erasure (read 10 October 2026)
- GDPR Art. 28(3)(e): a processor assists with data subjects' requests (read 10 October 2026)
- Ethyca's Fides repository: archived by its owner on 28 August 2026 (read 10 October 2026)
- Each vendor's own page, linked in the map with the day it was read.
subprocessors is a free tool from agentcheck, which runs scheduled checks of your endpoints and alerts you when an answer changes. Vendor links come from each vendor's own pages, read on the day shown.