Changelog

What changed in the API, its webhooks, its scanner endpoints and the apps built on it. Newest first.

Taken straight from the product's own changelog, so a release cannot ship a change this page does not mention. Everything that does not touch an integration is left out — that is on entrywick.com. This server runs d919fddd8fc9.

What counts as a breaking change

• A field or an operation is never removed from v1, and an existing field never changes meaning.
• New fields appear without notice: read what you need and ignore the rest.
• A new refusal code can appear in an existing response. Handle an unknown error.code as a refusal you do not recognise rather than as a success.
• Webhook payloads grow the same way. Verify the signature over the body exactly as it arrived, whatever is in it.

Unreleased · Phase 5

• api

  an event that announces an opening time can raise its own rate limits — the four limits on the surfaces with no account behind them (registration, public POST, public GET, the public page) were numbers in the source and could not be changed without a deploy. They are configuration now (entrywick.public, each with an EW_PUBLIC_* variable), read per request, with today's values as the defaults so nothing changes unless somebody sets one. The reason is not the load test it unblocks: an address is a poor identity for a public form. A family at home shares one, everybody on a venue's Wi-Fi shares one, and a mobile carrier can put thousands of phones behind one — so 20 registrations a minute per address turns real registrants away on any event whose link goes live at an announced time, and the 429 they get says nothing an organizer could act on. A limit can be raised and never configured away: every one is floored at one a minute where it is built and again where it is read, so no value turns a public endpoint into an open one, and a variable left blank or set to zero means the default rather than one a minute — a number somebody emptied should not quietly become an outage.

• integrations

  Constant Contact connects — the sign-in now asks for account_read too, so the account check after connecting is no longer refused with 403 insufficient.authorization.scopes; press Connect again to grant it.

• integrations

  the Zapier fields read like the product — the registration triggers now label their output with the glossary's own words (Attendee, Event, Registration) instead of Zapier's auto-derived "Attendees First Name", and expose an Attendee full name field (the first attendee, plus a full name on each person in the list) so a Zap never has to join first and last itself.

• integrations

  a registration webhook that reads on its own — the New Registration trigger (Zapier and Make) and the registration resource now carry the event's name, start and timezone, and a short registration reference (the same string the attendee sees on their manage page), so a Zap or scenario can name the event and quote the reference without a second lookup. Zapier app bumped to 1.0.2.

• scanner

  on a phone the camera comes first — under the event name and one line naming the check-in point

• scanner

  no more stray focus timer after the scan screen closes — the laptop's hand-back-the-focus timer in ScanPanel.vue is now tracked and cleared on unmount, which ended an intermittent red "Scanner unit tests" step in CI (document is not defined after the test page was torn down).

Unreleased · Phase 3

• api

  the developer portal answers more of the questions people actually arrive with — a Sandbox page that shows what is in the sandbox right now (the event's own id, its day, type and check-in point codes, a real ticket, and a curl with every value already filled in, so the first call works before you have read anything); a Changelog of everything that changed in the API, its webhooks and its scanner endpoints, taken straight from the product's own changelog so a release cannot ship a change the portal does not mention, and saying plainly what counts as a breaking change; a Status page saying whether the API, its background work, its certificates and its backups are healthy; search across every operation and every page, by path, by scope, by entitlement or by word; and the scanner conformance cases as a download — the same file our own tests and our own scanner are held to, so you can run your hardware through exactly what EntryWick decides. Every page now shares one layout with the search box on it.

• event templates

  an import can no longer fail because an event template forgot to declare an entitlement — the importer asked the document which features the organization had, and treated anything the document did not mention as allowed. A document with reminder emails that did not list configurable reminders therefore failed outright on a plan without them, instead of importing them switched off. Reminders and form logic now ask the plan itself, which is what the rule always said: an import never fails on a plan limit.

• event templates

  the five other event templates are finished — School Field Trip, Volunteer Day, Conference, Sports Tournament and Corporate Offsite arrive as whole events rather than skeletons. Each one now carries the forms its vertical actually needs (a guardian's permission slip and medical answers; a waiver a parent agrees to for an under-18 volunteer; dietary, access and invoice questions; a team roster with a date of birth per player), an example group tree, a public page with a hero line, what to bring and an FAQ written for that audience, confirmation, ticket, reminder and thank-you emails plus a ticket page, badge and print sheet in that vertical's voice, a schedule that runs from sign-up to the week after, and the checklists somebody reads at 7 AM — pre-event by day, gate training, and notes for whoever runs one class, team, shift or track. Anything your plan does not cover still imports switched off with the reason. The import wizard now offers one row per event template rather than one per version.

• api

  Add a person to an existing registration — POST /v1/events/{event_id}/registrations/{id}/attendees places them as the event's form would (rules, capacity, the plan's cap) and, on a confirmed registration, issues their tickets at once; a full day refuses rather than sending the family back to a waitlist. Zapier gains Add Attendee and Make gains Add an Attendee (Scale).

• integrations

  the email list sync engine — each organization's list is fed at the pace its provider allows, so a nightly run over thousands of households never trips a rate limit; a contact that fails is tried five times over about an hour and a half with the provider's own reason shown against their address meanwhile; a revoked connection stops at once and the owners are told once, not once per contact. Every night bounces are pulled back from Constant Contact and every household that changed is sent; Sync now does the same on demand. Tokens are renewed before they expire. Disconnecting keeps the record of what was sent for 30 days, so reconnecting picks up the same contacts instead of adding everybody again.

• integrations

  Settings → Email lists — connect Constant Contact or Mailchimp with a sign-in, or Brevo with an API key, and everyone who registers arrives in the organization's own list: one contact per household, keyed on its email, with everyone's names in ew_people, their tickets, group and ticket link in fields of their own, a list per event and per day, and types and check-ins as tags. What is sent is the organization's to change — rename a field, drop one, add a form answer — and nothing unlisted is sent. A household that has not changed costs no call. A hard bounce or a spam complaint the provider reports marks the contact in EntryWick too, so that person moves to the print track. Brevo can also send the organization's confirmations, tickets and reminders. A health panel shows how many contacts are in step, how many are failing and why.

• webhooks

  a delivery can be replayed for 30 days from the original delivery; replaying a copy no longer starts a new 30 days, and the admin's Replay button follows the same rule.

• webhooks

  an endpoint URL whose host is an address spelt as one number, in hexadecimal or octal, shortened or with a trailing dot (https://2130706433/, https://127.1/) is refused when it is made and before every delivery, as a private address already was. The webhook signature test vectors are published in WEBHOOKS.md §4 and on the developer page, and §4's reference verifier now accepts either secret during a rotation.

• api

  POST /v1/events/{event_id}/imports takes send_ticket_emails (boolean, default false), the same switch as imports.send_ticket_emails: the people an import adds always get tickets, and their confirmation and ticket emails go out only when it is set. The Zapier and Make apps install from their own lockfiles in CI.

• integrations

  EntryWick for Make (integrations/make, a Make Apps Editor project) — Watch Events for any of the 19 webhook types (optionally one event), Search Registrations, and Create a Registration, Issue a Ticket and Record a Check-in, all on API v1 with X-EntryWick-Client: make; the same plan messages as Zapier; its files are checked offline in CI against the spec. Publishing waits for the owner's Make account.

• integrations

  EntryWick for Zapier (integrations/zapier) — triggers New Registration, Registration Confirmed, Registration Cancelled, Ticket Issued, New Check-in and Payment Received as REST hooks on webhook endpoints (signature checked), Find Registration, and the actions Create Registration, Issue Ticket and Record Check-in, all on API v1; the apps name themselves with X-EntryWick-Client, which needs zapier (Growth: "Zapier and Make need the Growth plan or higher.") and is recorded as audit_logs.client; on Growth the actions say "This action needs the Scale plan"; tested offline in CI. Submission waits for the owner's Zapier account.

• webhooks

  Organization → Webhooks and /v1/webhooks* — make an endpoint (https, public addresses only; its signing secret shown once), filter it to an event or a part of the organization, change, test, rotate, pause, enable and delete it, and see each delivery's envelope, signature and answer with replay for 30 days; managing webhooks needs webhooks (Growth), not api_write; a key or member limited to a group stays inside it; a plan that loses webhooks pauses every endpoint, and getting it back enables exactly those.

• webhooks

  deliveries are sent — only to https endpoints whose every address is public, checked on each attempt and pinned for the connection; signed EntryWick-Signature: t=,v1= (both secrets for 24 h after a rotation; published vectors); retried after 1m/5m/30m/2h/12h/24h/24h/24h and then dead; 50 failures in a row make an endpoint failing and email its owners, 7 days pause it; replay keeps the envelope id for 30 days; test events go out once with livemode: false.

• webhooks

  all 19 documented events are raised by the services that do the thing and become webhook_deliveries after the commit — one envelope id per occurrence, data in API v1's own shapes (payments gained a ULID and a Payment schema), one registration.updated per commit, endpoints filtered by subscription, event and group subtree, nothing for work that rolled back, and never at the expense of the work itself; sending is next.

• api

  contract tests generated from the spec for every operation (credential, scope, entitlement, group scope, response schema); developer docs at /developers with a Scalar reference, quick-starts and a Postman collection, backed by a nightly sandbox tenant with a published test key; CI fails when anything generated from the spec is stale.

• api

  API v1 serves every operation in the spec but the ten planned for weeks 15 and 19 — groups, events and their structure, registrations and people (registered by code through the same submission as the form), contacts, tickets, scanning with a key, communications and test sends, bulk imports, exports and event template imports as jobs, and tokenless public JSON on tenant hosts; every object has a public ULID, codes are accepted wherever an id is, and a route-to-spec parity test keeps them in step.

• api

  API v1 on its own host with API keys — api.{base}/v1 authenticates by Authorization: Bearer alone (the key names the tenant), audits as source api with the key as actor, runs a group key inside its group, holds keys to exact scopes, api_read/api_write, a per-key rate capped by the plan (X-RateLimit-*) and a monthly call quota (owners warned at 80/100/150 %, 429 past 150 % until the 1st); scanner keys count toward the same month; GET /v1/me; this month's calls on the API keys page.

Unreleased · Phase 2

• scanner

  the mode chip names the mode the device is in — "Phone camera" on a phone scanning with its camera, "Laptop" only in the laptop layout — instead of the layout a tap would switch to (scanner 1.0.5).

• scanner

  the installed scanner opens at / (was /?source=pwa); tests/brand.spec.ts holds the manifest to the brand — "EntryWick Scanner", brand-kit icons including maskable and the apple-touch-icon, token colours, standalone, scope / — and keeps customer names and "CRM" out of the scanner's source, manifest and build.

• event templates

  the import wizard knows your groups — "Your groups" starts with each event template group matched to your group with the same code, and reused groups are one note with a count instead of one note each.

• scanner

  "Type or scan a code" where the check-in point takes typed codes or search — a laptop says so instead of "Ready — scan a ticket", and a page with no camera at such a check-in point shows no camera message (scanner 1.0.4, which also carries the dated "Not open yet").

• scanner

  works over plain http — scan ids and Idempotency-Keys fall back to a getRandomValues v4 UUID where crypto.randomUUID is missing (pairing failed with "crypto.randomUUID is not a function"), and the camera says it needs a secure connection, with the https address, instead of failing; local development runs on Herd's HTTPS (scanner 1.0.3).

• scanner

  hardware scanners at a laptop — keyboard-wedge codes are read only at scanner speed and a scanner repeating itself is dropped; ?layout=laptop (or the toggle on the home screen) drops the camera, shows the result large enough to read from a step back and keeps the page ready for Bluetooth scanners that type into whatever is focused; ?layout=kiosk is a stub until self check-in.

• api

  third-party scanners with API keys — Organization → API keys makes keys (shown once, stored as a hash) with scopes, a group, an expiry, IP ranges and a rate, and revokes them; a key with the scanner scope calls /scan, /scan/batch, /scan/manifest, /scan/roster and /checkins on the scanner host and gets exactly the envelope a paired scanner gets, with its group's roster, the key recorded as the actor, the plan's api_scanner and rate checked on every call, and no overrides; docs/product/scanner-api.md with a curl example and the golden cases as a conformance set.

• scanner

  versions and degraded modes — below min_sw_version (from the manifest or a 426) scanning stops with "Tap to reload" and the queue stays; newer versions install at a quiet moment; revoked devices try one last upload, then forget their data and lock; offline, stale-roster and camera-trouble banners.

• scanner

  offline queue and replay — queued scans persist in IndexedDB (storage persistence requested), upload through /scan/batch in scanned_at order at most 500 a call with backoff, stay on the phone when refused, and leave a corrections list wherever the server decided differently; "Waiting to upload: N" is always on screen; scans are stamped with the server-corrected clock.

• scanner

  scanning — camera (QR, Code128), hardware scanners, typed codes and roster search where the check-in point allows; a local decision mirroring ScanService (§3 steps 1–10) checked against shared golden cases in both test suites; full-screen results with icon and word, "Everyone here?" for shared tickets, and offline scans decided from the roster and queued.

• scanner

  pairing screen and manifest — the code alone pairs the phone, the token and manifest persist in IndexedDB, the manifest refreshes every 60 s with ETag/304, the operator picks a day only where none is pinned, and re-pin, revoke and a departed member each end the pairing visibly.

• scanner

  the scanner PWA scaffold in apps/scanner (Vue 3, Vite, TypeScript, Pinia, a versioned service worker that precaches the shell only), dark EntryWick brand, served by Laravel on the scanner host.

• api

  API v1's first routes — the scanner endpoints (/scan, /scan/batch, /scan/manifest, /checkins, /checkins/{id}/override, /devices/pair) with the error envelope, cursor pagination, a 24 h Idempotency-Key store and 10 scans a second per device.