@smartico/public-api 0.0.411 → 0.0.413

package/dist/Jackpots/JackpotPublicMeta.d.ts

@@ -17,7 +17,7 @@ interface JackpotPublicMeta {
     /**
      * Custom data as string or JSON string that can be used in API to build custom UI
      * You can request from Smartico to define fields for your specific case that will be managed from Smartico BackOffice
-     * Read more here - <https://help.smartico.ai/welcome/products/general-concepts/custom-fields-attributes>
+     * Read more here - <https://help.smartico.ai/welcome/products/tools-and-guides/custom-fields-attributes>
     */
     custom_data: string;
 }

package/dist/Level/LevelPublicMeta.d.ts

@@ -17,7 +17,7 @@ export interface LevelPublicMeta {
     /**
      * Custom data as string or JSON string that can be used in API to build custom UI
      * You can request from Smartico to define fields for your specific case that will be managed from Smartico BackOffice
-     * Read more here - https://help.smartico.ai/welcome/products/general-concepts/custom-fields-attributes
+     * Read more here - https://help.smartico.ai/welcome/products/tools-and-guides/custom-fields-attributes
     */
     custom_data?: string;
 }

package/dist/MiniGames/SAWTemplate.d.ts

@@ -56,6 +56,8 @@ export interface SAWTemplate {
     expose_game_stat_on_api?: boolean;
     /** Prize Drop only: when true, the pushed prize requires an explicit claim by the user before it is credited */
     requires_prize_claim?: boolean;
+    /** Prize Drop only: when true, the pushed prize requires a manual claim by the user before it is credited. The difference between this and `requires_prize_claim` is that requires_manual_claim gives the user the ability to cancel the claim. */
+    requires_manual_claim?: boolean;
     /** Timezone offset in minutes used to evaluate the template's period-based rules (UTC minus local, as in JS `Date.getTimezoneOffset()`) */
     relative_period_timezone?: number;
     /** Operator setting: show a prize-history entry point (icon / button) on this game's view */

package/dist/Raffle/Raffle.d.ts

@@ -23,7 +23,7 @@ interface RafflePublicMeta {
     /**
      * Custom data as string or JSON string that can be used in API to build custom UI
      * You can request from Smartico to define fields for your specific case that will be managed from Smartico BackOffice
-     * Read more here - <https://help.smartico.ai/welcome/products/general-concepts/custom-fields-attributes>
+     * Read more here - <https://help.smartico.ai/welcome/products/tools-and-guides/custom-fields-attributes>
      */
     custom_data: string;
     /**

package/dist/SmarticoLib/index.d.ts

@@ -854,21 +854,21 @@ export interface TLevel {
     /**
      * The counter of 1st metric used to reach the Level.
      * Relevant in case of using advanced leveling logic
-     * https://help.smartico.ai/welcome/more/release-notes/september-2022#new-logic-for-leveling-users
+     * https://help.smartico.ai/welcome/products/release-notes/september-2022#new-logic-for-leveling-users
      *
      */
     required_level_counter_1: number;
     /**
      * The counter of 2nd metric used to reach the Level.
      * Relevant in case of using advanced leveling logic
-     * https://help.smartico.ai/welcome/more/release-notes/september-2022#new-logic-for-leveling-users
+     * https://help.smartico.ai/welcome/products/release-notes/september-2022#new-logic-for-leveling-users
      *
      */
     required_level_counter_2: number;
     /**
      * Custom data as string or JSON string that can be used in API to build custom UI
      * You can request from Smartico to define fields for your specific case that will be managed from Smartico BackOffice
-     * Read more here - https://help.smartico.ai/welcome/products/general-concepts/custom-fields-attributes
+     * Read more here - https://help.smartico.ai/welcome/products/tools-and-guides/custom-fields-attributes
      */
     custom_data: string;
 }

package/dist/WSAPI/WSAPIJackpots.d.ts

@@ -245,7 +245,9 @@ export declare class WSAPIJackpots extends WSAPIClans {
      * user-currency display is needed, the consumer must convert client-side.
      *
      * **Refresh**
-     * - The SDK caches per `jp_template_id` for 30 seconds.
+     * - The SDK caches each page separately (per `jp_template_id` +
+     *   `limit` + `offset`) for 30 seconds, so paging back and forth is
+     *   served from cache and each page keeps its own fresh copy.
      * - Caches clear on jackpot-win push events and on opt-in / opt-out.
      *
      * **Error handling**

package/dist/WSAPI/WSAPIMissions.d.ts

@@ -55,18 +55,46 @@ export declare class WSAPIMissions extends WSAPIGeneral {
      * `only_in_custom_section: true` are intended for their custom-section
      * view only and should be hidden from the main mission list.
      *
-     * **Reading state from the returned mission**
-     * Drive availability chips ("missed", "coming soon", "needs opt-in",
-     * "in progress", "expired") from `availability_status` (enum
-     * {@link AchievementAvailabilityStatus}) — it's the canonical derived
-     * state and reflects all server-side timing/visibility rules in one
-     * field. For time-limited and recurring missions, `dt_start` doubles
-     * as the opt-in timestamp (for opt-in missions) or unlock timestamp
-     * (for previously-locked missions); the expiration of a time-limited
-     * mission is `dt_start + time_limit_ms`. `next_recurrence_date_ts`
-     * is populated for `RECURRING` / `RECURRING_QUANTITY` missions but
-     * is no longer meaningful once the mission's `active_till_ts` has
-     * passed.
+     * **Status bucketing (which tab / section a mission belongs to)**
+     * There is no pre-computed bucket field — assign each mission to exactly
+     * ONE section reading the raw state fields directly (NOT `availability_status`;
+     * see "Timers" below). Priority order, FIRST match wins:
+     * 1. **Missed / Expired** — not completed and the window has closed:
+     *    `!is_completed && ((time_limit_ms && dt_start && dt_start + time_limit_ms < Date.now())`
+     *    `|| (active_till_ts && active_till_ts < Date.now()))`. Do NOT gate this on
+     *    opt-in — an opt-in mission whose window closed before the user ever
+     *    opted in is still Missed. Sort by `position` ASC.
+     * 2. **Completed** — `is_completed === true`, OR (recurring-upon-completion
+     *    missions) at least one cycle done / the cap reached — see the recurring
+     *    caveats below. Sort by `complete_date_ts` DESC.
+     * 3. **Locked** — `is_locked === true`, OR not yet started
+     *    (`active_from_ts > Date.now()`). Sort by `position` ASC.
+     * 4. **In-progress** — `is_opted_in === true`, OR (no opt-in required and
+     *    `progress > 0`). Sort by `position` ASC.
+     * 5. **Available** — everything else (opt-in required but not yet joined, or
+     *    an unrestricted mission not yet started). Sort by `position` ASC.
+     *
+     * **Recurring-upon-completion caveats** (the common mis-bucketing trap):
+     * - `is_completed` NEVER flips true for a recurring-upon-completion mission
+     *   (only for one-shot missions) — detect a completed cycle from
+     *   `completion_count > 0`, not `is_completed`.
+     * - A non-null `completion_count` is what identifies a recurring-upon-completion
+     *   mission. `max_completion_count === null` means an INFINITE cap (still
+     *   recurring — never read null as "not recurring"), so only test
+     *   `completion_count >= max_completion_count` when `max_completion_count` is set.
+     *
+     * **Timers & timestamps** (display only — NOT bucketing)
+     * `availability_status` (enum {@link AchievementAvailabilityStatus}) is the
+     * timer/window signal: use it to pick WHICH countdown to show and whether the
+     * window has elapsed — NOT to choose the section. It does not read
+     * `completion_count`, and between cycles the server may keep reporting the
+     * just-elapsed cycle's `Missed*` value even after `dt_start` / `active_till_ts`
+     * are cleared for the next attempt, so bucketing by it sends recurring missions
+     * to the wrong tab. For time-limited / opt-in missions `dt_start` is the opt-in
+     * timestamp (or unlock timestamp for previously-locked missions), and a
+     * time-limited mission expires at `dt_start + time_limit_ms`.
+     * `next_recurrence_date_ts` is populated for `RECURRING` / `RECURRING_QUANTITY`
+     * missions but is no longer meaningful once `active_till_ts` has passed.
      *
      * **Refresh after a mutation**
      * After `requestMissionOptIn(...)` or `requestMissionClaimReward(...)`

package/dist/WSAPI/WSAPITypes.d.ts

@@ -826,7 +826,9 @@ export interface TMissionOrBadge {
     reward: string;
     /** URL of the image of the mission or badge, 256x256px */
     image: string;
-    /** Indicator if the mission is completed or badge is granted */
+    /** Indicator if the mission is completed or badge is granted. Stays `false` for
+     * Recurring-upon-completion missions even after cycles complete — use `completion_count`
+     * to detect completed cycles (see `getMissions` bucketing). */
     is_completed: boolean;
     /** Indicator if the mission is locked. Means that it's visible to the user, but he cannot progress in it until it's unlocked.
      * Mission may optionally contain the explanation of what should be done to unlock it in the unlock_mission_description property
@@ -898,15 +900,15 @@ export interface TMissionOrBadge {
     completed_this_month?: boolean;
     /** ID of specific Custom Section type */
     custom_section_type_id?: number;
-    /** Max number of times the user can complete a mission in case if mission type is Recurring upon completion. NULL equals infinite. */
+    /** Max number of times the user can complete a mission in case if mission type is Recurring upon completion. NULL equals infinite (still recurring — not "no cap disables recurring"). */
     max_completion_count?: number;
-    /** Current completion count for Recurring upon completion missions */
+    /** Current completion count for Recurring-upon-completion missions. Non-null ONLY for that mission type, so its presence identifies one; `> 0` means at least one cycle completed. */
     completion_count?: number;
     /** The date/timestamp for recurring missions, which indicating the time remaining until the next recurrence of the mission.
      * Note that if a mission has an "Active till" date defined, this field is not relevant after that date.
     */
     next_recurrence_date_ts?: number;
-    /** Availability status of the mission depends on the defined time limits */
+    /** Timer/window state derived from the mission's time limits (which countdown to show / whether the window elapsed). NOT a tab-bucketing signal — it ignores `completion_count`, so bucket sections from the raw fields instead (see `getMissions`). */
     availability_status?: AchievementAvailabilityStatus;
     /** Title for the claim reward button */
     claim_button_title?: string;
@@ -1343,7 +1345,7 @@ export interface TRaffle {
     /**
      * Custom data as string or JSON string that can be used in API to build custom UI
      * You can request from Smartico to define fields for your specific case that will be managed from Smartico BackOffice
-     * Read more here - https://help.smartico.ai/welcome/products/general-concepts/custom-fields-attributes
+     * Read more here - https://help.smartico.ai/welcome/products/tools-and-guides/custom-fields-attributes
      */
     custom_data: string;
     /** Date of start */

package/dist/index.js

@@ -3409,18 +3409,46 @@ var WSAPIMissions = /*#__PURE__*/function (_WSAPIGeneral) {
    * `only_in_custom_section: true` are intended for their custom-section
    * view only and should be hidden from the main mission list.
    *
-   * **Reading state from the returned mission**
-   * Drive availability chips ("missed", "coming soon", "needs opt-in",
-   * "in progress", "expired") from `availability_status` (enum
-   * {@link AchievementAvailabilityStatus}) — it's the canonical derived
-   * state and reflects all server-side timing/visibility rules in one
-   * field. For time-limited and recurring missions, `dt_start` doubles
-   * as the opt-in timestamp (for opt-in missions) or unlock timestamp
-   * (for previously-locked missions); the expiration of a time-limited
-   * mission is `dt_start + time_limit_ms`. `next_recurrence_date_ts`
-   * is populated for `RECURRING` / `RECURRING_QUANTITY` missions but
-   * is no longer meaningful once the mission's `active_till_ts` has
-   * passed.
+   * **Status bucketing (which tab / section a mission belongs to)**
+   * There is no pre-computed bucket field — assign each mission to exactly
+   * ONE section reading the raw state fields directly (NOT `availability_status`;
+   * see "Timers" below). Priority order, FIRST match wins:
+   * 1. **Missed / Expired** — not completed and the window has closed:
+   *    `!is_completed && ((time_limit_ms && dt_start && dt_start + time_limit_ms < Date.now())`
+   *    `|| (active_till_ts && active_till_ts < Date.now()))`. Do NOT gate this on
+   *    opt-in — an opt-in mission whose window closed before the user ever
+   *    opted in is still Missed. Sort by `position` ASC.
+   * 2. **Completed** — `is_completed === true`, OR (recurring-upon-completion
+   *    missions) at least one cycle done / the cap reached — see the recurring
+   *    caveats below. Sort by `complete_date_ts` DESC.
+   * 3. **Locked** — `is_locked === true`, OR not yet started
+   *    (`active_from_ts > Date.now()`). Sort by `position` ASC.
+   * 4. **In-progress** — `is_opted_in === true`, OR (no opt-in required and
+   *    `progress > 0`). Sort by `position` ASC.
+   * 5. **Available** — everything else (opt-in required but not yet joined, or
+   *    an unrestricted mission not yet started). Sort by `position` ASC.
+   *
+   * **Recurring-upon-completion caveats** (the common mis-bucketing trap):
+   * - `is_completed` NEVER flips true for a recurring-upon-completion mission
+   *   (only for one-shot missions) — detect a completed cycle from
+   *   `completion_count > 0`, not `is_completed`.
+   * - A non-null `completion_count` is what identifies a recurring-upon-completion
+   *   mission. `max_completion_count === null` means an INFINITE cap (still
+   *   recurring — never read null as "not recurring"), so only test
+   *   `completion_count >= max_completion_count` when `max_completion_count` is set.
+   *
+   * **Timers & timestamps** (display only — NOT bucketing)
+   * `availability_status` (enum {@link AchievementAvailabilityStatus}) is the
+   * timer/window signal: use it to pick WHICH countdown to show and whether the
+   * window has elapsed — NOT to choose the section. It does not read
+   * `completion_count`, and between cycles the server may keep reporting the
+   * just-elapsed cycle's `Missed*` value even after `dt_start` / `active_till_ts`
+   * are cleared for the next attempt, so bucketing by it sends recurring missions
+   * to the wrong tab. For time-limited / opt-in missions `dt_start` is the opt-in
+   * timestamp (or unlock timestamp for previously-locked missions), and a
+   * time-limited mission expires at `dt_start + time_limit_ms`.
+   * `next_recurrence_date_ts` is populated for `RECURRING` / `RECURRING_QUANTITY`
+   * missions but is no longer meaningful once `active_till_ts` has passed.
    *
    * **Refresh after a mutation**
    * After `requestMissionOptIn(...)` or `requestMissionClaimReward(...)`
@@ -6312,7 +6340,9 @@ var WSAPIJackpots = /*#__PURE__*/function (_WSAPIClans) {
    * user-currency display is needed, the consumer must convert client-side.
    *
    * **Refresh**
-   * - The SDK caches per `jp_template_id` for 30 seconds.
+   * - The SDK caches each page separately (per `jp_template_id` +
+   *   `limit` + `offset`) for 30 seconds, so paging back and forth is
+   *   served from cache and each page keeps its own fresh copy.
    * - Caches clear on jackpot-win push events and on opt-in / opt-out.
    *
    * **Error handling**
@@ -6350,7 +6380,10 @@ var WSAPIJackpots = /*#__PURE__*/function (_WSAPIClans) {
       jp_template_id = _ref.jp_template_id;
     try {
       var _this5 = this;
-      return Promise.resolve(OCache.use(onUpdateContextKey.JackpotWinners + jp_template_id, exports.ECacheContext.WSAPI, function () {
+      // Cache per (jp_template_id, limit, offset) so paging or switching
+      // jackpot within the TTL doesn't return a colliding winners list.
+      var cacheKey = "" + onUpdateContextKey.JackpotWinners + jp_template_id + ":" + limit + ":" + offset;
+      return Promise.resolve(OCache.use(cacheKey, exports.ECacheContext.WSAPI, function () {
         return _this5.api.getJackpotWinnersT(_this5.userExtId, limit, offset, jp_template_id);
       }, JACKPOT_WINNERS_CACHE_SEC));
     } catch (e) {