> 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/publishing-and-sharing.md).

# Publishing and sharing

Once your event is set up and ready for vendors, it's time to publish it. Publishing makes your event visible to the outside world and opens the door for vendors to apply or register.

***

## Event Statuses

Every event in Vendor Space has one of three statuses:

### Draft

Your event starts in **Draft** status. While in draft:

* The event is only visible to you and your team inside Vendor Space
* No public event page exists
* Vendors cannot apply or register
* You can freely make changes without anything going live

This is where you set up your products, booths, forms, and settings before going public.

### Published

When you publish an event, it becomes live:

* A **public event page** is created and accessible via a shareable link
* The event page displays your event details, booth types, pricing, and vendor categories
* Vendors can access the application or registration form (if you've linked one)
* Payment links become active

### Archived

Once your event is over, you can archive it:

* No new vendor registrations or applications are accepted
* All existing data is preserved for your records
* The event moves out of your active event list to reduce clutter

See [Duplicating and archiving](/docs/events/duplicating-and-archiving.md) for more on how archiving works.

***

## How to Publish an Event

1. Open the event you want to publish
2. Make sure you've set up the essentials:
   * At least one product (booth type) with pricing
   * Event settings configured (categories, approval mode, etc.)
   * A form linked to the event (if you want to collect applications)
3. Click the **Publish** button

Your event is now live and ready to share.

> **Tip:** Double-check your event details, pricing, and refund policy before publishing. While you can make changes after publishing, it's best to have everything in order before vendors start seeing your event page.

***

## Sharing Your Event

Once your event is published, you can share it with vendors in several ways:

* **Copy the public event link** and share it via email, social media, or your website
* **Send payment links** directly to vendors you've already been in contact with
* **Embed your vendor form** on your own website to capture applications (see [Embedding on your website](/docs/forms/embedding-on-your-website.md))

> **Tip:** Add your public event link to your social media profiles, event listing sites, and email newsletters to reach the widest possible audience of potential vendors.

***

## Making Changes After Publishing

Publishing doesn't lock you out of making edits. You can still:

* Update event details like the description, dates, and location
* Add or modify products and pricing
* Adjust event settings like vendor categories and caps
* Edit your linked forms

Changes take effect immediately on your public event page.

> **Tip:** If you need to make a major change (like adjusting booth pricing), consider reaching out to any vendors who have already registered to let them know. A quick message goes a long way in keeping your vendor relationships strong.


---

# 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/publishing-and-sharing.md?ask=<question>&goal=<endgoal>
```

`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.