> For the complete documentation index, see [llms.txt](https://vendorspace.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://vendorspace.gitbook.io/docs/events/event-settings.md). # Event settings Every event has its own set of configurable settings that let you control how vendors interact with it. These settings help you tailor the experience for each event, whether it's a small community market or a large-scale trade show. *** ## Where to Find Event Settings 1. Open the event you want to configure from the **Events** page 2. Click **Edit** to open the event form 3. Scroll to the settings sections: **Vendor Settings** and **Email Notifications** *** ## Vendor Settings ### Approval Required When turned on, vendors must submit an application and be approved by you before they can register or pay for a booth. This gives you full control over who participates in your event. When turned off, vendors can register and pay immediately without waiting for approval. > **Tip:** If you're running a curated event where vendor quality or category balance matters, turn on approval. For open-registration events where any vendor can join, you can leave it off to speed things up. ### Vendor Categories Define the types of vendors you accept at your event. Common categories include Food, Artisan, Retail, Service, and Non-Profit, but you can create whatever categories make sense for your event. Categories help you: * Organize vendors by type on your event page * Filter and sort your vendor list * Ensure a good mix of vendor types at your event > **Tip:** Keep your category list focused. Too many categories can be confusing for vendors filling out their application. You can always add more later if needed. ### Max Vendors Set a cap on the total number of vendors your event can accept. Once the limit is reached, new vendors won't be able to register. This is especially useful when you have a fixed number of booth spaces available and want to prevent overbooking. ### Refund Policy Write a refund policy that will be displayed to vendors during the checkout process. Being upfront about your refund terms helps set expectations and reduces disputes later. Your policy might cover: * Whether refunds are available and under what conditions * Deadlines for requesting a refund * Whether partial refunds are offered * How vendors should request a refund > **Tip:** Even a simple one-liner like "All sales are final" or "Refunds available up to 30 days before the event" goes a long way. Vendors appreciate knowing the terms before they pay. ### Load-in Instructions Provide setup and arrival details for accepted vendors. These instructions are shared with vendors after they've been approved and paid, so they know exactly what to expect on event day. Good load-in instructions typically include: * Setup date and time (if different from the event start) * Where to park and unload * Entrance or gate to use * Any items vendors need to bring * Contact information for day-of questions *** ## Tax If you charge tax on vendor payments, you can configure a per-event tax rate and label. When enabled, tax is calculated on the subtotal and added as a separate line item in Stripe checkout. | Field | Description | | --------------------------------- | ----------------------------------------------------------- | | **Charge tax on vendor payments** | Toggle to enable or disable tax for this event | | **Tax Rate** | The tax percentage to apply (e.g., 13 for 13%) | | **Tax Label** | A short label shown at checkout (e.g., "HST", "VAT", "GST") | New events inherit your organization's default tax rate and label from [Organization Settings](/docs/settings/organization-settings.md). You can override them here for any event. > **Tip:** If your events span multiple jurisdictions with different tax rates, set the correct rate on each event rather than relying on the organization default. *** ## Email Notifications Control which automatic emails Vendor Space sends to vendors for this event. Each toggle affects only automatic, system-triggered emails. Manual emails like reminders and re-engagement campaigns are not affected. | Toggle | What it controls | | ------------------------- | ----------------------------------------------------------- | | **Waitlist notification** | Sent when a vendor is moved to the waitlist | | **Offer email** | Sent when a vendor receives an offer with their portal link | | **Payment confirmation** | Sent after a vendor completes payment through Stripe | | **Application approved** | Sent when you approve a vendor's application | | **Application declined** | Sent when you decline a vendor's application | All emails are **enabled by default** when you create a new event. > **Tip:** If you prefer to contact vendors through your own channels, you can turn off automatic emails and share portal links manually. The underlying actions (offer creation, payment processing) still work normally -- only the email notification is suppressed. For more details on each email, see [Email Notifications](/docs/communication/email-notifications.md). *** ## When to Configure Settings You can update event settings at any time, even after your event is published and vendors have started registering. However, it's a good idea to have your core settings in place before you start accepting vendors. * **Before publishing:** Set your approval mode, categories, and vendor cap so the rules are clear from the start. * **Before sending payment links:** Make sure your refund policy is written and saved. * **Before event day:** Add or update your load-in instructions so vendors have everything they need. * **Email notifications:** Review your email preferences before you start making offers or processing applications. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://vendorspace.gitbook.io/docs/events/event-settings.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.