Abort offers
Removes offers from every player's web shop at once, for an offer that has to come down before the catalog cache would drop it (for example a wrong price or wrong contents). Each entry names an offer by the identifier your catalog sends: a purchase pack's id (the whole pack, every price point), a purchasable item's product_id (every per-player variant), or a free or non-purchasable item's item_id. Without a version, the abort hides that offer from every player's catalog, whatever your Get Catalog response returns, until you un-abort it; no catalog is fetched again from your server. With a version that is a whole number written only with the ASCII digits 0 to 9 (for example 5), the abort hides the offer with that identifier at that version and at every lower whole-number version, compared by value: an abort of 10 hides 9, an abort of 5 does not hide 10, and 05 reads as 5. With any other version (for example v5, a version with a sign or spaces, or one using digits other than the ASCII 0 to 9), the abort hides only the offer with exactly that version, compared character for character. Cached catalogs that still hold a hidden version are fetched again from your server on each player's next visit. To bring the offer back fixed, re-publish it under the same identifier with a higher version than the one you aborted: it shows as soon as Get Catalog returns it, with no un-abort needed, while a fix re-published at the aborted version or lower stays hidden. An abort with a version never matches an offer sent without a version. An abort with a version expires 7 days after it was made; an abort without a version lasts until un-aborted. Calls are idempotent: an entry that names an abort already active changes nothing. At most 100 entries per call. A purchase already in checkout when the abort lands can still complete, so Confirm Payment remains your last check. Applies only to shops with a real-time catalog integration and offer aborts enabled; any other shop is refused with FAILED_PRECONDITION.
Versioned HMAC-SHA256 signature authenticating server-to-server SDK requests (your backend calling Stash), as opposed to client-side SDK operations. Recommended over the deprecated X-Stash-Api-Key for the best security. Header format: v1;{appId};{unixMillisTimestamp};{base64Signature} (semicolon-delimited). {base64Signature} is the base64-encoded HMAC-SHA256 of the string {unixMillisTimestamp}.{requestBody} using your app ingress secret (the ingress secret is shown base64-encoded in Studio; base64-decode it to the raw bytes used as the HMAC key), where {requestBody} is the request body exactly as you send it for POST and PUT requests (the compact canonical request JSON is also accepted) and empty for GET requests. A signature over the exact bytes verifies for bodies of up to 18 KiB (18,432 bytes); a larger body may be refused with 401 even when correctly signed. The timestamp must be within 5 minutes of Stash server time. Your appId is your immutable app identifier, shown in Stash Studio under Project Settings > App details; your ingress secret is under Project Settings > API Secrets.
In: header
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Response Body
application/json
application/json
curl -X POST "https://example.com/sdk/server/catalog/offer-aborts/abort" \ -H "Content-Type: application/json" \ -d '{ "offers": [ { "offerId": "string" } ] }'{ "results": [ { "abort": { "offerId": "string", "version": "string", "source": "OFFER_ABORT_SOURCE_UNSPECIFIED", "reason": "string", "createdAt": "2019-08-24T14:15:22Z", "expiresAt": "2019-08-24T14:15:22Z" }, "created": true } ]}How is this guide?
Getting Started
APIs provided by Stash that your backend can call.
Force refresh catalog POST
Refreshes a web shop's cached catalog so the next time a player opens the shop it reflects the latest catalog from your game backend. Applies only to shops with a real-time catalog integration; for any other integration it is a no-op that still returns success. You rarely need to call it: the catalog already refreshes automatically after web shop purchases and free-gift redemptions, and checkout always revalidates against the server. It is most useful after an in-game purchase (outside the web shop) when you want the catalog view in the Web Shop to update right away. Name the players to refresh in player_ids; when several players need a refresh at the same time, send them in one request rather than one request per player.