Cookie Policy

This page lists every cookie autopostingpro.com sets and why. The short version: we use first-party cookies only — the ones needed to sign you in and keep your account secure, plus a single non-essential one (ap_attr) that records which channel first sent you here, so we know which of our own marketing efforts actually work. We do not use advertising cookies, third-party analytics cookies, or cross-site tracking of any kind. We measure site traffic with Vercel Web Analytics, which is cookieless: it reports aggregate page views, referrers, country, device class, and fixed interaction events such as CTA clicks, demo plays, plan choices and sections viewed. Those events contain labels chosen by us—not anything a visitor typed—and do not create a cross-site profile or store an identifier on the visitor’s device.

After Stripe accepts a request to create a hosted checkout, AutoPosting Pro attempts to keep one server-side acquisition checkpoint so a browser click is not mistaken for a working checkout. That checkpoint contains only the selected plan and billing interval, a coarse fixed first-touch source category, and the landing-page version when present. Dynamic campaign and referrer text is not stored in this checkpoint. It contains no name, email, IP address, raw URL or referrer, Stripe session or customer ID, account ID, or visitor identifier, and it is not directly linked to an account. If that best-effort checkpoint cannot be recorded, checkout continues; aggregate checkpoint counts are therefore a lower bound, not a complete count of Stripe sessions.

When someone activates a phone or email link on one of our public marketing pages, the page also attempts a best-effort server checkpoint containing only the fixed channel (phone or email) and a coarse source category derived in the browser from ap_attr, if present. The request omits cookies and the browser referrer, and the product audit record stores no name, email address, phone number, destination, message, page, link position, raw URL, referrer, UTM text, account, organization, visitor identifier, or IP address. The server may use the request IP transiently for abuse limiting, and ordinary Vercel infrastructure logs still apply as described below. This activation count is not a lead: repeats, accidental or automated clicks, and clicks whose phone or email handler fails may count, while copied contact details or blocked requests may not.

For an exact campaign link registered by AutoPosting Pro, the normal site client may submit a best-effort first-party campaign-arrival checkpoint after a visible page matches the registered path and all four campaign parameters. The application payload contains only one fixed campaign code; the server derives the fixed source and landing labels from its own registry. This request is separate from the first-touch ap_attr cookie, does not read that cookie, and explicitly omits all cookies and the browser referrer. The application table stores only the UTC day, fixed registered code, and a count bounded at 5,000 per code per day. It stores no per-event timestamp, full URL, raw UTM value, name, account, organization, visitor or device identifier, or IP address. The request IP may be processed transiently into a short-lived HMAC rate-limit key, and ordinary Vercel infrastructure logs still apply outside this application counter. A recorded checkpoint means only that the endpoint incremented the registered key’s daily counter; it does not prove the URL rendered, a link click, referring site, unique or human visitor, dealership, lead, signup, purchase, or customer. Direct or replayed requests, copied links, reloads, multiple tabs, automation, and previews may count; blockers, hidden pages, network failures, request limits, and write failures may be missed. A count of 5,000 means at least 5,000 recorded submissions because the counter stops increasing at that cap. The admin report reads a rolling 90-day window; older daily aggregate rows follow the service’s general retention practice rather than being automatically deleted when they leave that report.

Cookies we set

All of the cookies below are first-party (set by autopostingpro.com) and are used to operate or measure the service. The sign-in cookies are marked HttpOnly and Secure where the browser supports it, and most of them appear only after you sign in. The one exception is ap_attr: it is written by the page itself on your first visit to an allowlisted public marketing page, so it is readable by scripts on this site (that is how it is written). A deliberately source-tagged link to the signed-out login page may also establish the campaign source, but the login path itself is not retained as marketing landing evidence; signed-in, operational, legal and arbitrary missing routes do not write it. It stores bounded arrival information: a classified source, referring host and path without the query string, landing path, campaign labels supplied in UTM parameters, first-touch time, and the homepage version when applicable. AutoPosting Pro does not intentionally put personal information in those fields, but an outside link publisher can place personal text in a campaign label or referring path. Campaign links should never contain personal information. On non-HTTPS local development the __Secure-/__Host- prefixes are dropped.

Browser storage (not cookies)

We also use your browser’s localStorage for two small UI preferences. This data never leaves your browser and is not sent to our servers:

• autopostingpro:setup:progress — remembers which steps of the portal setup checklist you have completed.
• ap_cookie_notice_v1 — remembers that you dismissed the cookie notice so we do not show it again.

What we do not use

• No advertising or retargeting cookies.
• No third-party analytics cookies (no Google Analytics, no pixels, no session recording). Traffic and fixed on-site interaction measurement use cookieless Vercel Web Analytics and contain no typed content. The one first-party exception is ap_attr above, which records the bounded arrival fields disclosed above.
• No cross-site tracking or fingerprinting.
• We do not sell or share your data for advertising.

Third-party services

• Stripe — payments happen on Stripe’s own hosted checkout page (checkout.stripe.com). Stripe sets its own cookies there under its own privacy policy; card details never touch our servers.
• Iconify CDN — the site loads its icon graphics from the Iconify CDN. Those requests carry standard web-request data (IP address, browser info) like any resource load, and set no AutoPosting Pro cookies.
• Infrastructure logs — our hosting provider (Vercel) keeps standard server logs (IP address, user agent, timestamps) for security and operations, and the domain’s DNS and email routing run through Cloudflare. These are ordinary infrastructure records, not tracking cookies.

Managing cookies

You can block or delete cookies in your browser settings at any time. Blocking the sign-in cookies will prevent you from signing in to the portal — the public marketing pages work fine without any cookies at all. Blocking or deleting ap_attr changes nothing about how the site works for you and prevents durable first-touch attribution. The separate fixed-code campaign-arrival checkpoint does not use that cookie; browser privacy controls or content blockers can block its first-party request. If you start checkout or sign up directly from a current AutoPosting Pro page whose same-origin URL still contains campaign or click information, that current-page source may still be classified for that one request. Since we do no cross-site tracking and share nothing with advertisers, there is nothing else to opt out of.

Changes & contact

If we ever add a new cookie, we will list it here and update the date above. Questions: [email protected]. See also our Privacy Policy.

This document is provided as a general template and does not constitute legal advice. Have counsel review it before relying on it.