Privacy Policy

1Who We Are

Ostrel Software LLC, and its parents, subsidiaries, affiliates, agents, representatives, consultants, employees, officers, and managers — collectively, "STELQ," "we," "us," or "our" — is a Washington limited liability company doing business as STELQ. Our mailing address is 522 W Riverside Ave, Ste N, Spokane, WA 99201, United States.

STELQ sells machine-readable web intelligence. We operate a developer platform of five paid services — search (ranked web results), content (cleaned page text from a URL), answers (a grounded, cited natural-language answer), research (asynchronous deep research that crawls and synthesizes a long cited report), and monitors, which we also call Watches (a standing query that re-runs on a cadence, detects genuine developments, and emits events and signed outbound webhooks). Those services are reachable over our REST API, over the Model Context Protocol ("MCP"), and from our web Console. We also operate a logged-in conversational Workspace inside the Console, a public news surface called STELQ Live, and public documentation.

This Privacy Policy applies to information collected through the STELQ website at stelq.com and all of its subdomains (the "Site"), the API, the Console, the Workspace, STELQ Live, our documentation, our email communications, and all related services, features, and tools (collectively, the "Services").

Capitalized terms not defined here have the meaning given to them in our Terms of Service. In this Policy, an "Input" is anything you send to the Services — a query, a prompt, a URL, a Watch specification, a thread message, or a document you supply or reference. An "Output" is anything the Services return to you — search results, extracted content, an answer, a research report, a Watch event, or a webhook payload. "Credit" is the prepaid balance from which each billable call is debited.

By using the Services, you acknowledge that you have agreed to our Terms of Service and that you have read and understood this Privacy Policy.

2How This Policy Applies, and to Whom

This Policy describes the information we collect, how we use it, our legal basis for using it, whether and how it is shared, and the rights and choices you have. It covers three distinct audiences, and it matters which one you are, because we collect very different things from each.

2.1 Account Holders

You are an account holder if you have signed up for STELQ — whether you use the API as a developer, drive the Services from an autonomous agent over MCP, or work inside the Workspace in the Console. We collect the most information from you: registration details, billing records, request metadata, Workspace content, and the fraud-prevention signals described in Section 5. Most of this Policy is about you.

2.2 End Users Whose Data Passes Through a Customer's Calls

If you are an individual whose personal information appears inside an Input that a STELQ account holder submits — for example, because a customer's own application sends us a query containing your name — then the customer, not STELQ, decides what to send us and why. For that data the customer is the controller (or "business" under United States state privacy law) and STELQ acts as a processor (or "service provider"), handling it only on the customer's instructions and only to return the Output. Section 9 explains this relationship, what we do and do not do with such data, and how to direct a rights request to the right party. If you do not know which STELQ customer holds your data, you may still write to privacy@stelq.com and we will help route the request. You do not need a STELQ account to do so.

2.3 Members of the Public

If you read a story on STELQ Live, follow a story by email, or browse our public documentation, you are a member of the public and you do not need an account. We collect very little from you: anonymous reader analytics, and — only if you affirmatively ask for it — an email address for story updates. Section 10 is written specifically for you, and it also explains what to do if you are a person written about on a Live page and want that information corrected or removed.

3Changes to This Policy

We may update this Privacy Policy from time to time. If we do, we will tell you about any material change — by posting a notice on the Site, by notifying you in the Console, or by emailing the address associated with your account. New versions of this Policy will never apply retroactively; we will always state the exact date a version takes effect, which appears at the top of this document. If you continue using the Services after a change takes effect, that means you accept the updated Policy. If you do not accept it, you may close your account and request a refund of unused Credit as described in our Terms of Service.

4Information We Collect

We collect information you provide directly to us, information collected automatically when you use the Services, information generated by our own systems, and a small amount of information from third-party sources. This Section describes each. Section 5 separately and in full describes the signup fraud and identity meter, which is the most invasive collection we perform and therefore gets its own disclosure rather than a line in a list.

4.1 Information You Provide Directly

• Account registration information. Your email address, a password, and optionally an organization or workspace name. If a private beta gate is in effect, we also record the fact that you requested or were granted access.
• Billing information. We use Stripe, Inc. as our payment processor, through Stripe's hosted Checkout. We never see, receive, or store your full card number, card security code, or bank account number. From Stripe we receive transaction confirmations, amounts, currency, payment status, receipt identifiers, the Stripe customer and payment-method identifiers, and a card fingerprint — an opaque token Stripe derives from the card, which we use only for the fraud purpose described in Section 5.
• API Inputs. The queries, URLs, prompts, parameters, and other content you send to the Services. What we retain of an Input depends entirely on how you use us. Sections 4.2, 4.3, and 4.4 are the three different answers to the question "does STELQ keep my query."
• Workspace content. Thread messages you type in the Console, the asks you confirm, Watch specifications you create, research programs and their spending envelopes, folders, exports, and anything else you save in the Workspace.
• Support communications. Tickets you open in the Console support desk, the messages in them, feedback, bug reports, and email you send us. Our support desk uses AI-assisted intake, which reads the text of your ticket in order to classify and summarize it for our team.
• Notification and billing preferences. Whether you have enabled low-balance alerts; whether you have enabled auto-reload, which is off by default and governed by the separate Auto-Reload Terms; per-key monthly spend caps; and per-key logging settings.
• Follower email address on STELQ Live. If you ask to follow a public story, the email address you enter and the story you asked to follow. See Section 10.

4.2 Request Metadata We Always Collect

For every request to the Services — whether it arrives over REST, over MCP, or from the Console — we record a metadata record containing:

• the endpoint or service called;
• the timestamp of the request;
• the latency of the call;
• the status code or terminal job status;
• the cost debited from your Credit; and
• which API key was used.

This metadata is what powers your usage views, your billing ledger, your activity history, our rate limiting, and our capacity planning. It is retained as described in Section 13.

We do not record your query text and we do not record request or response bodies as part of this metadata. That is a design choice, not merely a policy statement: the always-on usage record has no field for your query. The only circumstances in which we hold the content of a call are the two described immediately below.

4.3 Request and Response Payloads — Opt-In Only, Deleted After Seven Days

Full request and response bodies are captured only when you explicitly enable full logging on a specific API key. This capture is:

• Off by default on every key, for every account, always.
• Scoped to the key you enable it on. Enabling it on one key does not turn it on anywhere else.
• Forward-looking only. Turning it on captures calls made after you turn it on. It cannot and does not retroactively reconstruct calls you already made, because we never had their contents.
• Automatically deleted after seven (7) days. Captured payloads are purged on a rolling basis. This is not a maximum we may choose to observe; it is how the system operates.

Full logging exists for one reason: so that you can debug your own integration by seeing exactly what you sent and exactly what came back. Because a captured payload may contain personal data about your own end users, you should enable it only for as long as you need it, and you should consider whether your own privacy notices and legal bases permit it. You can turn it off at any time in the Console.

4.4 Workspace Content and the Embeddings Derived From It

The Workspace is different from the API in this respect, and you should understand the difference before you use it.

Content you create in the Workspace is stored persistently for as long as your account is open. That includes:

• thread messages — everything you and the assistant say in a thread;
• research reports — the full text of every report produced for you, including its citations;
• Watch specifications and run history — the standing query, its cadence, its closing criteria, every pass it has run, and every event it has emitted;
• research programs — the tree of jobs, the authorized spending envelope, and the follow-ups; and
• the embeddings derived from all of the above.

That last item deserves its own sentence. To make your own work findable, we chunk your Workspace content into addressable passages and compute vector embeddings of those passages using embedding models we host ourselves. Those embeddings are derived personal data: they are a mathematical representation of your content, they are stored alongside it, and they are what allows the Workspace recall feature to semantically search across all of your threads, not merely the one you are sitting in.

This search is scoped to your account. One customer's Workspace content and embeddings are never searchable by another customer and are never pooled into a shared cross-customer index. When you close your account we delete or anonymize your Workspace content and the embeddings derived from it, as described in Section 13. Deleting a thread deletes the paragraphs, the embedding vectors, and the synthesis derived from it in the same operation — the derived data does not outlive its source.

4.5 Account Credentials and API Keys

• Passwords are stored hashed. We do not store, and cannot read, your password.
• API keys are stored as a hash only. When you create a key we show you the full key exactly once. After that we hold only a hash of it and a short display prefix. We cannot recover, re-display, or email you an existing key — not to you and not to anyone else. If you lose a key, the only remedy is to revoke it and create a new one.
• Session tokens, password-reset tokens, and email-confirmation tokens are stored in a form that lets us validate and expire them, and they are invalidated on use or on expiry.

4.6 Technical, Device, and Network Information

• IP addresses. We store IP addresses salted-hashed, not raw. The raw IP address of a request is used transiently — in memory, at the moment of the request — to compute the VPN and datacenter verdict described in Section 5 and to apply security and rate-limiting controls, and it is then discarded. What persists in our records is a salted hash of the address and, where relevant, the derived verdict. We therefore cannot look up "all activity from IP address X" the way a conventional server log would allow, and we cannot reverse a stored hash back into an address.
• Device identifier and browser fingerprint. We store a randomly generated device identifier in your browser's localStorage, and on the signup flow we compute a browser fingerprint using ThumbmarkJS. Both are described in full in Section 5. Neither is an advertising identifier and neither is shared with advertisers.
• Client and request characteristics. Browser or client type, user agent, and basic request headers, used for compatibility, security, abuse prevention, and operating the Services.
• Bot-protection signals. Cloudflare Turnstile runs on our signup and other unauthenticated forms and returns a pass or fail verdict to us. Turnstile is designed to avoid tracking users across sites.
• Analytics. We use Google Analytics 4 on the Site to understand aggregate traffic, which pages are read, and how people move through signup. See Section 12.
• Approximate location. Coarse, country- or region-level location may be inferred by our infrastructure provider from your network connection in order to route requests and apply regional rules. We do not collect precise geolocation and we do not ask for device location permission.

4.7 Information We Receive from Third Parties

• From Stripe — payment status, transaction confirmations, receipt data, customer and payment-method identifiers, and the card fingerprint described in Section 4.1.
• From Cloudflare — bot-protection verdicts, edge request characteristics, and coarse network information.
• From our email delivery provider (ZeptoMail, a Zoho service) — the delivery outcome of messages we send, for example whether a message was delivered, bounced, or was rejected, so that we do not keep mailing an address that does not work.
• From published datasets — we match request network information against the X4BNet published lists of VPN and datacenter IP ranges. Those datasets describe networks, not people; we receive no information about you from their publisher.

4.8 Information Generated by Our Own Systems

Some of the personal data we hold about you is produced by us rather than supplied by you:

• Outputs — answers, research reports, Watch events, and STELQ Live articles, all of which are machine-written by large language models from crawled sources.
• Router classifications. In the Workspace, an "Auto" router runs one model turn over your ask in order to classify it as conversation, a cited answer, research, or a Watch. The router proposes; a human confirms. Nothing billable fires on a click alone.
• Thread synthesis and derived groupings produced from your own threads.
• Embeddings, as described in Section 4.4.
• Usage aggregates — rollups of your metered activity for billing, ledger, and dashboard views.
• The identity score described in Section 5.
• Audit logs. We maintain an internal action log of administrative and security-relevant events, so that privileged actions on the platform are attributable and reviewable.
• Support intake summaries generated by an AI pass over the ticket you submitted.

4.9 Information Collected from Members of the Public on STELQ Live

Reading STELQ Live requires no account. What we collect there is described in Section 10 and is limited to anonymous reader analytics and, if you choose to follow a story, your email address.

5The Signup Fraud and Identity Meter

This Section describes the most invasive thing STELQ does. We describe it in full rather than burying it.

5.1 Why It Exists

Every new STELQ account receives free starting Credit. That welcome bonus costs us real money on the first day of an account's life, and it is the most attractive target for abuse on the platform: a person who can create fifty accounts can extract fifty welcome bonuses. Multi-accounting of that kind is the specific harm the identity meter exists to prevent. Secondarily, the same signals help us detect automated signup floods and credential-stuffing patterns that threaten the availability of the Services for everyone else.

5.2 Every Signup Attempt Is Scored and Recorded

When someone attempts to create a STELQ account, we compute an identity signal score from 0 to 100 and record it, together with the individual signals that produced it. This happens on every signup attempt, including attempts that are blocked or that never result in an account being created. We keep the record of a blocked attempt for the same reason we keep the record of a successful one: a pattern of blocked attempts is itself the evidence that abuse is being attempted.

5.3 The Five Layers, Named

The score is assembled from five distinct layers. We name each one, and the technology behind it, so that you can evaluate it.

• Canonical-email collision detection. We normalize the email address you supply into a canonical form — collapsing the sub-addressing and punctuation variations that many mail providers ignore, so that an address of the form a.b+x@gmail.com is recognized as equivalent to ab@gmail.com — and check whether that canonical form is already associated with an existing account. Address aliasing is the cheapest possible way to create duplicate accounts, so this is the first thing we look at.
• Disposable-email blocklist. We check the email domain you supply against a blocklist of approximately 75,000 disposable and temporary-email domains, refreshed weekly. A hit does not identify you; it tells us the address is designed to be discarded.
• VPN and datacenter IP verdict. We match the raw IP address of the signup request against the X4BNet published CIDR ranges for VPN exit nodes and datacenter networks and derive a verdict. As stated in Section 4.6, the raw address is used for this match transiently and then discarded. Only the salted hash of the address and the resulting verdict are retained.
• Browser fingerprinting and a device identifier. We compute a browser fingerprint using the ThumbmarkJS library, which derives a probabilistic identifier from characteristics your browser exposes — such as rendering behavior, available fonts, screen and hardware characteristics, language, and time zone. In parallel we store a randomly generated device identifier in your browser's localStorage. Together these let us see that many different "new" accounts are being created from the same browser on the same device. We disclose this plainly because a browser fingerprint is not a cookie but it does involve accessing and reading information from your terminal equipment, and because under United States state privacy law it is the collection of a unique identifier.
• Stripe card fingerprint. When an account makes its first paid top-up, Stripe returns an opaque card fingerprint — a stable token derived from the payment card that does not reveal the card number. We stamp that fingerprint onto the account. It lets us see that ten accounts are funded by one card. We never receive or store the card number itself.

5.4 Purpose Limitation

The identity score and the underlying signals are used only to prevent fraud and abuse of the Services, and in particular to protect the free welcome Credit from multi-accounting. They are not used for any other purpose.

Specifically, and without qualification:

• We do not use them for advertising, ad targeting, ad measurement, or audience building.
• We do not use them to build a commercial profile of you, to score you as a customer, to price differently to you, or to infer anything about your characteristics, interests, finances, or behavior beyond the fraud question.
• We do not sell or share them, and we do not disclose them to advertisers, data brokers, or any third party other than a service provider acting on our instructions or where compelled by law as described in Section 21.
• We do not use them to make an automated decision producing legal effects concerning you or similarly significantly affecting you.

5.5 Current Posture: Meter, Do Not Ban

Our operating posture today is to score, not to block automatically. The meter runs in a logging-first configuration: signals are recorded and surfaced to our team for review, and a high score by itself does not automatically bar you from creating an account or terminate an existing one. Where the meter contributes to an adverse outcome, a human reviews it. If we change that posture — for example, by enabling automatic blocking above a threshold — we will update this Policy before doing so.

5.6 Legal Basis and Your Rights

Where the EU or UK General Data Protection Regulation applies, we process the identity signals described in this Section on the basis of our legitimate interests in preventing fraud and abuse of the Services and in protecting Credit we give away for free (Article 6(1)(f) GDPR). We consider that proportionate because the collection is narrowly scoped to the signup and first-payment events, the retained form is minimized (a hash rather than an address, a fingerprint rather than a card number), the purpose is limited as stated in Section 5.4, and the realistic alternative — withdrawing the free welcome Credit — would make the Services worse for every honest user.

You have the right to object to this processing on grounds relating to your particular situation, and to request access to the signals we hold about your account. Write to privacy@stelq.com. We will weigh your objection against the fraud-prevention interest and tell you the outcome. Please note that we may decline to delete fraud-prevention records where retaining them is necessary to detect or prevent ongoing abuse, which is a recognized exception under the privacy laws described in Sections 16, 17, and 18.

6How We Use the Information We Collect

Subject to applicable law and to any controls available to you, we use the information we collect for the following purposes.

6.1 Providing, Operating, and Billing the Services

• Creating, authenticating, and managing your account and API keys
• Fulfilling your search, content, answers, research, and Watch requests, including the upstream processing described in Section 7
• Running Watches on their cadence and delivering events and signed webhooks to the endpoints you configure
• Operating the Workspace, including threads, the Auto router, research programs, thread synthesis, exports, and cross-thread recall
• Metering each call, debiting your prepaid Credit, and enforcing per-key spend caps and per-user rate limits
• Processing top-ups through Stripe and, where you have enabled it, auto-reload charges under the Auto-Reload Terms
• Refunding failed research jobs automatically and unused Credit on request, and producing your ledger, invoices, receipts, and exports

6.2 Security, Fraud, and Abuse Prevention

• Detecting, investigating, and preventing fraud, abuse, and security incidents, including the signup fraud meter described in Section 5
• Enforcing rate limits, protecting platform availability, and maintaining audit logs of privileged actions
• Enforcing our Terms of Service and investigating suspected violations

6.3 Support and Communications

• Responding to your support tickets, including the AI-assisted intake pass that classifies and summarizes them
• Sending transactional messages about your account, authentication, billing, low balance, auto-reload, and security, and service announcements about changes, incidents, deprecations, and pricing
• Sending story updates to STELQ Live followers who have confirmed their subscription, as described in Section 10

6.4 Improvement, Analytics, and Aggregated Data

We analyze aggregate usage patterns to improve latency, cost, quality, and reliability; diagnose errors and failures; and understand how people find and move through the Site. We may aggregate or de-identify information so that it can no longer reasonably be linked to you or your device ("Aggregated Data"), and we may use and retain Aggregated Data for any lawful purpose, including research, benchmarking, and publication of platform statistics. We do not attempt to re-identify Aggregated Data.

6.5 Legal Compliance

We use information to comply with applicable law, regulation, and legal process; to respond to lawful requests from law enforcement and regulators as described in Section 21; to establish, exercise, or defend legal claims; and to protect the rights, property, and safety of STELQ, our customers, and the public.

6.6 What We Do Not Do

We do not sell your personal information. We do not share it for cross-context behavioral advertising. We do not use your query content, Inputs, or Outputs to serve advertising, and we do not operate an advertising business.

7Fulfilling Your Requests — Upstream Processing and the Crawl Stack

To answer a search, content, answers, or research request, or to run a Watch pass, STELQ forwards the necessary parts of your request to its own search and research engine and to the third-party providers that engine depends on. You should understand what that involves, because it is how the product works.

7.1 What Leaves Our Systems

To fulfill a request, the engine may:

• query a self-hosted SearXNG meta-search instance and the Exa search API;
• crawl third-party websites at volume — a research report showing eight citations may have crawled well over a hundred pages to produce them;
• route those crawls through Evomi residential proxies;
• use Zyte as a rescue crawler when a direct fetch fails;
• use CapMonster to solve challenges encountered while crawling;
• send retrieved text, together with the necessary parts of your query, to large language models via OpenRouter, primarily Google Gemini models, for synthesis; and
• send text to embedding models we host ourselves for retrieval and recall.

Only what is needed to fulfill the request is sent, and these providers process it in order to deliver the result. Outputs are returned to you and are not retained by us as payloads unless you have enabled full logging on that key, in which case Section 4.3 applies. Workspace content, by contrast, is retained as described in Section 4.4 because retaining it is the feature.

7.2 A Candid Note About Model Providers

Model inference is performed by third parties under their own terms. We select providers with care and engage them on commercial terms rather than free consumer tiers, but we cannot guarantee that every model provider handles data identically, and the specific models and providers we route to may change as we evaluate quality, latency, and cost. If your use case requires a specific model provider, a specific region, or a contractual commitment about model training on your Inputs, contact us at privacy@stelq.com before you send us regulated or sensitive data, and we will tell you honestly what we can and cannot commit to.

7.3 Do Not Send Us What You Should Not Send Us

The Services are general-purpose web intelligence tools. They are not designed, configured, or contracted for protected health information under HIPAA, payment card data, government-issued identification numbers, biometric identifiers, precise geolocation of individuals, children's data, or other special categories of data. Do not submit that data to the Services. Section 9 sets out your responsibilities as controller of the data you send us.

8How Information Is Shared

8.1 Service Providers and Subprocessors

We share information with service providers who process it on our behalf, under contract, limited to what is needed for the purposes we have authorized. The following table lists them, what they do, and where the processing sits.

We require these providers to use your information only for the purposes we have authorized. They nonetheless operate under their own terms of service and privacy policies, and STELQ cannot fully control how they process, store, or use data beyond our contractual arrangements with them. We may add, replace, or remove subprocessors as the platform changes; where we do, we will keep this table current.

8.2 Information That Becomes Public by Design

Two features publish content deliberately, and you should know about both before you use them.

• STELQ Live. Every page under STELQ Live is public, indexed by search engines, and submitted in a news sitemap. See Section 10.
• Paid analyses on public stories. Where a customer pays to have STELQ write a deep-dive analysis on a public Live story, the resulting analysis is published publicly and free to read, including on the Live page itself. The rule of the house is that you pay to write an analysis, never to read one. A customer who commissions such an analysis is told this before paying, and is not currently credited by name on the published analysis. Do not commission an analysis on a public story if you do not want its Output to be public. The reverse case is the common one and it is private: an analysis you commission on a Watch of your own — one you created, or one you made yours by forking a public Watch — is private to your account, is never published, and is never added to a Live page.

8.3 Disclosures to Protect STELQ and Comply with the Law

We reserve the right to access, preserve, and disclose personal information when we believe in good faith that doing so is reasonably necessary to: (a) comply with applicable law, regulation, legal process, or a governmental request; (b) enforce our Terms of Service and other agreements, including investigating potential violations; (c) detect, prevent, or otherwise address fraud, abuse, security, or technical issues; (d) protect the rights, property, or safety of STELQ, our customers, or the public; or (e) respond to an emergency involving a danger to the personal safety of any person. See Section 21.

8.4 Business Transfers

If STELQ is involved in a merger, acquisition, reorganization, financing, sale of assets, or bankruptcy, your information may be transferred as part of that transaction. See Section 22.

8.5 What We Do Not Share

The following are not published, sold, or made available to other customers or to third parties, except to a service provider strictly as needed to operate the Services or where compelled as described in Section 8.3: your password and account credentials; your API keys, which we could not disclose even if compelled because we hold only hashes; your card number and bank details, which we never receive; your Workspace threads, research reports, Watches, and the embeddings derived from them, other than content you deliberately publish under Section 8.2; your opt-in request and response payloads; your fraud and identity signals; the content of your support tickets; and your usage volumes, balances, and billing records.

9Customer Inputs — You Are the Controller, We Are the Processor

9.1 The Roles

Your Inputs may contain personal data about your own end users or about other individuals. For that data:

• you act as the data controller under the GDPR and UK GDPR, and as the business under the CCPA/CPRA and comparable state laws; and
• STELQ acts as a data processor and a service provider, processing that data only on your documented instructions, only to provide the Services and return the Output, and only as described in this Policy.

9.2 Our Commitments as Processor and Service Provider

In that role, STELQ will:

• process personal data contained in your Inputs only to perform the Services and for the compatible operational purposes described in this Policy, and not for any independent commercial purpose of our own;
• not sell or share that personal data, as those terms are defined by the CCPA/CPRA, and not retain, use, or disclose it outside the direct business relationship with you except as permitted by law;
• impose materially equivalent obligations on the subprocessors listed in Section 8.1 and apply the security measures described in Section 14;
• assist you, so far as reasonably practicable, with data-subject rights requests, security-incident notification, and data protection impact assessments; and
• delete or return the personal data on termination, as described in Section 13, subject to any legal retention obligation.

9.3 Your Responsibilities as Controller

You are responsible for:

• having a valid legal basis, and giving any required notices and obtaining any required consents, for the personal data you submit to the Services;
• not submitting the categories of data listed in Section 7.3;
• deciding whether to enable per-key full payload logging, and accepting that doing so creates a seven-day copy of the personal data in your Inputs and Outputs;
• configuring your Watch destinations and webhook endpoints securely, since an Output we deliver to an endpoint you nominate leaves our control on delivery; and
• responding to your own end users' rights requests. If an individual contacts STELQ about data that belongs to your account, we will, where we can identify the account, refer them to you or ask you to instruct us.

9.4 Data Processing Agreement

A Data Processing Agreement, including the European Commission's Standard Contractual Clauses and the UK International Data Transfer Addendum where applicable, is available on request. Write to privacy@stelq.com or legal@stelq.com with the subject line "DPA Request." We will provide our standard form; we do not require you to negotiate one before you can use the Services.

10STELQ Live — Public Stories, Readers, Followers, and People Written About

STELQ Live is a public surface. Anyone can read it, no account is required, and every page is indexed by search engines. This Section is written for the people who encounter it.

10.1 What STELQ Live Is

STELQ runs its own first-party Watches on developing news stories. There is no customer behind them and nobody is billed for them. Each story page carries a headline, a standfirst, a summary, a timeline, and closing criteria that are written when the story is created and never edited afterwards. That content is machine-written by a large language model from publicly available sources that we crawled, and the hero images are AI-generated. Pages are published with structured news markup and submitted in a news sitemap. STELQ Live is an algorithmically generated information product. It is not journalism, it is not verified reporting, and it is not advice of any kind.

10.2 Reader Analytics

If you only read STELQ Live, we do not ask you for anything and we do not create an account for you. We collect anonymous reader analytics — page views, referring pages, coarse device and browser information, and coarse network-derived location — through Google Analytics 4 and our own aggregate counters, in order to understand which stories are read and how the surface performs. We do not build an advertising profile of you, we do not run behavioral advertising, and we do not sell or share reader data. Section 12 explains how to control the cookies and similar technologies involved.

10.3 Following a Story by Email — Double Opt-In

Anyone can ask to follow a story and receive email when it develops. That flow works as follows, and we describe it precisely because it is the only place where a member of the public gives us personal data.

• You enter your email address on a story page and ask to follow it. At that moment we create an unconfirmed record containing your address and the story you asked about.
• We send you one confirmation email. Until you click the link in it, the record stays unconfirmed. An unconfirmed record is inert and never receives story mail. This is a genuine double opt-in: someone typing your address into our form cannot cause us to mail you anything except that single confirmation.
• Once you confirm, you begin receiving updates for that story. Delivery is through ZeptoMail, our email provider, and each send pass is capped at a maximum of two thousand recipients.
• Every message carries a one-click unsubscribe link that requires no login, no password, and no account. One click stops the mail. We also honor list-unsubscribe headers where your mail client supports them.
• Every message carries our postal address, as required by the CAN-SPAM Act.

10.4 What a Follower's Email Address Is Used For

A follower's email address is used to send updates about the stories that person asked to follow, and for nothing else.

• We do not sell it. We do not rent it. We do not share it with any third party other than ZeptoMail, which delivers the message on our behalf.
• We do not use it for marketing STELQ's paid products, for advertising, for lookalike audience building, or for any promotional purpose.
• We do not merge it into a customer account, and following a story does not create an account.
• We retain it for as long as you are subscribed. When you unsubscribe we stop mailing you; we retain a minimal suppression record so that we do not mail you again by mistake, which is the standard practice required to honor an opt-out.

Where the GDPR applies, the legal basis for follower email is your consent (Article 6(1)(a)), given by confirming the double opt-in, and you may withdraw it at any time using the unsubscribe link without affecting the lawfulness of prior sends.

10.5 If You Are a Person Written About on STELQ Live

STELQ Live stories are about real events, and real events involve real people. If a Live page names you, describes you, or otherwise contains information about you, please read this.

• Where the information came from. Live content is generated from publicly available sources on the open web that our crawler retrieved. We do not obtain information about story subjects from private databases, from data brokers, or from any STELQ customer's account.
• It is machine-written. The summary, timeline, and closing criteria were composed by a language model. Language models make mistakes, including confident ones. A statement on a Live page is not a verified fact and should not be treated as one.
• Pages stay up after a story resolves. When a story reaches its closing criteria or expires, the page remains public and indexed. We do this so that the record of what was said, and when, remains checkable. It also means information about you can persist on the open web after the underlying matter has ended, which is precisely why the channel described next exists.
• AI-generated imagery. Hero images on Live pages are AI-generated and do not depict real people, places, or events, even where they appear to.

10.6 Correction and Removal — A Channel Any Person Can Reach

Any person may ask us to correct or remove information about them on a STELQ Live page, whether or not they have a STELQ account, and without creating one.

Write to privacy@stelq.com. Please include the URL of the page, identify the specific statement at issue, say whether you are asking for a correction or removal, and tell us what is inaccurate or why the information should not remain published. You do not need a lawyer, you do not need to use any particular form of words, and you will not be asked to sign anything to make the request.

What we will do: we will acknowledge the request, review the page and the sources behind it, and respond with what we have decided. Where a statement is inaccurate we will correct it, annotate it, or remove it. Where an entire page should not be published we will unpublish it and, where possible, request removal from search-engine caches. Where we decline, we will tell you why and tell you how to escalate. Where you assert a right under the GDPR, the UK GDPR, or a United States state privacy law, we will handle the request under Sections 16, 17, and 18 and within the statutory deadlines those laws impose.

You may also write to us at the postal address in Section 23. We do not require you to hold an account to exercise any right described in this Policy.

11International Data Transfers

STELQ is a United States company, and there is an inversion here that we want to state plainly rather than leave you to discover.

Our primary control-plane database and our research and search engine run on Hetzner infrastructure in Germany, inside the European Union. Accounts, usage and billing records, Workspace threads, research reports, Watches and their run history, and the embeddings derived from them are stored there. Our web frontend runs on Vercel, our API gateway and queues run on Cloudflare's global edge, payment processing runs on Stripe in the United States, analytics runs on Google Analytics 4 in the United States, and model inference is routed through OpenRouter to providers in the United States and elsewhere.

The practical consequence is that data moves in both directions across the Atlantic, and both directions need a lawful basis.

11.1 EEA, UK, and Swiss Data Coming to the United States

Where personal data originating in the European Economic Area, the United Kingdom, or Switzerland is transferred to the United States — for example to Stripe for payment processing, to Google Analytics 4 for Site analytics, or to a model provider for inference — we rely on appropriate safeguards, which include:

• the Standard Contractual Clauses adopted by the European Commission, together with the UK International Data Transfer Addendum and the Swiss addendum where applicable;
• data processing agreements with each subprocessor imposing confidentiality, security, and purpose-limitation obligations;
• reliance, where a recipient is certified, on the EU-U.S. Data Privacy Framework and its UK Extension and Swiss-U.S. counterpart; and
• transfer impact assessment and data minimization — most notably, storing IP addresses only as salted hashes, holding API keys only as hashes, and not capturing request payloads by default.

11.2 United States Data Going to the European Union

If you are in the United States or elsewhere outside the EEA, your account data, Workspace content, and Outputs are stored on our infrastructure in Germany. Your personal data is therefore processed in a jurisdiction whose laws differ from those of your home state or country, and may be subject to access requests by authorities there under local law. By using the Services you understand and agree that your data will be processed in the European Union and in the other locations listed in Section 8.1. We chose that architecture on engineering grounds and consider the resulting posture at least as strong as United States-only hosting, but we state it plainly so that you can make your own assessment.

If your organization requires data residency in a specific jurisdiction, or requires the Standard Contractual Clauses executed as a signed instrument rather than incorporated by reference, contact privacy@stelq.com before you build on the Services and we will tell you what we can and cannot support.

12Cookies and Similar Technologies

We use a small number of cookies and similar technologies. We do not use third-party advertising cookies, we do not run retargeting pixels, and we do not participate in cross-context behavioral advertising.

12.1 What We Use

• Strictly necessary cookies. Session and authentication cookies that keep you signed in to the Console, and cookies that support security and load balancing. These cannot be turned off without breaking the Services.
• Preference storage. A small number of values in your browser's localStorage that remember interface state, such as Console layout and theme.
• Device identifier. A randomly generated device identifier in localStorage, used for the fraud prevention described in Section 5.
• Browser fingerprinting. ThumbmarkJS runs on the signup flow only, as described in Section 5. It is not a cookie, but it does read characteristics of your browser and it is disclosed here so you can see the whole picture in one place.
• Cloudflare Turnstile. Bot protection on signup and other unauthenticated forms. Turnstile sets its own technical values and is designed not to track users across sites.
• Google Analytics 4. Pseudonymous analytics on the Site and on STELQ Live, used to understand aggregate traffic and page performance. GA4 sets its own identifiers.

12.2 Managing Cookies and Similar Technologies

Most browsers let you refuse cookies, delete existing cookies, clear local storage, or warn you before a cookie is set. Browser privacy modes and tracking-protection features will also limit some of the technologies above. Blocking strictly necessary cookies will prevent you from signing in. Clearing localStorage will reset your interface preferences and will cause a new device identifier to be generated on your next visit.

We do not currently present a cookie consent banner. Where the ePrivacy Directive and GDPR apply, you can decline the non-essential technologies described above at any time by sending a Global Privacy Control or Do Not Track signal from your browser, which we honour as described in Sections 12.3 and 12.4, by blocking or clearing the relevant storage, or by writing to privacy@stelq.com. The fingerprinting described in Section 5 runs on the signup flow only, is limited to fraud prevention, and is justified on the legitimate-interests basis stated in Section 5.6.

12.3 Do Not Track

Some browsers transmit a "Do Not Track" signal. There is still no industry-wide standard for interpreting it, but we treat it the same way we treat Global Privacy Control: if your browser sends it, our analytics are not loaded for your visit at all. Because we do not engage in cross-site behavioral advertising, there was never any sale or sharing for the signal to switch off. Your rights under this Policy apply regardless of the signal.

12.4 Global Privacy Control

We recognize the Global Privacy Control ("GPC") signal. Where we detect a GPC signal from your browser, we treat it as a valid request to opt out of any sale or sharing of personal information, as required by California and several other state privacy laws. Because we do not sell or share personal information for cross-context behavioral advertising in the first place, honoring the signal does not change what we do with your data. Where a GPC signal is present, we also disable non-essential analytics for that browser.

13Data Retention

We keep personal information only for as long as we need it for the purposes described in this Policy, and then we delete or anonymize it. The table below states the actual retention behavior for each class of data.

Where a legal hold, a regulatory obligation, or an active dispute requires it, we may retain specific data beyond the periods above for as long as the obligation lasts.

14Data Security

14.1 Measures We Take

We implement commercially reasonable administrative, technical, and physical safeguards designed to protect personal information, including:

• Encryption in transit. All traffic to the Site, the Console, the API, and the MCP endpoint is served over TLS.
• Hashed credentials. Passwords are stored hashed. API keys are stored as hashes only and cannot be recovered by us or disclosed by us.
• Salted IP hashing. IP addresses are stored as salted hashes rather than in raw form, as described in Section 4.6, so that a compromise of our records does not expose a raw address history.
• Payment isolation. Card data is collected by Stripe's hosted Checkout and never touches our servers.
• Access controls. Role-based access, least-privilege administrative accounts, and an internal audit log of privileged actions.
• Signed webhooks. Outbound Watch webhooks are signed with an account-specific secret so that you can verify that a delivery genuinely came from us.
• Rate limiting and bot protection at the edge, including per-user token buckets and Cloudflare Turnstile on unauthenticated forms.
• Monitoring of platform errors, failures, and anomalous activity.
• Data minimization by default — no query text in usage metadata, no payload capture unless you turn it on, and a hard seven-day life for payloads that are captured.

14.2 No Absolute Security

No method of transmission over the Internet, and no method of electronic storage, is completely secure. We cannot and do not guarantee the absolute security of your information. Your account security also depends on you: choose a strong, unique password, do not reuse it, treat your API keys as secrets, scope them narrowly, set per-key spend caps, and revoke a key immediately if you believe it has been exposed. Because we hold only a hash of each key, revocation and reissue is the only remedy available for a leaked key — but it is a complete one.

14.3 Security Incidents

If a security incident affects your personal information, we will notify you and the relevant supervisory or regulatory authorities as and when required by applicable law, and we will tell you what we know, what we do not yet know, and what we are doing about it. Where STELQ is acting as your processor under Section 9, we will notify you without undue delay after becoming aware of a personal data breach affecting data you control, so that you can meet your own notification obligations.

To report a vulnerability or a suspected incident, write to privacy@stelq.com with "Security" in the subject line, or open a ticket in the Console support desk marked "Security." We do not pursue legal action against good-faith security researchers who report findings responsibly and who do not access, alter, or exfiltrate other customers' data.

15Your Rights and Choices

15.1 What You Can Do Yourself in the Console

Much of what a privacy request would otherwise be needed for is self-service. Signed in to the Console, you can:

• review and update your account details and email address;
• change your password;
• create, name, scope, and revoke API keys;
• turn full payload logging on or off for any individual key;
• set and change per-key monthly spend caps;
• manage low-balance alerts and turn auto-reload on or off;
• view and export your usage and billing ledger as CSV;
• export research folders as a zip archive;
• delete individual threads, reports, and Watches; and
• close your account by asking us to, as described in Section 15.2.

15.2 What Requires a Request

For anything you cannot do in the Console — a complete copy of the personal data we hold about you, correction of data you cannot edit, deletion of data outside the Console's reach, an objection to processing, or a restriction request — write to privacy@stelq.com. If you do not have an account, that address works for you too; so does the postal address in Section 23.

We will take reasonable steps to verify your identity before acting, which usually means confirming control of the email address on the account or, for a non-account holder, asking for enough detail to locate the data at issue. Verification is a legal requirement, not an obstacle: we will not hand your data to someone who merely claims to be you.

We respond within the deadlines set by the law that applies to you, and in any event within forty-five (45) days where United States state privacy law applies, extendable by a further forty-five (45) days where reasonably necessary and where we tell you why.

15.3 Limits

• We may retain information where the law requires it, where it is needed to resolve a dispute or enforce our agreements, or where an exception in Section 13 applies.
• We cannot delete data held by third parties whose records are their own, such as Stripe's transaction records, which they are obliged to keep.
• We cannot recover an API key for you, because we never held it in a recoverable form.
• Deleting your account ends your access to the Services, including your Workspace threads, research reports, Watches, and any unused Credit that you have not asked us to refund first.
• Where you are an end user of a STELQ customer, and the data at issue is in that customer's Inputs, we will route your request to the customer rather than act on it unilaterally, because they and not we decide what happens to it.

15.4 Communication Preferences

• Transactional and service messages — about authentication, billing, security, low balance, and material changes — are necessary to operate the Services and cannot be turned off while your account is open.
• STELQ Live follower email — one-click unsubscribe in every message, no login required. See Section 10.3.
• Notification settings for alerts and Watch deliveries are managed in the Console.

15.5 No Discrimination

We will not discriminate against you for exercising any privacy right. We will not deny you the Services, charge you a different price, give you a lower quality of service, or suggest that we might, because you made a request under this Policy or under any privacy law.

16California Privacy Rights (CCPA/CPRA)

16.1 Applicability

If you are a California resident, you have rights under the California Consumer Privacy Act as amended by the California Privacy Rights Act ("CCPA/CPRA"), Cal. Civ. Code Section 1798.100 et seq. This Section supplements the rest of this Policy and controls to the extent of any conflict for California residents.

16.2 Categories of Personal Information Collected, Sources, Purposes, and Recipients

In the preceding twelve (12) months we have collected the following categories of personal information. "Disclosed to" means disclosed to a service provider or contractor for a business purpose; it does not mean sold or shared.

Personal data that a customer submits inside an Input may fall into other categories entirely. For that data STELQ is a service provider under Cal. Civ. Code Section 1798.140(ag) and the customer is the business; see Section 9.

16.3 We Do Not Sell or Share Personal Information

STELQ does not sell personal information, and STELQ does not share personal information for cross-context behavioral advertising, as those terms are defined by the CCPA/CPRA. We have not sold or shared personal information in the preceding twelve (12) months, and we do not have actual knowledge of selling or sharing the personal information of any consumer under sixteen (16) years of age. Disclosures to the service providers and contractors listed in Section 8.1, for the business purposes stated there, are not sales or sharing. We nonetheless honor the Global Privacy Control signal as described in Section 12.4.

16.4 Your California Rights

• Right to know. Request disclosure of the categories and specific pieces of personal information we have collected about you, the categories of sources, the business or commercial purpose for collecting it, and the categories of third parties to whom we disclose it.
• Right to delete. Request deletion of personal information we have collected from you, subject to the statutory exceptions — including our need to complete a transaction, detect and prevent fraud and abuse, maintain security, comply with a legal obligation, or use the information internally in a lawful manner compatible with the context in which you provided it.
• Right to correct. Request correction of inaccurate personal information, taking into account its nature and the purposes of processing.
• Right to opt out of sale or sharing. We do not sell or share personal information, so there is nothing to opt out of. If that ever changes we will provide a conspicuous "Do Not Sell or Share My Personal Information" link before it does.
• Right to limit the use of sensitive personal information. We do not use or disclose sensitive personal information for purposes that trigger this right.
• Right to data portability. Receive the personal information you provided in a readily usable format. Much of this is available immediately in the Console as CSV and zip exports.
• Right to non-discrimination. See Section 15.5.

16.5 How to Exercise Your California Rights

Write to privacy@stelq.com with "California Privacy Request" in the subject line, open a ticket in the Console support desk with the same subject, or write to the postal address in Section 23. Tell us which right you are exercising. We will acknowledge receipt within ten (10) business days, verify your identity, and respond within forty-five (45) days, extendable by a further forty-five (45) days where reasonably necessary and where we notify you of the extension and the reason for it.

16.6 Authorized Agents

You may designate an authorized agent to make a request on your behalf. The agent must provide written authorization signed by you, and we may still require you to verify your identity directly with us and to confirm that you gave the agent permission. An agent registered with the California Secretary of State acting under a valid power of attorney need not provide separate written authorization.

16.7 Financial Incentives

The free welcome Credit given to a new account is not intended to be a financial incentive program under the CCPA/CPRA. It is offered to every new account on the same terms, it is not conditioned on any consent to data processing beyond what is necessary to operate the Services, and its value is reasonably related to the value of operating an account.

17EEA, United Kingdom, and Swiss Users (GDPR)

17.1 Applicability and Roles

If you are in the European Economic Area, the United Kingdom, or Switzerland, you have rights under the General Data Protection Regulation, the UK GDPR, and the Swiss Federal Act on Data Protection. STELQ is the controller of the personal data described in Section 4 that relates to your relationship with us, and the processor of the personal data inside your Inputs, as described in Section 9.

17.2 Legal Bases for Processing

Where we rely on legitimate interests, we have carried out a balancing assessment and concluded that our interests are not overridden by your rights and freedoms. You may ask us for a summary of that assessment for any specific processing.

17.3 Your GDPR Rights

• Access. Obtain confirmation of whether we process your personal data and a copy of it.
• Rectification. Have inaccurate or incomplete data corrected.
• Erasure. Have your data deleted where one of the grounds in Article 17 applies.
• Restriction. Have processing restricted in the circumstances set out in Article 18.
• Portability. Receive data you provided in a structured, commonly used, machine-readable format, and have it transmitted to another controller where technically feasible.
• Object. Object at any time, on grounds relating to your particular situation, to processing based on legitimate interests — including the fraud meter described in Section 5 and the publication of a Live story that concerns you.
• Withdraw consent. Withdraw consent at any time where processing is based on consent, without affecting the lawfulness of processing carried out before withdrawal.
• Automated decision-making. You have the right not to be subject to a decision based solely on automated processing that produces legal effects concerning you or similarly significantly affects you. We do not make such decisions. The identity meter scores rather than blocks, and a human reviews any adverse outcome, as stated in Section 5.5.
• Complain. Lodge a complaint with your national supervisory authority, or with the Information Commissioner's Office in the United Kingdom or the Federal Data Protection and Information Commissioner in Switzerland. We would appreciate the chance to address your concern first.

17.4 International Transfers

See Section 11, which describes both directions of transfer and names the Standard Contractual Clauses and the UK Addendum as the mechanisms we rely on.

17.5 Data Protection Contact

STELQ is not required to appoint a Data Protection Officer, and has not appointed one. Our data protection point of contact is reachable at privacy@stelq.com — please use "GDPR Request" as the subject line — or at the postal address in Section 23. If you require an EU or UK Article 27 representative for your own compliance assessment, contact legal@stelq.com and we will tell you our current position honestly.

18Other United States State Privacy Rights

18.1 Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, and Comparable Laws

If you are a resident of Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, or another state with a comprehensive consumer privacy law, you may have rights to:

• confirm whether we process your personal data and access it;
• correct inaccuracies, taking into account the nature of the data and the purpose of processing;
• delete personal data we hold about you;
• obtain a portable copy of data you provided;
• opt out of the processing of personal data for targeted advertising, the sale of personal data, and profiling in furtherance of decisions producing legal or similarly significant effects; and
• appeal a refusal of any of the above.

We do not process personal data for targeted advertising, we do not sell personal data, and we do not conduct profiling in furtherance of decisions that produce legal or similarly significant effects. The opt-out right therefore has nothing to operate on in our case, but we honor the Global Privacy Control signal as described in Section 12.4 and we will honor an express opt-out request all the same.

Several of these laws require consent before processing sensitive data, which typically includes precise geolocation, biometric or genetic data, health data, data revealing racial or ethnic origin, religious beliefs, immigration status, sexual orientation, and data from a known child. We do not knowingly collect sensitive data, and Section 7.3 asks you not to send it to us.

To exercise a right, write to privacy@stelq.com with "[Your State] Privacy Request" in the subject line, or use the postal address in Section 23. We will verify and respond within the period your state's law allows, generally forty-five (45) days, extendable where the law permits.

Appeals. If we decline your request, we will tell you why and how to appeal. To appeal, reply to our decision with "Privacy Appeal" in the subject line. We will review the appeal and inform you in writing of the outcome and our reasoning within the period your state's law requires, generally sixty (60) days, and we will tell you how to contact your state Attorney General if you remain dissatisfied.

18.2 Washington My Health My Data Act

STELQ is a Washington company, and the Washington My Health My Data Act ("MHMDA"), RCW 19.373, applies to entities that collect "consumer health data" from Washington residents. We address it directly.

STELQ does not collect, process, sell, or share consumer health data as defined by the MHMDA. We do not collect health conditions, diagnoses, treatments, medications, bodily functions, vital signs, reproductive or sexual health information, gender-affirming care information, biometric data, precise location that could indicate an attempt to acquire health services, or any data used to identify a consumer's past, present, or future physical or mental health status. We do not derive or infer health data from any of the information described in Section 4, we do not operate a geofence around any health care facility, and we have no advertising business that could make such inferences valuable to us.

There is one boundary worth naming honestly. A customer's Input — a search query, a research prompt, or a Watch specification — could in principle contain health-related text, because a customer can type anything into a general-purpose research tool. Where that happens, STELQ is a processor acting on the customer's instructions under Section 9, we do not use that text for any purpose other than returning the Output, and — unless the customer has enabled per-key full logging — we do not retain it at all. Section 7.3 asks customers not to submit health data to the Services. If you believe consumer health data about you has reached us through a customer's Input, write to privacy@stelq.com and we will act on it under Section 9.3 and the MHMDA.

If you are a Washington resident and wish to exercise a right under the MHMDA — to confirm whether we collect, share, or sell your consumer health data, to withdraw consent, or to request deletion — write to privacy@stelq.com with "MHMDA Request" in the subject line. We will respond within forty-five (45) days, extendable by a further forty-five (45) days where reasonably necessary. We do not sell consumer health data and we have never sold consumer health data, so no valid authorization under RCW 19.373.100 exists or has ever been sought.

18.3 Nevada

Nevada residents may direct us not to sell certain covered information. We do not sell covered information. Requests may be sent to privacy@stelq.com.

19Children's Privacy

The Services are intended for users who are eighteen (18) years of age or older, and eligibility is a condition of our Terms of Service. The Services are not directed to children, we do not market them to children, and they contain no content designed to appeal to children.

We do not knowingly collect personal information from anyone under 18, and in no event from a child under 13 (or under 16 in the European Economic Area and the United Kingdom, where a lower age has not been set by national law). If we learn that we have collected personal information from a child under the applicable age, we will delete that information promptly and, where an account exists, terminate it.

If you are a parent or guardian and you believe a child has provided us with personal information, write to privacy@stelq.com and we will act on it. We do not have actual knowledge of selling or sharing the personal information of consumers under 16 years of age, and we do not sell or share personal information at all.

Customers are responsible for not submitting personal data about children in their Inputs. See Sections 7.3 and 9.3.

20Links to Other Websites and Services

The Services, and in particular our Outputs, are full of links to third-party websites. Search results, extracted content, cited answers, research reports, and STELQ Live stories all reference and link to sources on the open web that we do not control. When you follow such a link, the privacy policy and data practices of the destination site govern, not ours. A citation in an Output is not an endorsement of the linked site, of its accuracy, or of its privacy practices. We are not responsible for the content, security, or data handling of any third-party site.

21Law Enforcement and Legal Process

STELQ may access, preserve, and disclose your information if we believe in good faith that doing so is required or appropriate to: (a) comply with applicable law, regulation, subpoena, court order, or other legal process, or a lawful governmental or regulatory request; (b) enforce this Policy and our Terms of Service, including the investigation of potential violations; (c) detect, prevent, or otherwise address fraud, security, or technical issues; or (d) protect the rights, property, or personal safety of STELQ, our customers, or the public.

Where we are legally permitted to do so, and where we are not prohibited by the terms of the process itself or by a court order, we will make reasonable efforts to notify an affected account holder of a legal demand for their data before we produce it, so that they have an opportunity to object. We will construe overbroad demands narrowly and will require valid legal process appropriate to the data sought.

There are two things worth knowing about what a legal demand can actually reach:

• We cannot produce your API keys, because we hold only hashes of them.
• We cannot produce request or response payloads that we never captured, and we cannot produce captured payloads more than seven days old, because they have been deleted. A demand cannot make us produce data that no longer exists.

Legal process should be directed to legal@stelq.com or to the postal address in Section 23.

22Business Transfer

If STELQ is involved in a merger, acquisition, financing, reorganization, sale of all or part of our assets, bankruptcy, or a similar transaction, your information may be transferred or sold as part of that transaction or evaluated as part of the diligence for it. The promises in this Privacy Policy will continue to apply to your information as transferred, and any acquirer will be required to honor them or to give you notice and a meaningful choice before applying materially different terms. We will notify you of any such transfer — by email, by notice in the Console, or by a prominent notice on the Site — and tell you what choices you have.

23Contact Us

If you have any question about this Privacy Policy, or wish to exercise any right described in it, contact us. You do not need a STELQ account to contact us, and we will not require you to create one.

• Privacy requests, data-subject rights requests, security reports, and STELQ Live corrections and removals — privacy@stelq.com
• Legal notices and formal legal process — legal@stelq.com
• Everything else — support@stelq.com, or the support desk inside the Console, which is the fastest route for account holders and is tracked to resolution

Where this Policy asks you to label a request — for example "California Privacy Request," "GDPR Request," "MHMDA Request," "DPA Request," "Privacy Appeal," or "Security" — please put that label in the subject line of your email or ticket, or on the envelope, so that we can route it against the response deadlines that apply to it.

Our postal address, which may be used for any request described in this Policy:

• Ostrel Software LLC (d/b/a STELQ)
• State of organization: Washington, United States of America
• 522 W Riverside Ave, Ste N
• Spokane, WA 99201
• United States

See also our [Terms of Service](/legal/terms) and our [Auto-Reload Terms](/legal/auto-reload-terms).