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.

POST
/sdk/server/catalog/offer-aborts/abort
x-stash-hmac-signature<token>

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?