Versioning & changelog

Evident changes. This page tells you how to know when it has, and what you can rely on not changing without warning.

The three version numbers you will see

They are unrelated, and mixing them up is the fastest way to misread a release note.

Where you see it	Example	What it means
API path	https://api.evidentugc.com/api/v1/...	The API contract version. This is the one your integration depends on.
API reference	Evident API 1.0 at the top of the generated reference	The version of the reference document, which tracks the v1 contract.
Product footer	Evident Platform v0.2	The application build, shown in the admin app. Changes most weeks. Has no bearing on your integration.

If you are writing code, v1 is the only one that matters to you. The product build number moving does not mean anything in your integration changed.

What v1 guarantees

While an endpoint is part of v1, we will not:

• remove it,
• remove a field from its response,
• rename a field in a request or a response,
• change a field’s type,
• make an optional request field required,
• narrow the set of values a field accepts,
• or change the meaning of a status code it already returns.

We may do any of the following without notice and without a version change:

• add an endpoint,
• add an optional request field,
• add a field to a response,
• add a value to a set you should already be treating as open — webhook event names, error code values, status strings.

So: write clients that ignore fields they do not recognise, and that do not throw on a value they have not seen before. Outbound webhooks already says this for event names, and the same rule holds across the whole API.

What happens when something has to change

Breaking changes are not made to v1. Where a behaviour genuinely has to change, we add the new shape alongside the old one and deprecate the old one on the schedule below. There is no v2 planned, and no dated-version header to pin.

This is a deliberately narrow promise, and we would rather publish one we can hold to than a broader one we cannot. It has one consequence worth naming: some things we might otherwise fix cleanly will instead grow a second, better-named field beside the first. PUT /products replacing rather than merging is the kind of behaviour that would get a new endpoint rather than a changed one.

Deprecation

When an endpoint, field or event is deprecated:

1. It is announced in the changelog below, marked Deprecated, with the date it stops working.
2. You get at least 90 days between that announcement and the removal.
3. Responses carry RFC 8594 headers, so your monitoring catches it whether or not anyone reads this page:

Deprecation: Sun, 01 Nov 2026 00:00:00 GMT
Sunset: Mon, 01 Feb 2027 00:00:00 GMT
Link: <https://evidentugc.com/docs/versioning/>; rel="deprecation"

4. If we can see from your activity log that you are still calling it, we contact the organization owner directly rather than letting the date arrive.

The 90 days in point 2 is enforced in our own codebase, not just written here: the decorator that stamps those headers fails the build if the window between announcement and removal is shorter.

Nothing is deprecated today. Points 1–4 describe what will happen the first time something is, and the mechanism is already in place so that the policy is not an intention.

Breaking changes without notice

Only for security. If a change is needed to close a vulnerability or stop abuse, it ships immediately and appears in the changelog afterwards with a note saying why the notice period did not apply. This is rare, and we would rather tell you it is possible than surprise you with it.

A recent example of the shape, though it broke nothing: when we found that listing your webhooks returned each one’s signing secret, we stopped returning it the same day. Secrets are now shown once, when the webhook is created.

---

What changed

Newest first. Entries describe what changed for you, not what changed in the code.

Entries from October 2026 were written as the changes shipped. Everything before that was reconstructed from the repository history when this page was created — it is accurate about what changed, and may be incomplete.

October 2026

Added

• Outbound webhooks are signed with a timestamp. A new x-evident-signature-v2 header carries t=<unix>,v1=<hex>, where the digest covers `${t}.${rawBody}`. Verifying it with a tolerance — ours is 300 seconds — means a delivery someone captured stops working instead of verifying forever. See Outbound webhooks.
• The Reviews screen shows who left each review — email address and a link to their order — and the Orders screen shows when a review has been left, linking to it. Reviewer email addresses are shown in the admin app only; API keys, the MCP server and Zapier continue to receive the masked authorEmailLast4 instead.
• Reviews can be filtered to a single order with GET /reviews?orderId=.
• API keys can be scoped to particular resources when you create them, rather than only to a role.

Changed

• A VIEWER API key is now refused on every write, with a role_read_only error naming the reason, instead of being allowed through on endpoints that did not check. The Create API key dialog no longer offers a write option for that role. No VIEWER key had ever performed a write, so no integration changes behaviour.
• Listing your outbound webhooks no longer returns each one’s signing secret. The secret is shown once, when the webhook is created. Rotate by registering a second webhook and retiring the first — see Outbound webhooks.

Deprecated

• x-evident-signature, the body-only webhook signature. It stops being sent on 15 January 2027 — 101 days’ notice, against the 90 this page promises. It offers no replay protection, which is why x-evident-signature-v2 replaces it. Both headers are sent on every delivery until that date; migrating is a change to which header you hash against and nothing else. No webhook subscription existed in production when this was announced, so nothing is known to be affected.

Fixed

• Saving or approving a review no longer appeared to remove the product it was about. The review was never changed; the response omitted the product, and the screen believed it.
• An expired admin session now returns you to sign-in instead of showing “Failed to load”.
• The documentation now carries a last-updated date on every page, and the sitemap a lastmod for every URL.

September 2026

Added

• Agent access. The Evident MCP server is live at mcp.evidentugc.com and listed in Anthropic’s directory, so Claude and other MCP clients can read and moderate your evidence. It covers reviews, bulk moderation, galleries, loyalty accounts and redemptions, FAQs, orders, products and feature flags.
• Zapier. Connect with OAuth instead of pasting an API key. See Zapier.
• Excluding products from review requests, with a reason recorded on every skipped send rather than a silent omission. See Excluding products.
• Review request state on the order — scheduled, sent, failed or skipped, with the reason.
• An activity log and a security audit log, under Settings. See Activity & audit log.
• Per-store billing. An organization with several stores holds a subscription per store, and each store is gated by its own.
• Sign in from inside the BigCommerce control panel, and a Shopify embedded app with the three compliance webhooks Shopify requires.
• This documentation site — 27 pages across 8 sections, replacing a five-page structure.

Changed

• API key scopes are enforced. A key with scopes is refused outside them. A key with no scopes is unrestricted, as before. GET /account/stores stays reachable by any key so a scoped key can still find its store. See API keys & scopes.
• Rate limits are counted per caller, not per IP. A request authenticated with an evnt_ key gets its own budget, so one integration can no longer exhaust another’s. Previously every request through Cloudflare counted against a single shared bucket.
• Membership and role are re-validated on every request, so a removed teammate loses access immediately instead of when their session expires.
• Review requests use one review form for both the emailed link and the storefront widget, so they cannot drift apart.
• Klaviyo review-request templates are created as block-editor templates branded from your email branding, so they are editable in Klaviyo.
• /health now probes the database and answers 503 when it is unreachable, instead of reporting healthy.

Fixed

• GET filters that take a boolean read false as true, so ?verified=false returned verified records.
• A storefront serving both www. and the apex domain had one of the two refused by the CORS check.
• Team invitations failed silently for some owners and admins.
• Manual loyalty point adjustments were applied but not recorded in the member’s ledger.
• Replying to a review never emailed the reviewer; the screen now says so rather than implying it did.
• Two nightly loyalty jobs had been unable to write for two weeks.

August 2026

Added

• Loyalty points are derived from orders rather than written at the time of the order, so a refund, a cancellation or a corrected total is reflected without a manual adjustment.
• Points expiry, with a start date — so switching it on does not wipe every dormant balance overnight. See Setting up loyalty.
• Gallery carousels, with per-gallery control of columns, arrows and dots.
• A single-click BigCommerce app install for existing merchants.
• Nightly order reconciliation and dead-webhook detection — a store whose webhooks stopped arriving is now noticed rather than quietly falling behind.
• Filtering the moderation queue by star rating.

Changed

• Order totals are stored, so points stop over-awarding on discounted orders.
• A blocked plan now explains which plan is needed and where to change it, instead of a bare refusal.
• The affiliate commission is capped at $500 per referral.

Fixed

• Reinstalling a disconnected BigCommerce store created a duplicate store instead of reconnecting the original.
• Imported loyalty balances overwrote, rather than added to, the balances of the largest existing members.
• The Smile importer reported success while importing nobody.
• Orders created from a platform webhook did not store the customer’s email, so they never received a review request.
• Two loyalty settings — the review cooldown and referral codes — were configurable but had no effect.

July 2026

Added

• Direct billing, on three plans: Starter $49, Growth $99, Scale $299, with a 7-day trial. Plans can be changed or cancelled in place, and an expired or past-due subscription says so. See Billing & plans.
• Self-serve signup — a trial no longer needs a demo call.
• Klaviyo as an email provider, connected over OAuth, with a starter flow and template created on connect. See Klaviyo.
• Omnisend event wiring, at parity with Klaviyo’s event set.
• Agency accounts, with agency checkout at a 20% discount and affiliate commissions.

Changed

• Product URLs are stored and synced from platform webhooks, so a shopper who submits a review is returned to the product page they came from.

June 2026

Added

• Shopify as a platform, connected over OAuth, with webhooks, widget injection and catalog/order sync on connect. See Shopify.
• Loyalty birthday and referral rewards fire events to your email provider.
• Platform pages on the marketing site covering install, performance and pricing per platform.

Fixed

• Review sort order put imported reviews in the wrong place: a Yotpo import stores the original review date, and sorting used the import date. Newest and oldest now sort on the date the review was written.
• Admins, not only owners, can edit team roles.

---

Keeping this page true

This section is for whoever maintains Evident, and it is published rather than kept internally because the mechanism is the part worth committing to in public.

Changelog entries are written in the pull request that makes the change, not at the end of the month. A change to an API response, a webhook payload, a documented limit, or a label this documentation names does not merge without one. Anything that depends on someone writing up the month in arrears is abandoned by the second month.

Entries are grouped by month, newest first, under Added, Changed, Fixed and Deprecated. One sentence each, in terms a merchant would recognise, linking to the page that documents it. A breaking change is marked as such, in bold, with the date it takes effect.

Last-updated dates are derived from git, never written by hand. Every page in this documentation shows one, generated by scripts/doc-dates.mjs and checked in CI: a page whose source changed without its date changing fails the build. A hand-maintained date goes stale and then actively lies, and a reader who sees “Updated last week” on a page untouched since June has been given false confidence. The sitemap’s lastmod reads the same source, so the two cannot disagree.

Related

• Using the API — conventions that hold across every endpoint
• API keys & scopes — key lifecycle, roles, scopes and expiry
• Outbound webhooks — the event catalogue, explicitly open to additions