privacy

Papayya privacy policy

What Papayya collects, why it is collected, how long it is kept, who it is shared with, and how to have it deleted.

Last updated 21 August 2026. This policy covers two different things, and it is worth keeping them apart: this website, which anyone can visit, and the Papayya service, which processes work you send it. The website collects almost nothing. The service holds whatever your workload puts through it, which is why the second half of this page is the longer one.

This website

Demo request
Booking a demo at /demo is handled by Cal.com, which takes your name, email address and chosen time so the meeting can be scheduled, and sets its own cookies on that page. The address is used to run the meeting and to follow up about it. Email us and we will delete it. If you use the mailto fallback instead, we hold only the message you sent us.
Server logs
Our host, Vercel, records ordinary request logs — IP address, user agent, path, timestamp — for operational and abuse-prevention purposes. We do not join those logs to any account.
Analytics and advertising
None. There are no analytics scripts, no advertising pixels, and no third-party cookies on this site. The site sets no cookies of its own.

The Papayya service

When you run a workload on Papayya, the platform stores what it needs in order to grade an item and re-drive it later. That includes the input for each item, the output it produced, the step trace, token counts and derived cost, any correlation key you declare, and the code bundle you deployed. This is not optional data: an item you cannot re-drive from its own recorded input is not a recoverable item, and recovery is the product.

Account records — name, email, hashed password or identity-provider subject, and API key digests — are stored separately from workload data. API keys are stored as digests; the plaintext is shown once at creation and never again.

Model provider keys you supply are encrypted at rest and used only to make calls on your behalf. Papayya does not proxy model traffic in order to meter it and applies no markup to tokens.

What we do not do with your data

Sub-processors

We use a small set of vendors to run the service: a cloud provider for compute and managed Postgres, Vercel for website hosting, Cal.com for demo scheduling, and Resend for transactional email. Each is bound by its own data-processing terms. We will publish the current list on request and give notice before adding a sub-processor that handles customer workload data.

Retention and deletion

Workload data is kept for as long as your account holds it. The API exposes a scoped deletion endpoint that removes items by id or by prefix — it runs as a dry run by default so you can see exactly what would be removed before anything is, and every deletion is written to an audit trail. Deleting an account removes its workload data and its account record; backups age out on their own schedule within thirty days. Demo booking details are deleted on request.

A default retention window for workload data is not yet fixed. Until it is, nothing expires automatically, and the deletion endpoint is the mechanism. If you need a contractual retention period, write to us.

Your rights

Wherever you are, you can ask us what we hold about you, ask for a copy, ask us to correct it, or ask us to delete it. Under PIPEDA in Canada, the GDPR in the EU and UK, and the CCPA in California you may have further rights, including the right to complain to a supervisory authority. Write to kingsley@getpapayya.com with "privacy" in the subject and we will answer within thirty days.

Security and changes

Traffic is encrypted in transit, secrets and provider keys are encrypted at rest, and access to production is limited to the people who operate it. To report a vulnerability, see /.well-known/security.txt. If this policy changes materially we will update the date at the top of this page and email account holders before the change takes effect.