Venues, slugs & publication

A venue is the public unit of DineGlobe: it owns the floor plan, the bookable services, the booking terms and one web address. Every venue is born private (DRAFT) and becomes visible to guests only after a platform operator approves its publication. This page covers the creation fields, the rules for choosing the public address, the publication lifecycle with its four readiness blockers, and what happens when a venue is renamed, retired or deleted.

Create a venue

Open /app/venues/new (button “Add a venue” on the console home). The form creates the organization inline if you do not have one yet (see Organizations, teams & invitations).

Field	What it is	Rules/limits
Organization	Which company owns the venue.	Pick an existing one, or choose Create a new organization… and name it (1–160 characters).
Venue name	The public display name.	1–160 characters.
Public address (slug)	The venue’s web address path.	Lowercase letters and digits with single hyphens between them, 1–96 characters. See the slug rules below.
City	City shown on the public profile.	1–120 characters.
Country code	ISO 3166-1 alpha-2 country.	Exactly two letters (example: IN), uppercased for you.
Timezone (IANA)	The civil-time rules all service times follow.	A zone name the runtime’s own time zone database can resolve, e.g. Europe/Lisbon or UTC. Otherwise: “Unknown IANA time zone.”
Currency	The one currency every amount uses.	Exactly three letters, ISO 4217 (example: INR).
Primary language	The venue’s default content locale.	English, Japanese or Arabic.
Street address	Address line 1 for the profile.	1–200 characters.

On success you land on the new venue’s board. The venue is DRAFT and invisible to the public resolver. The underlying command also accepts a region, a second address line, a postal code, coordinates, extra supported locales, venue types, a public phone, a public email and an HTTPS website URL — the console asks for the core set, and the full surface is available through the Venues & slugs (DEV-009 panel) at /app/panels.

The currency is fixed for the life of the venue. Booking amounts and policies always use it, and no automatic currency conversion ever happens — choose it deliberately.

The public address (slug) rules

The slug becomes the venue’s guest-facing path: dineglobe.com/your-slug. Rules, enforced server-side on every create and rename:

• 1–96 characters of lowercase letters and digits, with single hyphens between groups (no leading, trailing or doubled hyphens). Input is trimmed and lowercased before validation.
• A fixed list of first path segments is reserved for the platform and can never be claimed by a venue: app, auth, api, my, b, about, features, capabilities, customers, contact, support, feature, customer, docs. These cover the private console roots, the guest portal /b, the API and the marketing pages.
• A slug is refused with SLUG_TAKEN (409) when any venue — yours or another’s — holds it now or held it in the past. Retired addresses keep redirecting to their venue, so they are never handed out again. The console setup form suggests a numbered alternative (for example tonyos-table-2).

Renaming (form “Rename the public address”, Venues & slugs panel) moves the venue to the new canonical address and turns the old slug into a permanent redirect (HTTP 308) that runs forever. Renaming back to one of your own historic slugs re-activates that row instead of failing.

The publication lifecycle

DRAFT ──request publication──► PENDING_REVIEW ──operator approves──► PUBLISHED
  ▲                                 (one pending review per venue)      │
  └────── operator rejects ────────────────┘        unpublish ──► UNPUBLISHED
                                                    (re-request from there)

Request publication from the Publication & SEO (DEV-011 panel) at /app/panels (button “Request publication”). The command needs the venues.manage permission. Before anything is written, the venue is checked against four readiness blockers:

Blocker code	Meaning	How to clear it
default-locale-content	The venue has no profile content in its default locale.	Add the venue’s descriptive text (in the current pilot this text is provisioned with the venue — see the limit note below).
resource	No active resource exists.	Add at least one active resource, e.g. a table — Floor plan & resources.
service	No active offering carries an active weekly window.	Configure an offering and publish its weekly set — Offerings & schedules.
policy	A bookable offering has no active accepted-terms policy.	Publish a policy version for every bookable offering — Booking policies & cancellation.

• A blocked request writes nothing: no review row is created, the venue stays private, and the panel lists the exact missing items. The panel’s copy maps the codes, e.g. default-locale-content → “Add profile content in the venue’s default locale.” and resource → “Add at least one active resource (e.g. a table).”
• A ready request opens a PENDING review (only one can exist per venue) and moves the venue to PENDING_REVIEW — still private.
• Approval is a platform-operator act and is never self-awarded: approving publishes the venue, rejecting returns it to DRAFT. Deciding a review that was already decided answers PUBLICATION_NOT_PENDING (409). Requesting publication while already PUBLISHED is refused with RULE_VIOLATION (422).

What the public sees once published

• Only PUBLISHED venues exist publicly. Drafts, pending-review, unpublished and deleted venues all answer a plain 404 — an unknown slug and a private venue are indistinguishable, so the existence of an unpublished venue is never revealed.
• Historic slugs 308-redirect permanently to the canonical address, and the sitemap lists the canonical slug of every published venue.
• The “Book a table” button appears on the public profile only when the venue has an active offering; a published venue without one shows an honest “online booking is not available yet” screen instead of a dead button.

Known pilot limit: there is no in-product editor yet for the venue’s descriptive profile text, so that text is provisioned with the venue rather than typed by the owner. Plan your default-locale description with your platform operator when you request publication.

Retirement, unpublish and deletion

• An unpublished venue is invisible publicly but keeps its configuration; requesting publication again moves it back to PENDING_REVIEW.
• There is no self-service delete. Venue records are soft-deleted by the platform operator when a business leaves; after that the venue, its profile, its slugs and its sitemap entry stop existing publicly (404 everywhere), while the database record is retained for audit and privacy obligations.
• Retired slugs stay bound to the venue they served forever — they can neither be reused by another venue nor freed by deleting the venue.