What we hold, and why.
Last updated August 23, 2026. Controller: Temp and Major Inc., 604 West 60th Street, Chicago, IL 60621, United States.
Osokoro holds two different kinds of data, and they are treated differently because only one of them chose to deal with us. Your account is yours and ours. The contacts a waitlist collects are yours: for those, you are the controller and we process them on your instructions.
Your account
Your email address, your name if you give one, your organisation name, your role, and a password hash held by our authentication provider. We use them to sign you in, to show you the right organisation, and to contact you about the account. Payment details are handled by Stripe and never reach us — we store only the Stripe customer and subscription identifiers.
Contacts collected by a waitlist
When somebody joins a waitlist you run we store their email address, when they joined, their answers to the questions you asked, their referral code and how many verified referrals they have, and how they arrived: referrer, UTM parameters, and the referral link they followed. We do not sell this, mine it, or market anything to those people on our own behalf.
IP addresses and user agents
A signup records the browser’s user agent, and we derive a short-lived key from the IP address for rate limiting. Both exist to stop one person or script flooding a waitlist. The rate-limit records are swept automatically a couple of hours after the window closes. If you consent to Meta measurement on the affiliate-recruitment funnel, we also retain the requesting IP address and user agent with that attribution for up to 90 days so browser and server conversion events can be matched and deduplicated.
Abuse prevention
Public signup forms on paid plans carry a proof-of-work challenge rather than a third-party CAPTCHA, so no data goes to an outside service for it. Each solved challenge is recorded once so it cannot be reused, and those records are swept within the hour. We also refuse addresses at known disposable domains and detect referral self-dealing.
Mail is sent through Amazon SES when it is configured, and through Resend otherwise. Which one is in use is a deployment setting, not a per-message choice.
Bounces and complaints reported by either provider are recorded and added to a suppression list that applies across every waitlist in your organisation, so an address that hard-bounced once is not mailed again by another of your projects. A soft bounce — a full mailbox, say — is recorded but not suppressed, because suppressing on one would lose a real subscriber; and where a provider reports a reason we do not recognise, we record it and do not suppress, for the same reason. A complaint also unsubscribes that person from the queue.
Cookies and local storage
We set a session cookie so you stay signed in, and a cookie remembering which organisation you last opened so that returning to the app takes you back to it. Both are HTTP-only where the browser allows it and are not used for tracking. Your theme choice is kept in local storage on your own device. On the affiliate-recruitment funnel only, we ask before setting a marketing-consent choice, a random first-party visitor ID, or Meta’s _fbp and _fbc identifiers. Rejecting does not affect the site. The consent choice lasts up to 180 days; recruitment identifiers and attribution expire after 90 days.Current choice: unknown
Analytics
We do not run general third-party analytics. If you allow marketing measurement, the Meta Pixel and Meta Conversions API operate only across the affiliate-program landing, application, approval and payout-onboarding funnel. We send page and application milestones, first-touch campaign parameters, the Meta browser identifiers, and hashed matching values; browser and server copies share an event ID so Meta counts them once. We do not load the Pixel on customer waitlists or custom domains. Dashboard product analytics are computed from your own signups by our database and are not sent to Meta.
Webhooks and integrations
If you configure a webhook or connect Zapier, we send the event data you subscribed to — a signup, a verification, an unsubscribe — to the URL you nominated, signed so the receiver can verify it came from us. What happens to it after that is governed by whoever operates that endpoint. We refuse URLs that resolve to private or internal addresses.
Who else processes data
Supabase (database and authentication hosting), Vercel (application hosting and custom domains), Stripe (payments), Amazon Web Services SES (email delivery), Resend (email delivery fallback), and Sentry (error monitoring). What each one receives is set out in Annex III of the data processing addendum, which is generated from the same list as this sentence so the two cannot disagree.
International transfers
Our database and application hosting run in the United States. If you or your contacts are in the UK or EEA, that means data is transferred outside your region; our providers offer standard contractual clauses for it.
How long we keep things
Account data lives as long as the account. Contacts live until you delete them or delete the account. Delivered email records are kept 30 days, failures 180 days, and provider delivery events 180 days. Affiliate recruitment attribution and sent Meta event records are kept for up to 90 days. Rate-limit and challenge records are swept within hours. Suppression records are kept indefinitely on purpose: they are the record of who asked not to be emailed, and deleting one would mean emailing that person again.
Deletion
You can delete your organisation from Settings. Doing so removes every waitlist it owns, every contact in them and their answers, your team members’ access, any custom domains, and its suppression list. An active subscription is cancelled first — and if that cancellation fails nothing is deleted, because otherwise you would keep being charged for an account that no longer exists. If it was your only organisation, your login goes too. We keep an aggregate record that an organisation of that name existed and was deleted, with the number of waitlists and contacts removed and the Stripe identifiers, so a later billing question can be answered. It contains no email addresses.
Anyone on a waitlist can remove themselves at any time from the unsubscribe link in any email, which also removes them from the queue. Suppression records survive that, and survive an organiser deleting a single contact, for the reason above — they are the record of who asked not to be emailed. They do not survive the organisation itself being deleted: at that point there are no further sends for them to protect, and keeping an address we have no remaining reason to hold would be worse for the person it belongs to, not better.
Your rights
Depending on where you live you may have the right to access, correct, export or delete your personal data, to object to processing, or to complain to a regulator. Export and deletion are available in the app; for anything else write to hello@osokoro.comand we will respond within 30 days. If you are a contact on somebody’s waitlist, the organiser is the controller — contact them first, and we will help them act on it.
Security
Every table is protected by row-level security, so one organisation cannot read another’s data even if the application has a bug. API keys are stored only as hashes and shown once. Webhook signing secrets are not readable by anyone, including account owners. Traffic is HTTPS only.
Changes
We will update this page when what we do changes, and change the date at the top. For a material change we will email account owners.
Contact
Privacy questions: hello@osokoro.com. Anything else: hello@osokoro.com. Postal: Temp and Major Inc., 604 West 60th Street, Chicago, IL 60621, United States.