Testers reference

Config

Using Testers is the same ground with the calls around it. Refusals carry an ordinary error code.

testers({
  baseUrl: "https://api.example.com",
  cohortDefaults: {
    targetSize: 12,
    windowDays: 14,
    maxRosterSize: 100,
  },
  nudges: { cooldownHours: 72 },
  optInLinkTtlDays: 30,
})

basePath defaults to /testers.

Every constant behind the forecast is a config field, including the survival priors and the health weights. They are numbers somebody chose, not values fitted to data, and the API says so in a calibration field. Change them and bump modelVersion, so a trend chart annotates where the change took effect.

Roster states

Activity states

Nudge kinds

confirm · store · inactive · closing

All four carry an opt-out link.

Routes

Opting out answers both verbs because a one-click unsubscribe header sends a POST and a person clicking the link sends a GET. Refusing either would refuse somebody trying to leave.

Removal is a POST with a body, not a path parameter — an address in a path is an address in every access log, proxy and trace between the client and the Worker.

Scopes

testers:roster:read · testers:roster:write · testers:nudge:send

Error codes

Which fields are estimates

Why the count is an estimate is the reasoning; what the store APIs withhold is why it has to be.

Every one named estimated. Plus:

Days are counted in UTC, and the response says so.

resetPolicy defaults to reset — deliberately pessimistic, because being told day fourteen while actually on day three is the expensive mistake.

What provisioning creates

One Worker, hosting the daily pass, bound as TESTERS_DAILY. No bucket, no index, no secret.

The store’s own limits

The roster cap of 100 is a management judgment, not a store limit.