Legal

Privacy Policy

Effective September 2, 2026

SendOps is a software product operated by AltaCoda LLC (“AltaCoda,” “we,” “us,” or “our”). This Privacy Policy describes how AltaCoda collects, uses, discloses, and protects information in connection with the SendOps platform and related services (collectively, the “Service”).

SendOps is an email operations and marketing platform that runs on your own Amazon Simple Email Service (SES) account. It stores and processes contact and audience data that you upload, synchronize, or submit, and recipient-level engagement data received from Amazon SES. This policy describes that processing in detail.

By accessing or using the Service, you acknowledge that you have read and understood this Privacy Policy. If you do not agree with our practices, please do not use the Service.

1. Who We Are, and Which Hat We Wear

AltaCoda LLC processes personal data in two distinct roles, and the distinction matters for your rights and ours.

In this policy, a Client is a third party for whom an approved partner or other authorized customer operates a managed SendOps workspace.

We are the controller (a “business” under CCPA/CPRA) for personal data we process to run the platform and partner program: your user account, your workspace, authentication and session records, usage and device data, billing records, support communications, partner applications and administration, referral attribution, and audit logs.

We are a processor or subprocessor (a “service provider” or subcontracted service provider under CCPA/CPRA) for the contact, audience, consent, content, and engagement data placed in or generated through the Service about recipients. For an ordinary or Client-billed workspace, you are the controller (or “business”). For a partner-billed managed workspace, your client may be the controller and you may be its processor or service provider. We process that data on documented instructions from the applicable controller or from a customer acting with the controller’s authority. That relationship is governed by our Data Processing Addendum (“DPA”), which is available to every customer and forms part of the Terms.

Contact: AltaCoda LLC 1111 Broadway Oakland, CA 94607 Email: hello@altacoda.io

2. What the Service Does — and Does Not Do

Understanding how SendOps works is essential to understanding what data we handle.

SendOps is an email operations and marketing platform built on an AWS account you own or are authorized to administer. It provides:

Transactional email management and monitoring
Contact and audience management (a contact roster with typed attributes you define)
Contact imports by CSV file, by API, and by synchronization with your SES contact list
Static lists and dynamic segments (including segments defined as code and synced from Git)
Broadcast and campaign sending
Automated and drip workflows
Email template management, authoring, and rendering
Topic-level consent and subscription management, including a hosted unsubscribe page
Bounce, complaint, suppression, delivery, open, and click tracking
Recipient-level message history, engagement reporting, and analytics
A public API, activity ingest API, and programmatic access for your own systems and agents

Email is always sent through the connected AWS account. Delivery uses that account’s SES identities, verified domains, sending quotas, and sender reputation, and AWS bills the account owner. SendOps does not relay, proxy, or send email through shared infrastructure of its own, and does not act as your email service provider for delivery purposes.

Two sending paths exist, and they involve different data:

The AWS Account owner’s own transactional sending. When its application calls SES directly, the message never passes through SendOps. We receive only the resulting event stream from Amazon SES (send, delivery, bounce, complaint, open, click) via EventBridge in the connected AWS account, together with the recipient address and metadata carried on those events. We do not receive the message body.
Broadcasts and workflow emails authored in SendOps. Here SendOps composes the message — it holds the template, the subject line, the content, the merge data, and the resolved recipient set — and dispatches it through SES in the connected AWS account. For these sends, we do process message content and recipient lists.

What we do not do:

We do not connect to, query, or replicate your application’s own databases. Contact data reaches SendOps only when you upload, synchronize, or submit it.
We do not sell personal information. Optional advertising technologies on our public websites may constitute sharing for cross-context behavioral advertising under California law; Section 14 explains how to opt out.
We do not buy, rent, broker, append, or enrich contact lists, and we do not supply recipients to you.
We do not request or process SES forensic (per-message failure) reports.

3. Information We Collect

3.1 Account and Workspace Information You Provide

Account information: Name, email address, and password (stored hashed) when you register for an Account.
Workspace information: Organization name, slug, logo, session and MFA policy settings, and the postal address you supply for the unsubscribe footer required by CAN-SPAM.
Billing information: Payment method details are collected and processed by our payment processor, Stripe. We do not store full payment card numbers. We receive and store a token, card brand, last four digits, expiration date, and billing and invoice history.
AWS connection details: The IAM role ARN, external ID, region, and related identifiers supplied to connect an AWS account. SendOps assumes a scoped role created by the account owner or an authorized administrator using short-lived STS credentials; we do not store long-lived AWS access keys.
Credentials you issue to us or to your own systems: API keys, OAuth client registrations, and access and refresh tokens (stored hashed or as signed tokens, never in reusable plaintext form).
Support communications: Information you provide when contacting us, including email address, message content, and attachments.

3.2 Contact and Audience Data You Place in the Service

This is data about recipients associated with the workspace, not about its Authorized Users. The applicable controller decides what to place here; an authorized Customer or partner may configure the processing on that controller’s behalf.

Recipient email addresses, stored per workspace.
Your own identifier for a contact (external_id), where you supply one so your systems and ours can be joined.
Custom contact attributes you define and populate — for example a first or last name, a plan tier, a signup date, a locale, or a numeric score. The attribute schema is yours; the values are whatever you upload, sync, or send. Names are stored as attributes when you choose to provide them.
List membership — which contacts belong to which static lists.
Segment definitions and derived segment membership — the predicate you wrote and the contacts currently matching it.
Consent and subscription records — workspace-level unsubscribe state, per-topic subscription status, the topics you define, and the changes recipients make through the hosted unsubscribe page.
Suppression status — the SendOps-derived undeliverable list, the classification rules your workspace configures, and suppression state mirrored to and from your SES contact list.

Contact and audience data reaches us in the ways configured for the workspace: CSV import, the public API, the activity ingest API, our own template and definition sync from a connected Git repository, and synchronization with the SES contact list in the connected AWS account.

3.3 Campaign, Template, and Workflow Content

Templates — template source read from a connected Git repository (including file names, commit messages, and commit authors), and templates managed in the Service. Templates are compiled and deployed as native SES templates in the connected AWS account.
Broadcast and campaign content — name, subject line, preview text, sending identity, the pinned template and version, inline HTML and plain-text content where you supply it, default merge data, schedule, and the topic a campaign is associated with.
Workflow definitions — the workflow source, its steps and conditions, and per-contact enrollment and step state.
Assets — images and files you upload or that we read from your connected repository, and their delivery configuration.
Unsubscribe page settings — your branding and copy for the hosted unsubscribe page.

3.4 Email Event, Engagement, and Activity Data

Email event data received from Amazon SES via EventBridge in the connected AWS account: sends, deliveries, rejects, delivery delays, bounces (including bounce type and sub-type), complaints, opens, clicks (including the clicked link), and rendering failures, together with the recipient address, sending identity, configuration set, message identifiers, and timestamps.
Recipient-level message history, searchable per message and per recipient. Recipient email addresses are stored in plaintext in this store so that per-message lookup and recipient search work, and in irreversible hashed form in the analytics and aggregate tables.
Per-recipient campaign outcomes — for each broadcast, one record per recipient recording whether the message was sent, failed, or was filtered before sending, and for filtered records the reason (for example, unsubscribed from the campaign’s topic, or suppressed).
Contact activity events you send us through the activity ingest API — an event name, timestamp, the contact it belongs to, and any properties you attach — used for segmentation and for the contact timeline.
Engagement derived per contact, such as last-open and last-click recency used by segments.

Access to recipient search in the dashboard is a distinct permission within your workspace, so you can grant analytics access without granting access to recipient addresses.

3.5 AWS and SES Configuration Information

SES configuration sets, verified domains and email identities, DKIM records and selectors, custom MAIL FROM settings, tracking domains, sandbox status and sending quotas, suppression settings, CloudFormation stack and template version, account maturity signals, cost and usage estimates, and the production-access requests we submit on your instruction.

3.6 Information Collected Automatically About Your Use of the Service

Usage data: Pages viewed, features used, actions taken, timestamps, and session duration.
Device and connection information: IP address, browser type and version, operating system, device identifiers, and referring URLs.
Audit records: Who in your workspace did what, and when — retained as a security and accountability record.
Server logs and telemetry: Request logs, traces, metrics, and error reports.
First-touch attribution: Where you consent, the so_attrib cookie records selected campaign parameters, a partner or referral code where present, referring URL, landing path, and first-seen timestamp. It does not contain your name, email address, or a cross-site advertising identifier.

3.7 Information from Third-Party Sources

AWS: SES configuration data, account status, contact-list state, and email event data from the connected AWS account, as authorized by its owner or authorized administrator.
Git provider (GitHub): Repository metadata, template files, and audience or workflow definitions from repositories you connect.
Stripe: Transaction status, payment confirmation, and limited billing details.
Analytics providers: We use Google Analytics 4 and Mixpanel to understand how the Service and our website are used, and Ahrefs Web Analytics, which is cookieless.
Advertising platforms: We run ads on X (Twitter) and LinkedIn. Their pixels on our public websites report back which ads led to a visit or a signup, and let us exclude people who have already found us. See Section 14 for how to turn these off.

3.8 Partner and Partner-Applicant Information

When you apply to or participate in the SendOps Partner Program, we may collect:

Identity and contact information: Legal and trading names, entity type, registration information, business and tax country, postal address, website, contact name, title, email address, and payment contact.
Application and program information: Partner profile, requested track, proposed contribution, application responses, eligibility and approval records, program status, managed workspaces, and compliance communications.
Referral and commission information: Partner or referral code, attributed visits and leads, qualifying customer and subscription records, commission calculations, payment status, reversals, disputes, and related accounting records.
Agreement and signature information: Agreement versions, names, titles, signatures, signing timestamps, IP address, device and audit-trail information supplied by our electronic-signature provider.
Payment and tax administration: Payment destination and tax information needed to validate and make partner payments. Payment providers may collect additional financial information directly under their own terms; we do not store full payment-account credentials unless expressly stated at collection.

We receive this information from you, the organization you represent, referred visitors and customers, our own attribution systems, payment providers, and our electronic-signature provider.

3.9 Cross-Account Aggregate Deliverability Data

We maintain one aggregate deliverability dataset that is deliberately not scoped to a single customer, and we want to be explicit about it.

For each day, recipient domain, and sending domain, we keep counts of sends, deliveries, bounces (by type), complaints, opens, and clicks, keyed by an irreversible HMAC-SHA256 hash of the recipient address and of the sending identity. This dataset carries no workspace identifier, no plaintext addresses, and no message content, and it cannot be used to list or reconstruct any customer’s contacts. We use it to detect deliverability problems earlier and to inform mailbox-provider-specific guidance. Because it is aggregate, pseudonymized, and not attributable to a workspace, it is retained on a longer schedule than event-level data (see Section 6) and is not deleted by workspace closure. If you object to this processing, contact us at hello@altacoda.io.

4. Why We Process Each Category, and For How Long

The table below states, for each category, why we process it and how long we keep it. Section 6 gives the deletion mechanics.

Category	Why we process it	Retention
Account, workspace, and authentication data	To create and secure accounts, authenticate users, enforce roles and MFA policy, and operate the workspace	Life of the Account, then deleted on closure
Billing data	To process payments, manage subscriptions, invoice, and meet tax and accounting obligations	Up to 7 years, as required by law
Contact roster, attributes, and `external_id`	To store the audience you asked us to store, resolve identity across your systems, personalize messages, and evaluate segments	Until you delete the contact or close the workspace
List and segment membership, segment definitions	To determine who a campaign or workflow reaches	Until you delete the list, segment, or workspace
Consent records and topic preferences	To honor subscription choices, filter campaigns before sending, and evidence that a recipient’s choice was respected	Until you delete the contact or close the workspace; opt-out records are kept while the contact exists, because deleting them would silently re-enable sending
Suppression and undeliverable status	To prevent sending to addresses that hard-bounced or complained, and to protect your sender reputation	While the contact exists; suppression records are not removed on a schedule
Bounce and complaint events	Deliverability diagnosis, suppression, and reputation alerting	Event-level records deleted no later than 24 months after ingest
Delivery, open, and click events	Engagement reporting, per-message history, and segmentation	Event-level records deleted no later than 24 months after ingest
Contact activity events	Segmentation, workflow triggering, and the contact timeline	The raw event log is deleted 12 months after ingest. Per-event-name daily counts derived from it are retained until you delete the workspace
Campaign and workflow activity (per-recipient outcomes, enrollment state)	To report campaign results, prevent duplicate sends, and reconcile failures	Send-deduplication records for approximately 400 days; outcome records with the campaign, until the workspace is deleted
Templates, campaign content, and assets	To render, preview, deploy, and send the messages you author	Until you delete them or close the workspace
AWS account and SES configuration	To provision, monitor, and reconcile the SES resources in your account	Life of the connection, then deleted with the workspace
Usage and device data	Product improvement, troubleshooting, and abuse prevention	Aggregated or de-identified where possible; underlying records up to 90 days
Audit records	Security, accountability, and dispute resolution	Life of the Account
Server logs, traces, and error reports	Operating and debugging the Service	Deleted or anonymized within 90 days
Support communications	To answer you and to improve support quality	For the life of the inquiry and a reasonable period after
Partner applications and eligibility records	To evaluate applicants, verify eligibility, prevent fraud, and administer approvals	Active applications for the review period; rejected, withdrawn, or abandoned applications generally up to 24 months, unless a longer period is needed for fraud prevention, compliance, or claims
Partner profile, managed-workspace, agreement, and compliance records	To operate the partner relationship, manage access and benefits, document authority, and enforce program requirements	Life of the partner relationship, then for the applicable limitation period or as required by law
Referral and attribution records	To attribute introductions, resolve competing claims, measure the program, and calculate eligibility	The `so_attrib` cookie expires after 90 days; converted lead, customer, dispute, and commission records follow the partner, billing, or accounting retention period that applies to them
Partner commission, payment, and tax records	To calculate and make payments, process reversals, resolve disputes, and meet tax and accounting obligations	Up to 7 years, or longer where required by law
Electronic-signature records	To execute and prove agreements, authenticate signers, and maintain an audit trail	Life of the agreement plus the applicable limitation period or legally required retention period
Cross-account aggregate deliverability data (hashed, no workspace identifier)	Early detection of deliverability problems; provider-specific guidance	Retained on a long-term basis; moved to cold storage after 90 days. Not workspace-attributable and not deleted by workspace closure

Plan retention windows are a different thing. Your Subscription Plan defines how far back the Service will show you email event data and analytics — 7 days on Free, 90 days on Team, 1 year on Business. That window governs visibility in the dashboard, reports, and API. It is not the same as physical deletion, which follows the schedule above. Do not rely on the plan window as a deletion mechanism; if you need data gone sooner, delete the contact or workspace, or ask us.

We also process personal data for:

Communications: Service-related notices (account verification, security alerts, deliverability and sending alerts, maintenance, and changes to our terms). These are transactional, not marketing.
Security, abuse, and fraud prevention: Detecting and investigating unauthorized access, spam and abuse complaints, and other harmful activity — including reviewing sending metadata where a complaint or reputation signal requires it, as described in the Terms.
Partner-program administration: Reviewing applications, confirming authority and eligibility, issuing and managing agreements, attributing introductions, calculating and paying commissions, administering managed workspaces and partner benefits, monitoring required disclosures, and resolving disputes.
Legal compliance: Complying with applicable laws, regulations, legal processes, and enforceable governmental requests.

We do not sell personal information. Some disclosures to advertising platforms described in Section 14 may constitute “sharing” for cross-context behavioral advertising under California law. You can opt out through Cookie settings or a supported Global Privacy Control signal.

5.1 Service Providers (Subprocessors)

We share information with third-party service providers that support the Service, our public websites, and the Partner Program. A complete list, including purposes and locations, is maintained at sendops.dev/subprocessors. We impose appropriate contractual and data-protection restrictions based on each provider’s role. Providers that process customer-controlled Personal Data as our subprocessors are bound to terms no less protective than our DPA.

Our subprocessors are not used to enrich, resell, or repurpose contact data.

Our current electronic-signature provider, Anvil, processes partner identity, agreement, signature, and signing audit-trail information to prepare and execute partner agreements. A future partner-payment provider may process payment and tax information; we will identify that provider and give any required notice before using it.

5.2 The Connected AWS Account

The Service reads from and writes to the connected AWS account to provision and manage resources, dispatch campaigns through SES, and mirror consent and suppression state to its SES contact list. Use of that account is governed by the AWS Account owner’s agreement with AWS, and data in it is subject to AWS’s terms and the owner’s configuration.

5.3 Your Git Provider

If you connect a repository, the Service reads templates and definitions from it using the permissions you grant. Where you enable write-back, the Service opens pull requests or commits to the branch you configure — and only there.

5.4 Within a Workspace

Administrators and Authorized Users in a workspace, including authorized partner or Client personnel where applicable, may access shared workspace data — contacts, segments, campaigns, analytics, and templates — as determined by configured roles and permissions. Recipient-address search is separately permissioned.

5.5 Legal Requirements

We may disclose information if required by law, regulation, legal process, or governmental request, or where we believe in good faith that disclosure is necessary to protect the rights, property, or safety of AltaCoda, our users, or the public. Where we act as a processor or subprocessor, we will notify the Customer before disclosing controlled data unless legally prohibited, and will challenge requests we consider unlawful.

5.6 Business Transfers

In connection with a merger, acquisition, reorganization, bankruptcy, or sale of assets, information may be transferred as part of the transaction. We will notify you of any change in ownership or control of your personal information.

We may share information in other circumstances with your explicit consent.

6. Retention and Deletion

Section 4 states the retention period for each category. This section describes how deletion happens.

Deleting a contact removes the contact and its attributes, memberships, and preferences from the roster. Historical event records that reference the recipient address age out on the schedule in Section 4 rather than disappearing immediately, because they are the record of messages that were in fact sent.
Closing a workspace deletes workspace data across all of our stores in an ordered cascade — contacts, lists, segments, consent records, campaigns, workflows, templates, assets, event data, and AWS connection details — subject to the legal retention obligations noted in Section 4 (principally billing records). The event store is partitioned by workspace so that this deletion is a bulk operation rather than a best-effort sweep.
Resources in the connected AWS account remain the account owner’s. SES identities, configuration sets, contact lists, and deployed templates live in that account and are not deleted by closing a SendOps workspace. Deleting the CloudFormation stack ends our access.
Cross-account aggregate deliverability data (Section 3.9) is hashed, carries no workspace identifier, and is not deleted by workspace closure.
Requesting deletion. You may request deletion of your Account and associated data through the account-closure feature or by contacting hello@altacoda.io.

7. Data Security

We implement commercially reasonable technical and organizational measures to protect information, including:

Encryption of data in transit (TLS 1.2 or higher) and at rest, including databases and backups.
Short-lived STS credentials for AWS access rather than stored long-lived keys; encrypted storage of secrets we do hold.
Irreversible hashing of recipient email addresses in analytics and aggregate stores. Plaintext addresses are retained in the searchable event store, scoped per workspace, to support per-message lookup.
Role-based access control and authentication requirements for Authorized Users, with recipient-address search gated by a separate permission.
Multi-factor authentication for administrative access to production systems, unique accounts for all personnel, and least-privilege access.
Centralized logging, monitoring for anomalous activity, and documented incident response.

No method of transmission over the Internet or electronic storage is completely secure. While we strive to protect your information, we cannot guarantee absolute security.

8. Open and Click Tracking — How It Works, and Its Limits

Open and click tracking produces personal data about individual recipients, and its accuracy is frequently misunderstood. Both matter for your compliance decisions.

How it works. Open tracking inserts a small tracking image into the HTML message; a request for that image is recorded as an open. Click tracking rewrites links so that a click passes through a tracking domain before redirecting to the destination. Both mechanisms are provided by Amazon SES within the connected AWS account, and the resulting events reach SendOps through the same event stream as deliveries and bounces.

It is under your control. Tracking is enabled by the event subscription on the SES event destination for your configuration set, not by SendOps unilaterally. You can operate SendOps without open or click tracking; reporting will then show delivery and bounce outcomes but not engagement, and segments that depend on engagement recency will not populate. You can also use your own tracking domain so that tracked links appear on your domain rather than a third party’s.

Open data is unreliable, and should not be treated as proof. An open is recorded when a mail client loads the image. Clients that block remote images under-report; clients and privacy proxies that pre-fetch or proxy images — including Apple Mail Privacy Protection — over-report and can attribute an open to a recipient who never read the message. Do not treat an open as evidence that a person read an email, and be cautious about inferring engagement, interest, or consent from open data alone.

Privacy implications. Tracking records that a specific recipient interacted with a specific message at a specific time, and click events record which link was followed. In some jurisdictions, tracking of this kind requires the recipient’s prior consent or, at minimum, transparent disclosure in the applicable controller’s privacy notice. That assessment belongs to the controller; a Customer acting for a Client must ensure the Client has made it. We provide the controls; we do not decide whether a particular use is lawful.

9. Controller and Customer Responsibilities, and How Requests Are Handled

9.1 Your responsibilities

Where we act as processor or subprocessor, the applicable controller is responsible for the matters below. If you operate a managed workspace for a Client, you are responsible for ensuring the Client addresses them and for acting only on the Client’s documented instructions:

Establishing and documenting a lawful basis for every recipient contacted through the Service.
Providing recipients with a privacy notice covering use of SendOps, including any open and click tracking enabled.
The provenance and lawfulness of every contact uploaded, synced, or submitted — see the list-provenance requirements in the Terms.
Honoring unsubscribe, objection, and erasure requests, and not circumventing suppression.
Configuring retention, access, and permissions consistently with the controller’s obligations.
Determining whether data placed in the Service is appropriate for it. The Service is not designed for special categories of data under Article 9 GDPR, and they must not be uploaded as contact attributes.
Disclosing and authorizing our role as a subprocessor where applicable. A managed-services arrangement does not remove disclosures required by law, contract, procurement, or security review.

9.2 Requests from Recipients

If a recipient contacts us directly to exercise a right over controlled data, we will not act on it unilaterally. We will identify the relevant workspace where we can, refer the individual to the Customer, and notify the Customer so it can respond or coordinate with the Client. If the Customer asks for assistance, we will help locate, export, correct, or delete that individual’s data within our systems, as described in the DPA. Self-service tools exist for the common cases: contact search and export, contact deletion, and the hosted unsubscribe page.

You can also reduce these requests structurally: a recipient who unsubscribes through the hosted page has their choice recorded workspace-wide or per topic, mirrored to your SES contact list, and enforced on every subsequent campaign send.

9.3 Requests about your own data

For personal data where we are the controller (your user account, usage, billing, support), contact us at hello@altacoda.io. See Sections 11 and 12 for the specific rights available to you.

Because the way suppression is enforced affects recipients directly, we describe it explicitly.

Campaign sends are filtered before dispatch. Every broadcast is checked against two tiers before a message is composed: a workspace-level tier (the contact is suppressed, or has unsubscribed from everything) and a topic-level tier (the contact has opted out of the topic the campaign belongs to). Filtered recipients are recorded with the reason and are not sent to. Where SendOps and your SES contact list disagree about a recipient’s consent, the stricter state wins and is pushed back to SES; a relaxed state in SES never re-enables sending.

Test sends deliberately bypass consent filtering, and you should know exactly what that means. A test send delivers a campaign to an explicit, small set of addresses you name (currently up to ten) so that you can see the real rendered message. It skips the audience snapshot and both consent tiers, does not change campaign state, and is excluded from campaign reporting. It is not a way to send a campaign to your audience, and it must not be used to reach a recipient who has opted out or been suppressed. Using a test send to contact someone you would otherwise be barred from contacting is a breach of the Terms.

What a test send cannot bypass. Test sends go out through Amazon SES in the connected AWS account, so SES’s own controls still apply — including its account-level and configuration-set suppression lists, which SES enforces on every send. Where a recipient is on that SES suppression list because of a hard bounce or a spam complaint, SES will not deliver to them regardless of what SendOps asks for. Permanent deliverability and abuse suppressions of this kind are enforced by AWS below the SendOps layer and are not bypassable through the Service.

Restrict test recipients yourself. Until the Service enforces this for you, address test sends only to verified members of your own workspace or to seed and testing addresses you control. We recommend you make that a written rule internally.

11. Rights for EEA, UK, and Swiss Individuals

If you are located in the European Economic Area (EEA), the United Kingdom, or Switzerland, you have rights under the GDPR, the UK GDPR, and the Swiss FADP.

11.1 Legal Bases for Processing

Where we act as controller, we process personal data on the following legal bases:

Contract performance and steps at your request: Processing necessary to provide the Service, evaluate a partner application, enter into an agreement, and fulfill our obligations (Article 6(1)(b)).
Legitimate interests: Improving the Service, operating and measuring the Partner Program, ensuring security, preventing abuse and fraud, resolving attribution and payment disputes, and maintaining aggregate deliverability intelligence, where those interests are not overridden by your rights (Article 6(1)(f)).
Legal obligation: Complying with applicable laws (Article 6(1)(c)).
Consent: Where you have given consent for a specific purpose, such as optional marketing communications (Article 6(1)(a)). You may withdraw consent at any time.

Where we act as a processor or subprocessor, the legal basis for processing recipients’ data belongs to the applicable controller. A customer acting for a client is responsible for having valid instructions and authority to appoint us.

You have the right to access, rectify, erase, restrict, and port your personal data; to object to processing based on legitimate interests; to withdraw consent; and to lodge a complaint with your local data protection authority.

To exercise these rights, contact hello@altacoda.io. We will respond within 30 days, or sooner where required by law.

11.3 International Transfers

Our production infrastructure runs at Hetzner Online GmbH in Germany and on Amazon Web Services in the United States, and personal data may be transferred to and processed in the United States. Where we transfer personal data out of the EEA, UK, or Switzerland, we rely on the applicable module of the Standard Contractual Clauses — Module Two for controller-to-processor transfers or Module Three for processor-to-processor transfers — as incorporated into our DPA, together with the UK Addendum for UK transfers and the FADP modifications for Swiss transfers. Provider locations are listed at sendops.dev/subprocessors.

Separately, email you send is delivered by Amazon SES in your AWS account and in the region you choose, under your agreement with AWS. Choosing where your sending and event data are processed at the AWS layer is a configuration decision that belongs to you.

12. Rights for California Residents

If you are a California resident, you have rights under the CCPA as amended by the CPRA.

12.1 Categories of Personal Information

In the preceding 12 months, we may have collected the following categories: identifiers (name, email, IP address, account, contact, partner, and referral identifiers), commercial information (billing, subscription, referral, commission, payment, and agreement records), internet or electronic network activity (usage data, device information, referral and attribution data, and email engagement events), and professional information (organization name, role, business address, website, entity information, and partner profile).

12.2 Your CCPA/CPRA Rights

You have the right to know what personal information we collect, use, and disclose; to delete it, subject to exceptions; to correct it; to opt out of sale or sharing; to limit the use of sensitive personal information where that right applies; and to non-discrimination for exercising your rights. We do not sell personal information. You may opt out of advertising activities that may constitute sharing using Cookie settings, the Do Not Sell or Share My Personal Information link in the footer, or a supported Global Privacy Control signal.

To exercise these rights, contact hello@altacoda.io. We will verify your identity before processing your request.

12.3 Service Provider Status

For the contact, audience, consent, content, and engagement data described in Sections 3.2 to 3.4, we act as a service provider or subcontracted service provider, as applicable. We do not retain, use, or disclose that data for any purpose other than performing the Service, do not sell or share it, and do not combine it with personal information from other sources except as permitted by the CCPA/CPRA. Our service-provider certification is in the DPA.

12.4 Authorized Agents

You may designate an authorized agent to make requests on your behalf. We may require you to verify your identity directly and confirm the agent’s authority.

13. Children’s Privacy

The Service is not directed to individuals under the age of 16, and we do not knowingly collect personal information from children. If we learn that we have collected personal information from a child under 16, we will delete it promptly. If you believe a child has provided us with personal information, contact hello@altacoda.io.

You are responsible for not uploading contact data about children where you have no lawful basis to process it.

14. Cookies and Tracking on Our Own Properties

This section concerns our own properties — tracking in the email you send is covered in Section 8.

Our public websites — sendops.dev, help.sendops.dev, developers.sendops.dev, and blog.sendops.dev — load a single Google Tag Manager container, which in turn loads the tags described below. The Service itself (the signed-in application) uses cookies for session management and authentication.

We group the cookies and similar technologies on our websites into four categories:

Essential. Session management, authentication, security, load balancing, and remembering the cookie choice you make. These cannot be switched off, and we do not ask consent for them.
Analytics. Google Analytics 4, used to understand which pages are read, how visitors arrive, and where they leave. We also use Ahrefs Web Analytics, which is cookieless and collects no personal identifiers. Inside the Service we additionally use Mixpanel for product analytics.
Partner attribution. With your consent, the first-party so_attrib cookie records the campaign or partner that first introduced you to SendOps. It may contain selected UTM parameters, a partner or referral code where present, referring URL without its query string, landing path without its query string, and first-seen timestamp. It is scoped to sendops.dev, is not used to follow you across unrelated sites, and expires after 90 days. Refusing or deleting it does not limit the Service, but an introduction may need to be registered manually for the partner to receive credit.
Advertising. X (Twitter) and LinkedIn advertising pixels, used to measure which of our ads lead to a signup and to build retargeting audiences. These set cookies readable by those platforms and are the basis on which they attribute conversions to us.

Your choice, and how we default. Analytics, partner-attribution, and advertising technologies are disabled until you choose to allow them. You can change any category at any time using the Cookie settings link in the footer of any of our websites. Your choice is stored in a sendops_consent cookie scoped to sendops.dev, so it applies across our sites and is remembered for six months. When you withdraw a category, we signal the change to Google Tag Manager where applicable and delete the corresponding cookies we can reach. You can also manage cookies through your browser settings; disabling optional cookies does not prevent you from using the website or Service.

Global Privacy Control. If your browser sends a Global Privacy Control signal, we treat it as an opt-out of advertising cookies before any advertising tag loads. Advertising remains disabled while that signal is present.

We do not sell personal information. The advertising technologies described above may constitute sharing for cross-context behavioral advertising under the CCPA/CPRA, and the controls above provide a way to opt out.

15. Third-Party Links and Services

The Service may contain links to third-party websites or services (such as AWS documentation, GitHub, or Stripe). This Privacy Policy does not apply to them. We encourage you to review their privacy policies.

16. Changes to This Privacy Policy

We may update this Privacy Policy from time to time. If we make material changes, we will notify you by email or through the Service at least thirty (30) days before they take effect. The “Effective Date” at the top of this page indicates when the policy was last revised. Your continued use of the Service after the effective date constitutes acceptance of the revised policy.

17. Contact Us

If you have questions, concerns, or requests regarding this Privacy Policy or our data practices:

AltaCoda LLC 1111 Broadway Oakland, CA 94607 Email: hello@altacoda.io

For GDPR-related inquiries, you may use the same address. If you are not satisfied with our response, you have the right to lodge a complaint with your local data protection authority.

Last updated: September 2, 2026