Privacy Policy

Operator: Ecropolis LLC, 8001 Valcasi Dr. Ste 101, Arlington, TX 76001, USA
Contact: [email protected]
Applies to: vendorstreet.app (this website) and app.vendorstreet.app (the Platform)

Who we are and our role

VendorStreet (“the Platform”) is an operating platform for farmers markets, experiences, and venues, operated by Ecropolis LLC.

Organizations that use VendorStreet — market operators, experience operators, and venue operators — use it to manage their own vendors, customers, guests, and attendees. For that data, the organization is the data controller and we are a data processor acting on its instructions. We do not decide the purposes for which an organization’s vendor or customer data is used, and we do not use it for our own purposes.

Where we process an organization’s own account details (staff logins, organization profile, billing status), we act as a controller.

What we process

About organization staff

Login email, display name, optional first/last name and phone number, a salted password hash (we never store the password itself), role, session records, and the date of terms acceptance.

About organizations

Legal and trade name, business address, contact person details, federal EIN (an organization-level tax identifier), plan and billing status, and Stripe billing identifiers.

About vendors (processed for the organization)

About customers and guests (processed for the organization)

We do not store payment card details or bank account numbers — payment is collected on Stripe-hosted pages and the Platform stores only Stripe identifiers, amounts, and statuses. The Platform has no fields for government identifiers of individuals or for special-category data.

Connected calendar and video accounts

An appointments practice can connect a practitioner’s own Zoom, Google or Microsoft account so that bookings reach their calendar and video appointments get a meeting link. Each practitioner connects their own account, can disconnect it at any time, and the connection is used only for the purposes below. These are the practitioner’s own accounts with those companies, under their terms; we act on them only as the practitioner has approved.

Zoom

• What we store: the OAuth access and refresh tokens Zoom issues, the permissions granted, the practitioner’s Zoom user ID (used only to recognise a removal notice from Zoom, and to tell whether another connection is the same Zoom user), and, for each video appointment, the ID and join link of the meeting we created for it. Nothing else.
• What we do with it: create one meeting on the practitioner’s account when a video appointment is booked, move it when the appointment is rescheduled, and delete it when the appointment is cancelled. The join link is shared with the client who booked that appointment.
• What we never access: meeting content, recordings, transcripts, participants, chat, contacts, the practitioner’s profile, or any meeting we did not create. We never join a meeting.
• Deletion: disconnecting Zoom in VendorStreet deletes the stored tokens immediately, then asks Zoom to remove VendorStreet from the account, unless the same Zoom user, or a Zoom connection that doesn’t say which user it is, is still connected in VendorStreet. If a practitioner is removed from the practice, we delete their upcoming meetings first, then their connection, the same way. Removing VendorStreet yourself in Zoom (Manage → Added Apps in the App Marketplace) does the same: Zoom notifies us and we delete the connection. Join links are cleared from an appointment when it is cancelled.

Google Calendar and Google Meet

A practitioner connects their Google account by signing in at Google and approving VendorStreet there. We ask for two permissions at most. Where we ask for both, Google shows each one separately, so a practitioner can allow the first and decline the second.

• Managing events (Google’s calendar.events permission, which Google describes as “View and edit events on all your calendars”). We use it only on their main calendar, and only for events we create: when an appointment is booked with the practitioner, we create an event for it, move it when the appointment is rescheduled, and delete it when the appointment is cancelled. For a Google Meet appointment, the Meet link is created on that event. We never read, change or delete an event we did not create.
• Seeing availability (Google’s calendar.freebusy permission, which Google describes as “View your availability in your calendars”). This one is optional. If the practitioner allows it, we read when their main Google calendar is busy, up to 120 days ahead, so those times are not offered on their booking page. We read it about every 15 minutes, and again when a client reserves a time, an appointment is moved, or a phone booking is taken. Google tells us only when each busy period starts and ends, never what an event is called, who it is with, or where it is. A connection without this permission is never read.
• What we store: the access and refresh tokens Google issues, encrypted; the permissions granted; for each appointment, the ID of the event we created and, for a Meet appointment, the meeting’s ID and join link; and, where availability is allowed, the busy periods, with no detail of what they are. To tell whether two connections are the same Google account, we read the organizer of an event we created, which is the calendar’s address, and keep only a keyed one-way fingerprint of it, never the address. Nothing else comes through this connection: not the account’s profile, contacts, other calendars, or any other Google service. Separately, a practitioner may paste a calendar’s private address, such as a Google calendar’s secret address in iCal format, under Also check these calendars for busy time. We store that address encrypted and read it for busy times only, keeping when they are busy and each event’s ID, never what an event is called or who it is with.
• Who sees it: the Meet link goes to the client who booked that appointment, in their messages about it and on their own booking page, and to the practitioner in any appointment notice the practice sends them. It is not shown on the practice’s schedule. Busy periods are never shown to anyone as events. They only stop those times being offered, to clients and staff alike.
• How long we keep it: the tokens, the fingerprint, the permissions granted and the busy periods are kept until the connection is disconnected. While a connection is working, each busy period is deleted about a day after it ends, and reconnecting without the availability permission deletes them all. An appointment’s event ID and Meet link stay with that appointment, as part of the practice’s records (see Retention). When an appointment is cancelled, we delete its event from the calendar if the connection still works, and remove the Meet link from the booking page and every later message. If the practice closes its account, we delete its connections with the rest of its data when it asks us in writing (see Retention). A practitioner can disconnect, or remove access at Google, at any time.
• Disconnecting: the practitioner, or the practice’s owner or an admin, can disconnect Google on the Calendar & video page. That deletes the connection straight away: the stored tokens, the fingerprint, the permissions granted, and every busy period it brought in, and then asks Google to revoke VendorStreet’s access (see the next point). Events already written to the calendar stay there, to be deleted in Google Calendar if the practitioner wants them gone. Disconnecting is refused while a published Google Meet service depends on the calendar, and the page says what to change first. If a practitioner is removed from the practice, we take their upcoming appointments out of their Google Calendar (past ones stay), then delete the connection, its tokens and its busy periods, usually within minutes, and tell the practice what needs a new connection.
• Removing access at Google: a practitioner can also remove VendorStreet’s access at any time in their Google Account, at myaccount.google.com/permissions. When a connection is disconnected, or its practitioner removed, we delete its tokens and fingerprint, then ask Google to revoke VendorStreet’s access. Google revokes access for the whole account, so we don’t ask while another VendorStreet connection may be the same account: one with the same fingerprint, or one whose account we don’t know yet in the same practice or belonging to the same person. In that case, remove it yourself at the link above. If access is removed at Google first, the connection stops working, and the next time we use it, its row on the Calendar & video page starts asking them to reconnect. Until they reconnect or disconnect, the busy periods we last read keep those times blocked, so a lapsed connection never suddenly offers times they are busy.

Google user data and Limited Use. VendorStreet's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. Google Calendar is a Google Workspace API, so we also follow the Google Workspace API User Data and Developer Policy. These commitments cover the data we receive from Google and anything derived from it:

• We use it only to provide the features described above, which a practitioner turns on by connecting: their appointments on their own calendar, Meet links, and keeping their busy times off their booking page.
• We do not sell it. We do not transfer it to anyone, including advertising platforms, data brokers and information resellers, except to provide those features (the Meet link to the client who booked, and the services that host the Platform and deliver its messages, listed under Sub-processors); for security purposes, such as investigating abuse; to comply with the law; or as part of a merger, acquisition or sale of assets, and then only with the practitioner’s explicit consent first.
• We do not use it for advertising, including retargeting and personalized or interest-based advertising, or to determine anyone’s creditworthiness or for lending.
• We do not use it to create, train or improve any machine-learning or artificial-intelligence model.
• Nobody at Ecropolis reads it unless the practitioner has asked us in writing to look at specific data (for example, to sort out a problem with their connection), it is necessary for security (for example, investigating a bug or abuse), or the law requires it.
• Everyone who works on VendorStreet for us, as an employee or a contractor, is held to these same rules, and so would be anyone who took the business over.

How to connect, reconnect and disconnect is explained in the appointments guide.

Microsoft Outlook calendar

We write an event for each appointment, and read the practitioner’s calendar to keep times they are busy off the booking page. We keep only when they are busy, up to 120 days ahead, with each event’s ID so one read can be compared with the next — never what an event is called or who it is with — and we do not access mail or contacts. Disconnecting deletes the stored tokens and the busy times that connection brought in. If a practitioner is removed from the practice, we take their upcoming appointments out of their calendar, then delete the connection. Microsoft gives apps no way to remove themselves, so after a disconnect VendorStreet stays listed in the account until it is removed at myapps.microsoft.com (work or school accounts; access approved for a whole organisation can only be removed by its administrator) or account.live.com/consent/Manage (personal accounts).

For all three, tokens are encrypted before they are stored (AES-GCM, with the key held outside the database) and are never returned by any listing in the Platform.

What we do not do

• We do not sell personal data. There is no mechanism to do so.
• We do not run advertising trackers, and we do not profile you across other websites. The Platform (app.vendorstreet.app) loads no advertising scripts, and fonts are self-hosted. It uses PostHog for product analytics, to see how the Platform is used and to find problems (see Cookies below). This marketing website uses Google Analytics for basic traffic measurement — European visitors are asked first, everyone else can opt out on the cookie banner — with advertising and cross-site features switched off (see Cookies below).
• We do not combine data across organizations. Every vendor and customer record belongs to a single organization, and each organization’s records are kept separate.
• We do not use personal data to train machine learning models. The Platform’s AI-assisted features process only the text an organization’s staff types into them.

Email

The Platform sends account and service email:

• To staff and vendors: verification, password reset, and invitation email; document-expiry reminders; compliance notices and operational announcements an organization sends to its vendors; platform service announcements.
• To guests: booking confirmations and reminders, waitlist notifications, and a post-visit feedback request.

We do not send third-party marketing. You can opt out of non-essential email — platform service announcements, an organization’s operational announcements to its vendors, and the post-visit feedback request sent to guests — at any time. Signed-in users can turn it off under Account settings → Email preferences, and every non-essential email includes an unsubscribe link, so guests can opt out even though they have no account. Essential email is always sent: verification, password reset, and invitations; booking confirmations, reminders, and waitlist notifications; document-expiry and compliance notices; and payment messages. You can also contact [email protected]. We do not send SMS.

Automated decisions

The Platform makes no automated decisions that produce legal or similarly significant effects.

Where data is stored

On Cloudflare’s global network (Workers, D1, KV, and R2). Data may be processed at Cloudflare data centers worldwide.

Sub-processors

We will give organizations notice before adding a sub-processor. The Platform contains an integration with a customer-intelligence system operated by Ecropolis; it is not currently enabled, and we will update this page before enabling it.

Security

Traffic is encrypted in transit, data is encrypted at rest by Cloudflare, passwords are stored as salted hashes, and every organization-owned record is scoped to that organization. Our Security Overview describes our measures in detail, including what we do not yet claim.

Retention

• Staff, vendor, and customer records are retained for the life of the organization’s account.
• Operational records are moved out of the live database to cold storage on a schedule: audit events after 400 days, notification records after 180 days, resolved payment-reconciliation records after 90 days.
• Abandoned draft bookings are deleted after 7 days.
• Financial records (invoices, payments) are retained for approximately 7 years for tax purposes.
• When an organization closes its account, we delete its data on written request, except records we are legally required to keep.
• Deleted records, including a disconnected calendar’s tokens and busy times, can still be restored from our database provider’s point-in-time recovery for up to 30 days after deletion.

Your rights

If you are a vendor, customer, or guest of an organization that uses VendorStreet, that organization is the controller of your data — please direct access, correction, or deletion requests to it. We assist organizations in responding to such requests; requests we receive directly are referred to the organization concerned, and we act on verified requests the organization passes to us.

For data we control (organization accounts and staff logins), contact [email protected].

Cookies

This website uses Google Analytics (via Google Tag Manager) to measure traffic. Which rules apply depends on where you appear to be. If you appear to be in the EEA, the UK or Switzerland, nothing is requested from Google and no analytics cookies are set until you accept via the cookie banner — decline, or simply ignore it, and no Google script loads at all. Everywhere else, analytics start on your first page view and the banner invites you to opt out; if you decline we stop analytics, switch Google Analytics off for this site, and delete the analytics cookies already set, so only that first page view was ever counted. We work out which applies from your browser's own time-zone setting — a rough guess that a VPN or a trip abroad will fool. We deliberately do not use the Geolocation API (which would prompt you) or an IP address lookup, and an unreadable time zone falls back to the stricter, consent-first rules. You can change your choice at any time using the Cookie settings link in the footer. We do not use advertising or cross-site tracking cookies.

The Platform (app.vendorstreet.app) sets a session cookie (HttpOnly, Secure) to keep you signed in, and a temporary cookie holding your email address during signup verification. Sign-in and registration forms use Cloudflare Turnstile for bot protection, which processes your IP address.

The Platform also uses PostHog for product analytics. It records the pages you visit, the controls you use, errors in your browser, and technical details such as browser type, screen size and an approximate location derived from your IP address; if you are signed in, this is associated with your account and organization. To diagnose problems it may record how a page was used (a session replay), with anything typed into a form masked first. Payment card details are entered on Stripe’s pages and are never captured. PostHog sets first-party cookies and uses your browser’s storage so that repeat visits are counted once. We do not sell this information or use it for advertising.

Changes

We will post changes here and update the date above. Material changes will be notified to organizations.

Contact

[email protected] — 8001 Valcasi Dr. Ste 101, Arlington, TX 76001, USA

---

Related: Security Overview · Data Processing Addendum