Use store.get with a Dynamic Store for level-based offer values

Aghanim does not currently support automatically scaling the quantity inside a single SKU based on a player attribute such as level. To deliver level-based values in the HUB, use a store.get webhook with a Dynamic Store, or create separate SKUs and gate them with store rules or level requirements.

Recommended approach: Dynamic Store + store.get webhook

1. Create a new store of type Webhook in LiveOps Builder → Stores.

2. Select the webhook endpoint that will respond to store.get.

3. Add this Dynamic Store to your Store Rules.

4. When the HUB requests the store, return the SKU list and the quantity values you want to show for that player.

This lets your backend calculate the reward quantity for each player, for example from their level or another progression attribute.

Important: do not add the same items directly to the Dynamic Store if you want webhook values to win

If you manually add a product to the Dynamic Store, the product properties configured in the dashboard can override the values returned by store.get.

For example, if the webhook returns a SKU with a higher dynamic quantity but that SKU is also present in the Dynamic Store with a static quantity, the static product properties may be shown instead.

To keep the webhook-provided quantity, add the Dynamic Store to Store Rules and let the webhook supply the items and values.

Testing with different players

You can now specify a player_id during testing. This makes it easier to simulate different players and verify that your store.get logic returns the expected values.

Sorting items in a Dynamic Store

If your items are populated dynamically through store.get, you can sort them in several ways:

• Use SKU categories.

• Use Store Rule sorting, such as sorting by Price, Discount, or Position.

• If your use case allows it, pre-create SKUs and control visibility through segmentation parameters.

Note that manually adding SKUs to the Dynamic Store can interfere with webhook-driven values, so this is not the best option when your goal is to override quantities dynamically.

Alternative approach: separate SKUs by level

If you do not want to use store.get, you can create different SKUs for different level ranges and then either:

• create different stores with level attribute checks, or

• put the SKUs in the same store and set level requirements for each item.

This works, but it can create significant manual setup if you need a large number of level-specific variants.

Current limitation

Automatic quantity scaling inside a single SKU based on player attributes is not currently available as a built-in feature.