What control and integration surfaces are already in HETable?

HETable already includes API keys, webhooks, permissions, audit logging, security policies, reporting, and multi-location controls alongside the live front-of-house workflow.

Why does the engineering page matter for go-live?

An engineering-facing page helps technical reviewers understand the real product boundary, the route surfaces already in the app, and the integration and security controls that should be reviewed before launch.

HETable engineering overview

Technical scope, controls, and launch-readiness for engineering reviewers

This page gives a technical reviewer the fastest accurate picture of what HETable is, what it already includes in the app today, and which control surfaces matter most before go-live. It is built to support engineering, implementation, and parent-site product-page reviews without inflating claims beyond the actual codebase.

Review integrations and security Open the go-live checklist

Product boundary

What HETable isThe HospiEdge front-of-house table-management and guest-flow product: floor plans, host workflows, reservations, waitlist, optional self-seat and kiosk paths, staffing alignment, reporting, and admin controls.

What HETable is notDo not market it as payroll, payment processing, or POS software unless those capabilities are actually added to this repo later.

Why this boundary mattersIt keeps product, engineering, SEO, and buyer messaging aligned with the real route surface already present in the app.

Real app surfaces already in the product

Floor Plan Builder + VersionsCreate layouts, save drafts, review versions, and publish the live room.

Host Stand + Reservations ManagerRun live arrivals, table-state decisions, reservation edits, and floor execution.

Waitlist + Wait BoardTrack queue pressure, quoted waits, recent seatings, and live wait conditions.

Public booking + confirmationSupport guest booking plus reservation confirmation or cancellation flow.

Self-seat + Guest KioskOffer guest-led arrival workflows where the restaurant enables them.

Sections + Smart Assign + Station AssignmentsAlign floor coverage before service and publish station-ready outputs.

Pocket View + ReportsSupport floor-team follow-through and post-shift review.

Locations + Admin controlsSupport group oversight, governance, and workflow controls around the service layer.

Integration and control surfaces

API keys: scoped access around floor data, staffing, reports, ratings, and admin workflows.
Webhooks: event handoff for staffing, ratings, assignments, and table-status workflows.
Permissions + overrides: role and user-level control for sensitive actions.
Audit log: activity review around settings and admin workflows.
Security policies: idle timeout, IP allowlist, and brute-force lockout settings.
Multi-location controls: locations dashboard and related oversight flows.

API keys Webhooks Permissions Audit log Security policies Locations dashboard

How the technical review should think about the workflow

Manager layerRoom setup, booking rules, assignments, reporting, permissions, audit, security, and location-level oversight.

Host layerLive seating, reservation control, waitlist pacing, and arrival management against the current room.

Floor-team layerStation assignments and Pocket View for execution after the host decision is made.

Guest-facing layerBooking, confirmation, self-seat, kiosk, and concierge flows only where the restaurant chooses to expose them.

Engineering review should focus on whether those layers stay aligned, whether role boundaries are clear, and whether the public product story stays inside that real boundary.

Go-live technical review checklist

Confirm the published room and the host-facing workflow are aligned.
Confirm role access around manager, host, floor-team, and guest-facing paths.
Review permissions, audit, API keys, webhooks, and security-policy settings before launch.
Confirm public buyer pages do not overclaim unsupported payroll, payment, or POS capabilities.
Use the go-live checklist and workflow pages as the operational reference for rollout.

Direct answers

What should an engineering page say about HETable?

It should describe HETable as the HospiEdge table-management and guest-flow product, then explain the real app surfaces already present: floor plans, host workflows, reservations, waitlist, optional guest-led arrival paths, staffing alignment, reporting, and admin controls.

What should technical reviewers look at before launch?

They should review the role boundaries, guest-facing paths, permissions, audit visibility, API keys, webhooks, security policies, and location-level controls that surround the live service workflow.

Why is a public engineering page useful?

It helps technical buyers, implementation partners, and internal teams evaluate the real product boundary and control surface without relying only on broad marketing language.

Integrations and securitySee the buyer-facing control story that surrounds the workflow. What teams open in HETableSee the real screen-level surfaces behind the engineering summary. HETable go-live checklistWalk the final launch checks before the first live shift. HETable featuresUse the public feature overview as the buyer-facing companion to the engineering page.