Legal

Privacy Policy

Effective July 29, 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.

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

We are a processor (a “service provider” under CCPA/CPRA) for the contact, audience, consent, content, and engagement data you place in or generate through the Service about your own recipients. For that data, you are the controller (or “business”). We process it on your documented instructions — which, in practice, are the choices you make when you configure the Service, import contacts, define segments, and send campaigns. 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 your AWS account. 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 your AWS account. Delivery uses your SES identities, your verified domains, your SES sending quotas, your sender reputation, and is billed to you by AWS. 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:

Your application’s own transactional sending. When your 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 your AWS account, together with the recipient address and metadata carried on those events. We do not receive the message body.
Broadcasts and workflow emails you author 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 your 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, and we do not share it for cross-context behavioral advertising.
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 you provide to connect your AWS account. SendOps assumes a scoped role you create 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 your recipients, not about you. You decide what to put here; we process it on your 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 you choose: CSV import, the public API, the activity ingest API, our own template and definition sync from a Git repository you connect, and synchronization with the SES contact list in your AWS account.

3.3 Campaign, Template, and Workflow Content

Templates — template source read from a Git repository you connect (including file names, commit messages, and commit authors), and templates you manage in the Service. Templates are compiled and deployed as native SES templates in your 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 your 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.

3.7 Information from Third-Party Sources

AWS: SES configuration data, account status, contact-list state, and email event data from your AWS account, as authorized by you.
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 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
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.
Legal compliance: Complying with applicable laws, regulations, legal processes, and enforceable governmental requests.

We do not sell your personal information, and we do not share it for cross-context behavioral advertising.

5.1 Service Providers (Subprocessors)

We share information with third-party service providers who process data on our behalf to provide the Service. A complete list, including purposes and locations, is maintained at sendops.dev/subprocessors. Providers are contractually obligated to use the information only as necessary to provide their services to us, on terms no less protective than our DPA.

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

5.2 Your AWS Account

The Service reads from and writes to your AWS account to provision and manage resources, dispatch campaigns through SES, and mirror consent and suppression state to your SES contact list. Your use of AWS is governed by your agreement with AWS, and data in your AWS account is subject to AWS’s terms and your own 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 Your Organization

Administrators and Authorized Users in your workspace may access shared workspace data — contacts, segments, campaigns, analytics, and templates — as determined by the roles and permissions you configure. 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 your processor, we will notify you before disclosing your 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 your AWS account remain yours. SES identities, configuration sets, contact lists, and deployed templates live in your account and are not deleted by closing your SendOps workspace. Deleting the CloudFormation stack ends our access.
Cross-account aggregate deliverability data (Section 3.8) 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 your 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 your own privacy notice. As the controller for your recipients’ data, that assessment and disclosure are yours to make. We provide the controls; we do not decide whether your use of them is lawful.

9. Your Responsibilities as Controller, and How Requests Are Handled

9.1 Your responsibilities

Where we act as your processor, you are the controller and you are responsible for:

Establishing and documenting a lawful basis for every recipient you contact through the Service.
Providing your recipients with a privacy notice covering your use of SendOps, including any open and click tracking you enable.
The provenance and lawfulness of every contact you upload, sync, or submit — see the list-provenance requirements in the Terms.
Honoring unsubscribe, objection, and erasure requests, and not circumventing suppression.
Configuring retention, access, and permissions in a way consistent with your own obligations.
Determining whether the data you place in the Service is appropriate for it. The Service is not designed for special categories of data under Article 9 GDPR, and you should not upload them as contact attributes.

9.2 Requests from your recipients

If one of your recipients contacts us directly to exercise a right over data you control, we will not act on it unilaterally. We will identify the customer where we can, refer the individual to you, and notify you so that you can respond as controller. If you ask us for assistance, we will help you 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 your AWS account, so SES’s own controls still apply — including your account-level and configuration-set suppression lists, which SES enforces on every send. Where a recipient is on your 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: Processing necessary to provide the Service and fulfill our obligations to you (Article 6(1)(b)).
Legitimate interests: Improving the Service, ensuring security, preventing abuse and fraud, 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 your processor, the legal basis for processing your recipients’ data is yours to establish and document.

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 Standard Contractual Clauses (Module Two, controller to processor) as incorporated into our DPA, together with the UK Addendum for UK transfers and the FADP modifications for Swiss transfers. Subprocessor 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 and contact identifiers), commercial information (billing records, subscription history), internet or electronic network activity (usage data, device information, email engagement events), and professional information (organization name, role).

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 (we do neither); to limit the use of sensitive personal information (we do not collect it for that purpose); and to non-discrimination for exercising your rights.

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 to you. 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 on our websites into three 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.
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 and advertising cookies are enabled by default when you first arrive, and a notice tells you so on your first visit. You can turn either category off at any time — immediately, and without giving a reason — 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 all of our sites at once, and it is remembered for six months. When you withdraw a category we signal the change to Google Tag Manager using Google Consent Mode v2 and delete the corresponding cookies we can reach. You can also manage cookies through your browser settings; disabling certain cookies may affect functionality.

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. You can still switch advertising back on through Cookie settings if you want to.

A note on defaulting to on. Defaulting these categories to on reflects an opt-out model. If you are in the United Kingdom, the European Economic Area, or another jurisdiction that requires consent before non-essential cookies are set, we want you to know that we currently default them on and rely on the notice and the opt-out above. If you would rather we had not set them, use Cookie settings to turn them off, or contact us at hello@altacoda.io and we will honour the request.

We do not sell personal information and we do not share it for cross-context behavioral advertising, as those terms are defined under CCPA/CPRA.

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: July 29, 2026