Event Tech CLI

@go-labs-sg/event-tech provides the event-tech and et commands for working with Event Tech through its permission-aware API.

Runtime and installation

The CLI requires Bun 1.4.0 or newer. npm distributes the package, while the installed command runs under Bun.

Check whether a compatible Bun version is already available:

bun --version

If Bun is missing, install it for the current operating system:

macOS (Homebrew)

brew install oven-sh/bun/bun

Windows (PowerShell)

powershell -c "irm bun.sh/install.ps1|iex"

Linux

curl -fsSL https://bun.com/install | bash

If Bun is installed but older than 1.4.0, run bun upgrade. Open a new terminal if the installer changes PATH, then verify bun --version again. Installation agents should skip the platform installer when Bun 1.4.0 or newer is already available.

Install and verify the CLI:

bun add --global @go-labs-sg/event-tech
et version

Authentication

et auth login
et auth status
et auth whoami

et auth login opens Event Tech in the system browser. Use the normal Event Tech Google-backed web login if needed, verify the displayed code and device, then click Authorize CLI. An existing browser session skips another Google login but never skips explicit CLI approval.

The terminal polls automatically and stores only Event Tech-issued credentials through Bun.secrets. It does not store Google credentials and has no API-key or environment-variable authentication fallback. Use et auth logout to revoke the remote session and remove its local credential. For SSH and containers, pass --no-browser and open the printed URL elsewhere.

Use EVENT_TECH_API_URL or --api-url to target another HTTPS deployment. Plain HTTP is allowed only for localhost development.

Commands

et --help
et organization list
et organization get --organization-id <id>
et event list --organization-id <id>
et event get --event-id <id>
et event appearance get --event-id <id>
et event appearance get --event-id <id> --public
et event appearance update --event-id <id> --appearance-version <n> --appearance '<json>'
et event appearance reset --event-id <id> --appearance-version <n>
et event appearance upload --event-id <id> --file ./background.mp4 --media-type video --content-type video/mp4
et event photo-wall display-items --event-id <id> --limit 30

Commands emit deterministic JSON envelopes. Authentication credentials are never included in successful output, and bearer credentials are redacted from errors.

Event appearance and Photo Wall display

event appearance get returns the canonical appearance, its optimistic-lock version, and resolved media URLs. It uses the authenticated event procedure by default. Add --public for the same safe projection through the unauthenticated public procedure; that read does not access the credential store or require CLI login. Pass the authenticated result's version back unchanged when saving:

et event appearance update \
  --event-id <id> \
  --appearance-version 3 \
  --appearance '{"version":1,"theme":{"accentColor":"#f84404","backgroundColor":"#f6f7f9","textColor":"#20242a","fontFamily":"SYSTEM"},"guestBackground":{"type":"none","key":null},"displayBackground":{"type":"none","key":null},"photoWall":{"durationSeconds":18,"maxVisible":4,"motion":"gentle","showQrCode":true,"showEventName":true}}'

Reset is an explicit, version-fenced null update:

et event appearance reset --event-id <id> --appearance-version 3

Upload appearance media before referencing its returned key in the appearance JSON. The CLI requests the existing signed attachment URL with the event scope and uploads with the declared content type. The server-bound expected size is carried in the SDK-signed URL as x-amz-meta-event-appearance-size; the CLI and browser use that URL unchanged and do not add duplicate metadata headers. Before saving a new key, the API checks the event namespace and the actual object size/content type, including its expected-size metadata.

The contract is covered by offline tests using the real AWS SDK presigner and shared object validator, with only storage HEAD responses modelled. This is not live AWS verification. See the AWS presigner documentation for the distinction between signed query parameters and required upload headers.

Example:

et event appearance upload --event-id <id> --file ./background.jpg \
  --media-type image --content-type image/jpeg

Display pages are approved-only and newest-first. The cursor is JSON with an ISO date string; the CLI decodes createdAt to a real Date before calling the API. Retained IDs are sent separately so currently visible items can be revalidated:

et event photo-wall display-items --event-id <id> --limit 30 \
  --cursor '{"createdAt":"2026-01-03T00:00:00.000Z","id":"photo-123"}' \
  --retained-ids '["photo-121","photo-122"]'

--limit is 1–60, --retained-ids accepts at most 100 non-empty strings, and the success data preserves the API's items, nextCursor, and retainedItems fields.

Lucky draw pre-draw

et lucky-draw pre-draw --event-id <id> --prize-count 5

This immediately assigns winners to the next five unassigned prizes in their configured order. It calls the same backend pre-draw operation as the web UI, using the live draw's random function and participant email/domain filters. Previous winners are excluded, each participant can win only once per batch, and the entire batch is saved in one transaction. Too few eligible participants or unassigned prizes causes the request to fail.

--prize-count is required and must be a positive integer. The success envelope contains data.drawnCount and data.winners, including each winner's participant ID, name, lucky draw ID, and assigned prize. The command requires an authenticated CLI session with access to the event and a deployment that includes the pre-draw API.