Privacy Policy

pipera is operated by Omega Union Limited (“we”, “us”), a company registered in the United Kingdom. This policy explains what personal data we handle when you visit pipera.io, when you book a call with us, and when you are a client of ours. We are the controller for the data described here, except where we process a client’s data on their instructions, which the Data Processing Addendum covers.

When you book a call or write to us

• Your name, work email address, company name and website.
• What you tell us about the business and what you are looking for.
• The time slot you selected and the timezone your browser reported.
• The IP address the request came from, kept short term for abuse prevention.

When you are a client

• Account and contact details for the people who use the client portal.
• Billing records. Card details are handled by our payment processor and never reach our systems.
• Brand material you give us, and access tokens for the platforms you connect.
• Data we retrieve from those connected platforms to run the work, such as orders, catalog data and campaign results.

Automatically

• Usage data: pages visited, referring page, approximate region.
• Device data: browser and operating system.
• Cookies and similar technologies, described in the Cookie Policy.

• To schedule and hold the call you asked for, and to send you the invitation for it.
• To answer messages you send us.
• To provide the engagement you bought, and to report on it.
• To take payment and keep the accounting records the law requires.
• To keep the site and the service secure, including rate limiting and abuse prevention.
• To meet legal obligations.

Our legal bases are: performance of a contract (delivering the engagement, holding the call you booked), legitimate interests (running and securing the site, answering business enquiries), legal obligation (accounting and tax records), and consent where consent is what the law requires, such as non-essential cookies.

We do not sell personal data. We share it with the providers that make the service work:

• Supabase, for the database, authentication and storage.
• Cloudflare, for DNS, edge delivery and object storage.
• Hetzner, for the servers the execution engine runs on.
• Apple iCloud, for the calendar that holds booked calls.
• Resend, for transactional and campaign email delivery.
• Stripe and iyzico, for payment processing.
• Model and media providers used to produce work for clients, listed in the DPA.
• Advertising and commerce platforms, where a client has connected them and asked us to run them.
• Authorities, where the law requires it.

pipera runs the digital side of the businesses that hire us, on those businesses’ own accounts. A client connects its accounts to pipera and can disconnect any of them at any time. This section says, platform by platform, what we access, why we access it, and what we store.

Across every platform below the same three rules hold. We do not sell this data. We do not use it to train models. One client’s data is never combined with another’s: each client’s records and access tokens sit in their own namespace, enforced at the database layer.

Meta (Facebook Pages and Instagram)

• We read the list of Facebook Pages the connecting person manages, so the client can pick the right one (pages_show_list).
• We read that Page’s name, description and metadata to show it back in the app and to attribute published work (pages_read_engagement).
• We publish organic posts to that Page on the client’s instruction (pages_manage_posts).
• We read the Instagram Business account linked to the Page, including its username (instagram_basic), publish organic posts to it (instagram_content_publish), and read the reach and engagement of the posts we published (instagram_manage_insights).
• We read the client’s ad accounts and campaign performance (ads_read, business_management) and create and manage campaigns inside the budget the client agreed (ads_management).
• We store: the access token, the Page and Instagram account identifiers, the identifiers of the posts we published, and the performance figures we retrieved. We do not store follower lists or the contents of direct messages.

TikTok

• We read the connected creator’s basic profile, meaning nickname and avatar, plus the posting settings TikTok reports for that account, so the publishing screen can show who is about to post and which options are available (user.info.basic).
• We publish video and photo posts to that account on the client’s instruction (video.publish).
• We store: the access token, the creator’s nickname and avatar url, and for each post the publish_id, its publish status and the publicly_available_post_id TikTok returns.
• We add no watermark, logo or promotional text to anything we publish.

Google and YouTube

• We read the signing-in person’s Google account identifier, email address and basic profile so the connection can be attached to the right client (openid, userinfo.email, userinfo.profile).
• We upload videos to the client’s YouTube channel on the client’s instruction (youtube.upload). We ask for upload only, not full channel access.
• We create and manage Google Ads campaigns inside the agreed budget and read their performance (adwords).
• We store: the access and refresh tokens, the Google account identifier and email, the identifiers of videos we uploaded, and campaign performance figures. We do not read the client’s Gmail, Drive or Contacts, and we do not request access to them.

LinkedIn

• We read the signing-in person’s identifier, name and email address (openid, profile, email).
• We publish posts as that person or as the organisation page they administer (w_member_social, w_organization_social), read the engagement on posts we published (r_organization_social), and read the organisation pages they administer so the client can choose one (rw_organization_admin).
• We store: the access token, the member and organisation identifiers, and the identifiers plus engagement figures of posts we published. Where a comment on such a post is shown in the app, the commenter’s name, headline and profile url are displayed and not retained beyond the reporting window.

X

• We read the connected account’s identifier and username (users.read), read the posts we published to check their status (tweet.read), publish posts on the client’s instruction (tweet.write), and keep the connection alive without asking the client to sign in repeatedly (offline.access).
• We store: the access and refresh tokens, the account identifier and username, and the identifiers of posts we published.

Shopify

• We read and write products and collections, themes and site content, so the store can be built and improved (read_products, write_products, read_themes, write_themes, read_content, write_content).
• We read orders, customer records and inventory so revenue can be attributed and the email lifecycle can run (read_orders, read_customers, read_inventory).
• We never write to a live theme directly. Changes are made on a copy, previewed, and published in one move.
• We store: the access token, the store domain, order records and the customer email addresses attached to them, and catalog data. Order and customer records are deleted automatically once they pass 24 months.

Payment processors

• Payments to us are processed by Stripe, or by iyzico where the client pays from Turkey. Card details go to the processor directly and never reach our systems.
• We store: the customer and transaction identifiers held at the processor, the amount, the currency, and the status and dates of invoices. We never store a card number.

Disconnecting a platform withdraws the grant where the provider allows it, deletes the stored token, and removes the data we retrieved through it. The Data Deletion page has the exact steps and says which providers accept a withdrawal. Work already published to a client’s own account belongs to that account, and removing our access does not remove it there.

Enquiries and booked calls are kept for as long as the conversation is live, and for up to 24 months afterwards so we can pick up a thread that returns. Ask us to delete it sooner and we will.

Client data is kept for the duration of the engagement. On termination it is deleted or returned within 30 days, apart from records we are required by law to retain, such as invoices. Customer and prospect personal data inside a client workspace is removed automatically once it ages past its retention window.

Data is encrypted in transit. Credentials and tokens are encrypted at rest. Access to production is limited and logged, and tenant separation is enforced at the database layer. No system is perfectly secure, and we do not claim otherwise.

Under the UK GDPR and the EU GDPR you can ask us to:

• Give you a copy of your personal data.
• Correct data that is wrong.
• Delete your data.
• Restrict or object to how we process it.
• Send your data to another provider.
• Withdraw consent where processing rests on consent.

Write to [email protected] and we will answer within one month. Step by step instructions are on the Data Deletion page. If you think we have handled your data badly you can complain to the UK Information Commissioner’s Office, or to the supervisory authority where you live.

Some of our providers process data outside the UK and the EEA. Where that happens we rely on an appropriate transfer mechanism, such as the European Commission Standard Contractual Clauses together with the UK International Data Transfer Addendum, plus any additional measures needed.

The service is for businesses. It is not directed at anyone under 18 and we do not knowingly collect their data.

We update this policy when the practice behind it changes. The revision date at the top moves when we do.

Omega Union Limited, United Kingdom. Data protection enquiries: [email protected].