Skip to main content
A Sure project contains ordinary HTML, CSS, and JavaScript plus sure.json. The JSON file defines the scheduling rules and the starter frontend’s presentation. It is validated when source is saved or imported. See Projects for Git, MCP, previews, publishing, and rollback, and Booking for the public booking API.

A complete valid sure.json

This example is synthetic. Exception dates are examples, not holidays inferred by Sure. All top-level sections shown here are required; there is no implicit defaulting of missing sections.

Schema and limits

Numeric fields below must be JSON integers, not numeric strings. Strings cannot contain NUL characters. String length limits use JavaScript string length; for most text that is the character count, while some Unicode characters occupy two code units. Unknown properties do not add backend capabilities. Use the documented shape; the validated runtime configuration contains the supported fields. A custom frontend may add its own separate source files and choose how to present the supported configuration.

Scheduling semantics

Weekly windows and exception dates are interpreted in timezone, independent of the timezone a booker uses to view dates. Multiple windows can apply to the same weekday. A matching exception replaces every weekly window for that date. windows: [] closes that date; an empty weekly array offers only explicitly opened exception dates. A booking must fit entirely within one window and stay on the same configured local date. Adjacent windows are not automatically merged. Candidate starts occur every 15 minutes from each window’s start: a window beginning at 09:10 permits starts such as 09:10, 09:25, and 09:40, subject to duration, notice, conflicts, and the requested day. Duration is elapsed time in minutes. Actual instants are checked through daylight-saving transitions; do not generate slots by adding fixed UTC offsets to local strings. Use the public API’s returned start, end, and token. The API also requires the entire meeting to fit inside the day requested by the booker. Minimum notice is measured from the current instant. The booking’s start must be before the current instant plus horizonDays × 24 hours; this is a rolling horizon, not a count of local calendar-date boundaries. Buffer is a minimum gap from busy time, before or after the booking. When another Sure booking also has a buffer, the larger buffer applies, rather than adding both buffers. Buffer is a conflict rule; it does not add to the displayed meeting duration or require the buffer itself to fit inside an availability window. The backend enforces scheduling and required form answers. Theme and copy guide the starter frontend; changing JavaScript or CSS can change its appearance, but does not bypass scheduling validation. Required question answers are trimmed nonempty strings, each at most 2,000 characters; see Booking. Draft configuration changes affect previews. Public booking uses the currently published configuration. Publication or rollback can invalidate unused slot tokens from another source revision. Changing configuration does not move or cancel existing bookings.

Source file constraints

A source snapshot contains at most 100 files and 2,000,000 UTF-8 bytes in total. Each file is text, contains no NUL characters, and is at most 250,000 UTF-8 bytes. Keep nonempty index.html and sure.json at the project root. Paths are relative, at most 180 characters, begin with an ASCII letter or digit, and otherwise use ASCII letters, digits, _, ., /, or -. Empty segments, . or .. segments, hidden path segments, and directories named memory, node_modules, credentials, or secrets are not allowed. Supported extensions are .html, .css, .js, .json, .md, .svg, and .txt. Keep credentials, private calendar links, private conversation or memory files, booking records, and form answers out of the repository. Source validation rejects known credential patterns; that is not a substitute for keeping secrets out of source. The repository is frontend source, not a secret store. No package installation or build step is required for the starter. Use relative asset URLs so the same source works under a published revision or a preview URL. sure-runtime.json and sure-font.ttf are supplied by hosting at the source directory; do not create project files with those names expecting to replace the hosted responses.

Hosted URLs and runtime JSON

Use the publicUrl or previewUrl returned by the project API rather than constructing the host yourself. Current hosting uses the separate origin https://pages.sure.day. REVISION is a source revision returned by Sure, not a Git commit SHA. A preview is fixed to the source that was previewed; saving later edits does not change an already-open preview. Request a fresh preview after editing. Historical public URLs are available while that release is retained; do not assume unlimited release retention. From either directory, fetch the runtime beside your HTML:
The exact response shape is:
preview is always a boolean: false for a published release and true for a preview. This response contains no owner credentials, booking answers, management tokens, or private calendar events. config is the validated configuration, rather than a promise to preserve extra JSON properties or the original JSON formatting. Send public booking requests to runtime.appOrigin + '/booking-rpc' with runtime.projectId. A custom frontend must disable booking submissions when runtime.preview is true. The starter disables its search and booking buttons and labels the page as a preview. Preview source does not become the active booking policy: the public API always uses the currently published page, and there is no separate preview booking endpoint. Hosting serves GET and HEAD. Hosted code is isolated from the signed-in app’s origin. Its content security policy allows scripts and styles from its own origin, including inline scripts/styles; connections can go to that origin and the Sure app. Objects, child frames, workers, and native form submissions are blocked. The page may only be framed by the Sure app. Use JavaScript booking RPC, not an HTML form action to another service. Arbitrary external script, font, analytics, or payment URLs are not enabled by default. The supplied sure-font.ttf is the starter’s Manrope font. theme.fontFamily chooses fonts already available to the page or device; it does not relax hosting restrictions.

Optional private day in an owner preview

A public visitor does not receive private calendar data. The signed-in Booking pages editor can explicitly send a simplified view of the owner’s current day to an embedded preview after the owner chooses Show my day here. This is an optional UI message contract, not a public calendar-read API. First, the preview announces readiness to the containing editor:
The editor checks the preview origin, its exact iframe window, the project ID, and the current source revision before enabling the owner’s action. Readiness alone does not send calendar data. If the source revision changed, open a fresh preview. After the owner’s explicit action, the editor can send:
date is today’s date in the project’s timezone. events contains only display titles and preformatted time labels; time is not an ISO timestamp or a stable format for calculations. The payload has no event IDs, provider records, credentials, descriptions, or management capabilities. coverage is complete or incomplete; an empty list with incomplete coverage must not be described as a guaranteed free day. The starter renders at most 200 entries. Check the sender and render text safely:
Treat this payload as private, temporary display data. Do not commit it, embed it in a public page, or forward it to another service. The handshake does not grant the preview access to the app’s authenticated APIs and does not make an anonymous public page calendar-aware.