store.get webhook: timeout, retries, response size, caching, and store type switching

This article summarizes operational behavior of the store.get webhook that is not fully spelled out in the public docs.

Timeout

• Aghanim currently waits up to 30 seconds for a store.get response.
• This timeout is not configurable per webhook today.
• The platform team plans to reduce this default timeout to 10 seconds in the future.

Even though the hard timeout is currently higher, integrations should aim to return the store payload in well under a second when possible, because slow store.get responses directly affect the player experience in the Hub.

Retries and delivery mode

• store.get is a synchronous webhook.
• Like player.verify, it is handled as a single attempt.
• No retries are performed for failed or timed-out store.get requests.

Response size limits

• There is no explicit documented limit for the store.get response size.
• There is also no explicit documented limit on the number of elements in items.
• There may still be practical technical limits at very large payload sizes, but those are expected to be far above a reasonable store response.

As a best practice, do not return hundreds of items from store.get. Prefer returning a focused set of the most relevant or popular offers, typically no more than a few dozen items.

Caching

On the live environment, Aghanim typically caches the store.get response for about 1 minute. This is configurable in the store settings.

Changing a store between static and webhook modes

Switching an existing store's type between a static catalog mode (for example, limited_stock) and webhook is not a recommended workflow.

• This rollback scenario has not been validated by the team.
• If you need a fallback strategy for webhook instability, do not assume that switching the store type back and forth is a supported, tested recovery path.

If you are planning an operational fallback from a webhook-driven store to a static catalog, contact the Aghanim team first and validate the exact setup for your project before relying on that flow in production.

Planned fallback support for webhook stores

The platform team has stated that they plan to add support in Store Rules for webhook-store fallback behavior.

• You will be able to specify a fallback store for a webhook store, to be shown when the webhook is unavailable.
• You will also be able to configure the timeout there.

Until this capability is released and documented, treat it as a planned improvement rather than a generally available production feature.