Privacy notice

Who handles these records

Seller

Mark, an individual

Support e-mail

support@shogunhooks.com

This draft covers the hosted licence, billing, alert relay and support service described in worker.js and schema.sql. It names each database table and the retention rules visible in those files.

The service runs on Cloudflare Workers. Its database tables are stored in Cloudflare D1. Stripe handles payment details. We do not receive or store your card number.

Purchases and licence records

Subscriber accounts: subscribers

We store your subscriber ID, e-mail, plan, subscription status, paid-until date, machine limit, creation time, notes and Stripe customer ID. These records can come from Stripe billing and checkout information or an operator-created account. They let us match payments to your licence and check access.

When checkout starts, the worker sends Stripe your selected plan and any e-mail you supplied. It reads checkout, subscription and customer information from Stripe to verify payment and update access. To open the billing portal, it sends Stripe your customer ID and a return address.

No age-based deletion rule is defined for this table. Kept while your account exists and afterwards as the record of your purchases; ask us and we delete it when you close your account, except what tax and receipt records require us to keep.

Checkout claims: checkout_sessions

We store the Stripe checkout session ID, plan, creation time, and the subscriber ID and claim time when a licence is claimed. This stops the same checkout from issuing a key twice. Stripe returns the session ID in the claim-page address. The claim page sends it to the worker to verify the purchase.

Scheduled cleanup targets unclaimed rows more than 30 days after creation. Claimed rows are excluded from that cleanup so the single-use record remains. Claimed rows are kept, because this record is what stops one purchase from issuing two licence keys. It holds no card details.

Licence keys: licence_keys

The worker generates or receives your key when issuing it or checking access. This table stores its SHA-256 hash, subscriber ID, creation time and any revocation time. It does not store the readable key. Replacing a key marks the old hash revoked; it does not delete that row.

No age-based deletion rule is defined. Kept (as a hash, never the key itself) while your account exists; ask us and we delete it when you close your account.

Machines and webhook access

Activated machines: activations

Your app sends a hashed machine fingerprint and its version when it activates. We store those with your subscriber ID and first-seen and last-seen times. Validation updates the last-seen time. These records enforce the machine limit and show activated machines on your account page.

Freeing a machine slot deletes its activation row. An operator can also remove it, including during a key replacement if machine release is requested. Related audit events remain subject to their own cleanup rule.

No age-based deletion rule is defined for remaining rows. Kept while your account exists; deleted when you remove that machine on the account page, when we free it for you (for example during a licence-key replacement), or when you ask us.

Activation and validation return signed licence tokens to your app. These tokens have a 14-day lifetime. Token expiry does not delete the database records.

Webhook credentials: endpoints

We store your subscriber ID, a generated webhook path token, an alert secret, a creation time and a field for a rotation time. The worker returns the path token and secret to your app. TradingView sends the secret with your alerts. Your app also uses the secret when collecting alerts.

The endpoint secret is stored as a usable value, not as a licence-key hash. It is needed to check incoming alerts and requests to collect them. No timed deletion, rotation or deletion on cancellation is defined. Kept while your account exists; ask us and we delete it when you close your account.

Relayed alerts

Alert queue: signals

TradingView sends your alert to the hosted webhook. The worker stores its sequence number, channel or strategy name, signal ID, timestamp, position direction and alert body. Private alerts also carry your subscriber ID. Your app collects those private alerts using your endpoint credentials.

The saved body contains the fields you send, such as an order action, quantity or price. Before saving, the worker removes these top-level fields: secret, path_token, licence_key, token, authorization and password. Nested values and other text are not covered by that filter. Do not put broker logins or other secrets in an alert.

The relay queues messages. It does not connect to your broker or place orders. Scheduled cleanup targets alerts whose stored signal timestamp is more than 7 days old. That timestamp can come from the alert itself.

Channel permissions: subscriptions

This table stores a subscriber ID, channel name and creation time when an operator grants access to a broadcast channel. It is separate from your billing subscription. The worker can store publisher-submitted alerts in signals and deliver them to subscribers with that permission. Your private alerts are scoped to your subscriber ID.

Shogun's current software subscription includes no trading strategies or signals. These channel records describe a separate capability in the service code.

Removing a channel permission deletes that row. No age-based cleanup is defined. Kept while your account exists; deleted when the channel permission is removed, or when you ask us after closing your account.

Support and operational records

Messages: support_requests

The contact form stores a message reference, creation time, request type, reply e-mail, message text, any linked subscriber ID, handling state and handled time. An optional licence key is used to find the account; that key field is not saved. Recognised licence-key text pasted into the message is replaced with a removal notice. Other message text is kept.

The worker also creates internal support requests on its own when Stripe reports billing for a retired plan, a full refund or a dispute, and when the app reports a serious problem (see below). The operator reads these records through the authenticated support queue. Marking a request handled changes its state; it does not delete it.

When a support request opens, the worker e-mails the operator a notice, usually within 10 minutes, and once a day lists requests still open after 48 hours. A notice holds the request's reference, type, creation time, reply e-mail, whether it is linked to an account, and up to 300 characters of its text, with licence keys and sign-in tokens removed. It goes through Cloudflare to the operator's own e-mail inbox, which Google hosts, and stays there under that inbox's settings. Mail sent to the support e-mail address above reaches the same inbox. The table records when the operator was notified.

No age-based cleanup is defined. Kept as the record of your support conversation; ask us and we delete it.

Audit trail: events

We record activation attempts, refused validations, billing and account actions, alert relay activity, support actions, operator changes and cleanup results. Each row has an ID, time, event type, any subscriber or machine reference, and up to 500 characters of detail.

Details can include e-mail addresses, Stripe references, channel and signal names, membership references, TradingView usernames and error information. Scheduled cleanup targets events more than 90 days old.

Access records for separate products

For separate products sold elsewhere, the worker can import membership data from a third-party sales platform or an operator-supplied list. It can also use Stripe checkout data for older purchases of them. It stores a membership reference, TradingView username, e-mail, plan, source, access-work state, first-seen time, last-valid time, change time and notes.

The operator uses this queue to track manual grants and removals of TradingView access. It is not proof of current TradingView access. The current Shogun checkout does not request a TradingView username.

Marking access revoked does not delete the row. No age-based cleanup is defined. Kept as the record of access granted under the retired plans; ask us and we delete it.

Software releases: releases

This table holds one record per release channel: its version, signed update manifest and publication time. The manifest contains the download address, file checksum, minimum version, release notes and issue time. It supplies the public update and download pages.

Publishing to the same channel replaces its previous record. No age-based deletion rule is defined. Replaced each time a new update is published. It holds no personal data.

Error reports and diagnostics from the app

Automatic error reports: support_errors

Shogun sends a report only when something fails, such as an order that could not close, a lost broker or relay connection, or a crash. Reports are batched: at most one upload every 5 minutes and 24 a day. Each holds the error message, where in Shogun it happened, how many times, when, and the Shogun version. This is on by default; turn it off in Setup → Licence → Support, and the change applies at once.

We store an error fingerprint, its kind, severity and source, the message and stack trace with licence keys removed, occurrence counts, the app's own timestamps and version, and our server's receive time. Scheduled cleanup targets error records not received for 90 days and upload receipts older than 24 hours. Receipts hold an ID, counts, app send and server receive times, account and machine hashes, and an overflow count. A backlog or failed cleanup can delay deletion.

Diagnostics you choose to send: support_diagnostics

Only when you press Send to support, Shogun sends the last part of its log, its recent errors, its health report, its version, basic details of your operating system, your note, and redacted settings structure and selected values, including instruments and sizing. Custom names can remain. You get a short reference such as D-7K2QXM to quote to us. Scheduled cleanup targets diagnostics received more than 30 days ago; a backlog or failed cleanup can delay deletion.

What these never carry, and how they are keyed

Shogun removes broker passwords, your licence key, your webhook URL and alert secret, PINs, e-mail and IP addresses and your Windows user name before sending. Configured account identifiers become pseudonyms; recognisable unconfigured identifiers may retain their last four characters. Our server removes licence keys and sign-in tokens again and never stores your machine identifier: reports are filed under SHA-256 fingerprints of your account and machine instead of the identifiers themselves. That is not anonymity — we hold your account record, so we can match a report to you when we need to help.

Anything else you type into a note can remain, so please do not put private details there. One exception to the fingerprints, on purpose: when Shogun reports a serious problem (a crash, a prop-account flatten that did not complete, or a refused flatten), we open or reopen one item per kind of problem in our support queue, linked to your account, so we can contact you. It holds a short excerpt (up to 200 characters, with licence keys removed) and stays until we mark it handled. Only the operator's full admin access can read the reports themselves. Cleanup deletes at most 2,000 rows per table per run, so a backlog can delay it.

Request checks and browser memory

The worker reads the connecting IP address to limit checkout and contact requests and repeated refusal logs. For an IPv6 address it uses only the network half (the first 64 bits), which is shared by the devices on one connection. It passes rate-limit keys to Cloudflare's configured limiters. If those are unavailable, it keeps counters in worker memory. Repeated-log checks also use worker memory.

The fallback counters use one-minute windows. Repeated refusal logs are suppressed for one hour per source and request category. Those windows are not deletion deadlines. Memory entries stay until the worker restarts, except that the rate-limit list is wiped when it passes 2,000 entries and refusal-log entries more than an hour old are dropped when that list reaches 500. Counters keyed to your IP address are never written to our database; they exist only in Cloudflare's rate limiter and in worker memory. For rate limiting the database keeps a daily count of contact-form messages (no IP address or other personal data) and, for desktop support uploads, one-day receipts keyed to hashed machine and account ids.

The account-page script keeps your licence key in page memory and sends it with account requests. It does not create a login cookie or write the key to browser storage. The separate operator page uses browser session storage for its operator access token.

How cleanup works

The 7-day, 90-day and 30-day thresholds above apply when scheduled cleanup runs. Each run deletes at most 2,000 eligible rows from each of signals, events and checkout_sessions. A backlog, failed run or stopped schedule can leave older records in place. These are cleanup thresholds, not exact deletion deadlines.

Cancellation changes subscription status. It does not erase your account, support messages or other records. A record removed from one table may still be referred to in the audit trail.

For a question about your records, or to ask for a copy, correction or deletion, use the contact form or the support e-mail listed above. Do not include card numbers, broker passwords or alert secrets in your message.