Resources

Changelog

What has actually changed on StreamBoost, newest first. Every entry describes behaviour that is live.

11 entries

September 2026

  1. Orders

    Resumable partial orders and live progress

    A partially delivered order is an order with quantity still owed, not a finished one. The lifecycle now treats it that way, and progress reaches the customer as it happens.

    • ChangedA partially delivered order stays active where the fulfilment system supports continuation, and is pursued until the requested quantity is delivered.
    • AddedLive order progress on the customer order page — delivered count, remaining, percentage and status update without a refresh.
    • AddedA conservative refresh fallback for networks where a live connection cannot be established.
    • ChangedPaused and retrying states reported by a fulfilment system now count as active work rather than as a stop.
    • AddedA stall guard: an order that is answered but never advances moves to a slower schedule and is surfaced for review instead of being retried forever.
  2. Orders

    Cleaner cancellation lifecycle

    Cancelling now ends active processing completely and immediately, while keeping the record intact for billing and audit.

    • ChangedA cancelled order leaves the work queue at once: it stops being polled, stops being continued, and releases its worker claim and schedule.
    • AddedA cancellation timestamp, recorded separately from completion so a cancelled order never shows a completion date.
    • FixedA status read that returned after an order was cancelled could put it back into a running state. Progress writes are now refused once an order is terminal, so the cancellation always wins.
    • ChangedA cancellation reported by the fulfilment system itself produces the identical terminal transition as an administrator-initiated one.
    • ChangedCancelled orders no longer count toward a provider's active order total.
  3. Providers

    Health monitoring, retries and recovery

    Fulfilment outages are handled as information about the system rather than as a verdict on anyone's order.

    • AddedContinuous health tracking per fulfilment system, measured from real requests rather than declared by an administrator.
    • AddedA read-only health probe that never creates an order.
    • ChangedAn unreachable fulfilment system no longer fails or refunds orders. They keep their progress and resume automatically on recovery.
    • AddedA fixed retry backoff ladder — 30s, 1m, 2m, 5m, then 10m held — with any success resetting it immediately.
    • AddedRetry-After is honoured when a fulfilment system asks for longer than that schedule.
  4. Orders

    Automatic background synchronisation

    Order tracking runs on the server on its own schedule, independent of whether anyone has a browser open.

    • AddedA background worker that checks fulfilment health and synchronises every active order each cycle.
    • AddedAtomic claiming of orders, so two workers running at once pick up disjoint sets and never poll the same job twice.
    • AddedBounded concurrency and a per-request timeout, so one slow fulfilment system cannot stall everything else.
    • ChangedDelivered quantity is clamped to what was ordered, so over-reporting cannot invent units a customer did not buy.
  5. Providers

    Provider configuration and admin order management

    Fulfilment systems are configured in the admin area, with capabilities declared explicitly rather than assumed.

    • AddedPer-provider capability declarations covering create, status, cancel, balance, idempotent create and resume.
    • AddedAn admin order console for inspecting, synchronising, cancelling, refunding and reconciling orders.
    • AddedA needs-attention queue for orders where money moved but the outcome at the fulfilment system is uncertain.
    • ChangedProvider credentials are encrypted at rest and opened only inside the server-side adapter that makes the call.
    • AddedAn administrative audit log recording who cancelled, refunded or reconciled an order.
  6. Providers

    Provider API specification v2.2

    The integration specification is generated from one source, so the page administrators read and the file they hand to a developer cannot disagree.

    • AddedComplete request and response examples for every endpoint, headers included.
    • AddedExplicit cancellation semantics, including what leaves active processing and what is retained.
    • AddedA worked partial-delivery progression showing how an order runs to completion.
    • FixedThe specification described a resume request body that was never sent. Resume and cancel carry no body; the order is identified by the path.
  7. Services

    Database-backed services and pricing

    The catalogue is configuration rather than code, and every price is computed server-side from that configuration.

    • AddedFour pricing models: fixed, per unit, per thousand, and tiered bands.
    • ChangedPrices are calculated on the server at order time. A value sent by a browser is never treated as an authority.
    • AddedPer-service target format validation and quantity limits, enforced before a balance is charged.
    • ChangedRequested quantity is recorded exactly as ordered and never rewritten to match what was delivered.
  8. Payments

    Cryptocurrency payments alongside cards

    Balance top-ups can be made by card or by cryptocurrency, with both crediting through the same ledger.

    • AddedCryptocurrency top-ups alongside the existing card payments.
    • AddedSignature-verified payment webhooks, with each event recorded once so a replay cannot credit a balance twice.
    • ChangedEvery balance movement is written to a ledger entry in the same transaction that changes the balance.
    • AddedRefunds are claimed with a conditional update, making a duplicate refund impossible even under concurrent requests.
    • ChangedA redesigned billing page covering top-ups, transactions and history.
  9. Security

    Account security and anti-abuse

    Sign-up and sign-in are protected against automation, and session handling was corrected end to end.

    • AddedA proof-of-work challenge and browser execution attestation on account creation, so a request-only script cannot sign up by replaying captured values.
    • ChangedAuthorisation values are server-issued, single-use and replay-resistant.
    • AddedRate limiting across address, email, account, session and endpoint, working on hashed identifiers rather than raw values.
    • FixedThe session cookie's Secure flag is derived from how the request actually arrived rather than from the build mode, which previously caused sessions to be discarded over plain HTTP.
    • FixedA database error during session lookup was being treated as a sign-out. It is now surfaced as an error instead of silently logging someone out.
    • FixedA signed-in visitor arriving at the home page saw the signed-out header. The page now reads the session per request.
  10. Support

    Help Center and support improvements

    The support area now answers the common questions directly, alongside the existing ticket system.

    • AddedA Help Center covering account, payments, orders, delivery states and privacy, with category navigation.
    • AddedLive ticket updates, so a reply appears without refreshing.
    • ChangedTicket messages are machine-translated on a service hosted on the same machine — ticket text is not sent to a hosted translation API.
    • AddedUnread tracking across the ticket list.
  11. Website

    Rebuilt public site

    Every page outside the dashboard was written properly, and every footer link now resolves to a real destination.

    • AddedFeatures, pricing, about, blog, careers, community, changelog and status pages.
    • AddedPrivacy, terms, security and cookie policies written from the implementation rather than a template.
    • AddedA status page that runs live checks and publishes no uptime figure, because no uptime monitoring exists to measure one.
    • FixedFooter and navigation placeholder links that went nowhere now point at real pages.
    • ChangedPublic pages render in the visitor's language alongside the dashboard.

About these dates

Entries are grouped by month rather than by exact day. StreamBoost does not publish tagged releases, and a precise date here would be a number someone typed rather than one anything recorded — a month is accurate and still tells you when something landed.

ServicesThe live catalogue these changes apply to.BlogLonger explanations of how the platform works.StatusWhether everything is working right now.
Changelog · StreamBoost