Security

Data minimization and hashing

The tracking layer is designed so that even our own database cannot identify the people behind a click. When a user hits GET {edge}/r/:affiliate_id, the edge tracker reads the request IP, User-Agent and Accept-Language to derive two values: a salted SHA-256 device fingerprint and a salted SHA-256 ip_hash. The plaintext IP address is never stored — only its salted hash is written to the click record.

The salt is a secret known only to the edge tracker and the API. Because both services hash with the same salt, two hashes are comparable (allowing rate limiting and fraud signals) without being reversible: an attacker who reads the database cannot recover an IP address or device from a hash, and the hashes are useless without the salt. A stored click record therefore contains only a click id, the affiliate id, the device fingerprint, the ip_hash, the User-Agent, the Accept-Language, a status and a timestamp — no names, no emails, no plaintext IP.

The argus_cid appended to destination URLs is a random 128-bit click identifier, not a personal identifier; it carries no information about the user. For the personal data customers do entrust to us, see the Privacy Policy and the Data Processing Addendum.

Transport and infrastructure

All traffic to Argus Grape is encrypted in transit with TLS — the marketing site, the dashboard, the API and the edge tracker. Internally the platform is split into isolated services that each do one job: a Go edge tracker for redirects, the application API, a PostgreSQL primary for durable state, and Redis for rate-limit counters and ephemeral data. The services communicate over private networking and hold distinct credentials.

Secrets — database credentials, the hashing salt, webhook signing keys — are supplied through the environment at runtime and are never committed to source control or embedded in client-side code. Hosting and managed data stores run on established cloud and database providers; these sub-processors are described in the DPA.

Webhook integrity

Conversions are never trusted from the browser. They are reconciled only from signed webhooks: Stripe events are verified against the Stripe signature, and our internal and partner endpoint at /webhooks/zylior verifies an x-zylior-signature HMAC-SHA256 computed over the raw request body. Signature verification runs on the exact bytes received, before any parsing, so a tampered or replayed payload is rejected.

Processing is idempotent on an external reference, so a webhook delivered more than once produces a single conversion rather than duplicate commissions. Commissions are then split up the multi-level referral tree, which we store with the PostgreSQL ltree extension.

Abuse and fraud prevention

The edge tracker enforces per-IP rate limiting on the salted ip_hash. When a source exceeds the threshold, its clicks are silently flagged shadow_banned — the user is still redirected normally, but any conversion later attributed to a shadow-banned click is automatically rejected so it cannot earn a commission.

On the account side, signup attempts are scored against anti-abuse signals — normalized email, email domain, website domain, hashed IP, device fingerprint and resulting risk flags — to block fraudulent or abusive registrations. What is and isn't permitted is set out in the Acceptable Use Policy.

Access control

We apply least privilege throughout. Database access uses scoped roles so each service can touch only the data it needs, and the edge tracker — the most exposed component — operates with the narrowest footprint of all. Administrative access to production is limited to the people who need it and is granted through the same per-environment secret distribution rather than shared credentials in code.

Data retention and deletion

We keep personal data only as long as it serves the purpose it was collected for. Hashed click and conversion records are retained for the analytics and commission-reconciliation window a campaign needs and are then aged out; because IPs and devices are stored only as salted hashes, retained records are already de-identified at the source.

Account data — workspace, team members, billing and invoices, newsletter subscribers and anti-abuse records — is retained for the life of the account and for the limited period afterward needed to meet legal, accounting and fraud-prevention obligations, then deleted or anonymized. For data we process on a customer's behalf, deletion and return on termination follow the DPA, and individual rights requests are handled as described in the Privacy Policy.

Controls at a glance

Responsible disclosure

We welcome reports from security researchers. If you believe you have found a vulnerability, please email security@argus-grape.com with enough detail to reproduce the issue. We commit to handling reports in good faith: we will acknowledge your report, investigate, keep you informed of our progress, and will not pursue legal action against researchers who follow this policy.

In return, we ask that you give us reasonable time to remediate before public disclosure, do not access, modify or delete data belonging to other users, and do not run destructive, denial-of-service or large-scale automated tests against our systems. Use only test accounts and data you control.