Freebuff Ads · Legal
Last updated September 16, 2026
Freebuff Ads: Data Security Overview
Last updated September 16, 2026.
This overview is written for the security, privacy, and legal teams of companies that advertise with Freebuff. It describes how the Freebuff Ads platform is built and operated, what data we hold about advertisers, what data advertisers receive about Freebuff users, and how to reach us. It describes our practices; it is not a contract. The Advertiser Terms of Service at freebuff.com/ads/terms and the Privacy Policy at freebuff.com/privacy-policy govern.
At a glance
- Advertisers never receive the prompts, code, repositories, files, identities, or contact details of Freebuff users. Reporting is aggregate, and click identifiers are opaque and signed.
- Payment card details are handled by Stripe on Stripe-hosted pages. Card numbers never touch Freebuff servers.
- Advertiser API keys are stored only as SHA-256 hashes, are shown once at creation, are scoped, and can be revoked at any time.
- All traffic to and from freebuff.com is encrypted in transit with TLS, and so are our connections to our database and to third-party providers. Our managed database provider encrypts stored data at rest.
- Production secrets live in a dedicated secrets manager, never in source code.
- Every operator action on an advertiser account is attributed to a named Freebuff staff member and recorded.
- Security contact for vulnerability reports and incident questions: support@codebuff.com.
1. Architecture and hosting
The Ads Services are part of the Freebuff web application, a Next.js service deployed on Render in the United States. Advertiser, campaign, delivery, conversion, and billing records are stored in a managed PostgreSQL database hosted by Render in Oregon, United States. Short-lived operational state, such as rate-limit counters and frequency-cap reservations, is held in a managed Redis-compatible store. Sponsored proposals shown inside Freebuff Web are stored in Convex, the application database for that product. Cloudflare sits in front of freebuff.com.
Production deployments are made from the main branch of our source repository after automated type checks and tests. Database schema changes are applied by versioned migrations on deploy.
2. Data we hold about advertisers
| Category | Examples | Where it lives |
|---|---|---|
| Account and team | Company name, website, billing email, owner and member email addresses, invitations, review status | PostgreSQL |
| Billing | Stripe customer and payment-method identifiers, prepaid balance, statements, an append-only spend ledger, promotional credit | PostgreSQL; card details at Stripe |
| Campaigns and ads | Campaign settings, budgets, creatives, logos and images, landing URLs, targeting, review notes and decisions | PostgreSQL |
| Credentials | SHA-256 hashes of API keys, key prefixes, scopes, expiry, and revocation state | PostgreSQL |
| Conversion data you send | Click identifier, event type, event id, timestamp, reporting channel | PostgreSQL |
| Agreement records | Accepted Terms version and body hash, acceptance time, IP address, and browser user agent of the accepting owner | PostgreSQL |
| Operator audit | Which Freebuff staff member changed what, when, and why | PostgreSQL and logs |
We do not store payment card numbers, security codes, or bank details. Card setup and top-ups use Stripe-hosted pages, and we keep only the identifiers Stripe returns.
If you use the identity-matching feature and send an email address with a conversion, the address is normalized and hashed in memory, used to look up your own clicks, and discarded. It is not written to the database or to logs.
3. Data advertisers receive about Freebuff users
Advertisers receive:
- Aggregate delivery metrics: impressions, views, clicks, spend, and conversions per day, per campaign, per creative, per placement, and per country.
- Opaque click identifiers, signed by Freebuff and attached to clicks on your ads, so that you can report conversions.
- Your own reported conversion events, including whether an email-matched event matched one of your clicks (only where that feature is enabled).
- Monthly statements and adjustment summaries.
Advertisers do not receive:
- Users' prompts, messages, code, repositories, files, project names, or any content of a coding session.
- Users' names, email addresses, account identifiers, IP addresses, or device identifiers.
- Per-event fraud signals, or the reason a specific event was treated as invalid.
- Other advertisers' campaigns, prices, allocations, or results.
- Membership of measurement holdout groups.
A click identifier is an HMAC-signed token bound to one click. It carries no user information, and the conversion endpoints accept it only from the advertiser that owns the click.
4. Data flows you may integrate
Server-to-server conversion postback. Your backend sends a click identifier, event type, event id, and timestamp to our API over HTTPS with your API key. Requests are validated against strict schemas, deduplicated on the event id, and rate limited. A forged or tampered click identifier is rejected before any database lookup.
Hosted browser tag. The optional tag at freebuff.com/freebuff-tag.js reads a click identifier from the landing page URL, stores it in a first-party cookie on your own domain, and sends it with an event type and event id only when your page explicitly calls the tag. It sets no other cookies, reads no other data from the page, fires no events automatically, and sends nothing when no click identifier is present. Its source is published, and the exact shipped bytes are covered by automated tests.
Reporting API and MCP server. Read-scoped API keys can export delivery and conversion data and drive the console through an MCP server. Every tool re-checks the key's scope and the account's capabilities on each call.
Sponsored proposals. If you run a sponsored-proposal campaign, the procedure you author is reviewed before approval and runs only after a user accepts it, inside that user's own environment under the safeguards we apply. The results of the task belong to the user; you receive funnel counts and the billable acceptance event.
5. Access control
- Every console page and API route resolves the advertiser from the verified session or from the API key, never from an identifier supplied in the request. An identifier in a URL is never treated as authorization.
- Accounts have an owner and members. Only the owner can manage the team or accept the Advertiser Terms. Team invitations are matched against the invitee's verified email address.
- API keys are scoped (ingest or read), can be created in test mode, can carry an expiry, and can be revoked immediately from the console or the MCP server.
- Operator actions on advertiser accounts require a Freebuff admin role. Money-affecting overrides require a higher, separately granted role. Each action is recorded with the acting staff member's identity, and campaign changes carry a stated reason and an audit row.
- Access to production infrastructure and secrets is restricted to authorized Freebuff personnel.
6. Encryption and secrets
- All client connections to freebuff.com use HTTPS (TLS). Our database connections and our calls to third-party providers are encrypted in transit.
- Our managed database provider encrypts data at rest and takes automated backups.
- Click identifiers, first-party click capabilities, and conversion tokens are signed with secret keys that never leave our servers and are never exposed in the console.
- API keys are hashed with SHA-256 before storage. The plaintext is shown once at creation and cannot be recovered by Freebuff.
- Production secrets and configuration are managed in a dedicated secrets manager (Infisical) and injected at deploy time. Secrets are not committed to source control.
7. Application security practices
- Input validation with strict schemas on every advertiser-facing endpoint, including size limits and content-type checks.
- Idempotent writes for money and conversion records: duplicate postbacks, payment webhooks, and top-ups are recognized and do not create duplicate charges.
- Append-only ledgers for spend and for agreement acceptance, so financial history is never rewritten.
- Rate limits and per-advertiser budgets on identity-matching and other high-volume endpoints.
- Signed, expiring tokens on click and impression paths, so a leaked or guessed URL cannot bill a click.
- Automated tests and type checks on every change, including route-level tests that pin authorization behavior.
- Structured server logging to a central log platform (Axiom). Logs carry request metadata and identifiers; they do not carry payment details, API key plaintext, or the email addresses sent for identity matching.
8. Retention and deletion
- Advertiser account, campaign, creative, delivery, conversion, and billing records are retained while your account is open and afterward as needed for financial records, dispute resolution, and legal compliance.
- Raw ad impression logs are deleted after 30 days. Daily delivery aggregates, which feed your reports, are retained.
- Deleting a campaign removes its configuration but keeps its delivery and billing history, shown under a neutral name in exports, so that statements remain reconcilable.
- To close your account or request deletion of advertiser data, email support@codebuff.com from the account owner's address. We will confirm what was deleted and what must be retained.
- Freebuff users can delete their own accounts. User-level deletion does not affect your aggregate reporting.
9. Subprocessors
| Provider | Purpose | Data involved |
|---|---|---|
| Render | Application hosting and managed PostgreSQL (United States) | All advertiser data |
| Cloudflare | Edge network, request routing, bot protection | Request metadata |
| Stripe | Payment processing, card storage, invoices | Billing contact and payment details |
| Resend | Transactional email (invitations, review decisions, notices) | Names and email addresses |
| Convex | Application database for Freebuff Web features, including sponsored proposals | Sponsored-proposal content and funnel events |
| Axiom | Log storage and monitoring | Request metadata and identifiers |
| PostHog | Product analytics for freebuff.com | Usage events |
| Slack | Internal operations notifications to Freebuff staff | Company name, campaign name, review events |
| Firecrawl | Fetching a public post you submit for an engagement campaign, to draft its description | The public post's content |
| OpenRouter and Google (Gemini) | Automated review of the engagement evidence that users submit | User-submitted screenshots and links, not advertiser account data |
We update this list when providers change.
10. Incident response and vulnerability reporting
- If we confirm a security incident that affects your advertiser data, we will notify the account owner without undue delay and tell you what happened, what data was involved, and what we are doing about it.
- To report a vulnerability in any Freebuff product, email support@codebuff.com. Please do not file security reports in public issue trackers or on social media. We investigate every legitimate report and prioritize fixes by severity.
11. Certifications and questionnaires
Freebuff has not published a SOC 2 or ISO 27001 report. If your review requires a completed security questionnaire, a data processing addendum, or more detail on any item above, contact support@codebuff.com and we will work through it with you.