Heimdall

Write store text for several languages at once from a file the user prepared — the values are theirs, read straight from the file rather than retyped. Accepts CSV with a "locale" column and one column per field, or JSON keyed by locale. Every value is checked against Apple’s character limits before anything is sent, so a file with a bad value changes nothing at all. Apple is still asked one language at a time: if it rejects the eleventh, the first ten are already written and the error names exactly which ones landed.

Compare an app version’s store text across every language and report what is missing or over Apple’s limit — empty descriptions, blank keywords, fields present in one language and absent in others. Read-only: it reports and stops, and never fills anything in.

Return one language’s store text plus an instruction for you to draft it in the languages named. Only runs for locales the caller asks for — it never decides that a language looks stale. Returns a draft for a person to read; writing is a separate step, and for keywords the draft is a starting point rather than an answer, because keywords are a search-ranking choice rather than a translation.

Check subscription catalog readiness before submitting for review. Give the app and either a subscription (product ID, name or ID) or a group (reference name or ID). Checks localizations, group locales, prices, plan availability, review screenshot, review note and required attributes; reports state and blocking or warning findings with the raw tool that fixes each gap. Group mode checks at most 20 subscriptions. All reads are capped and truncation is reported. Read-only; ready means no observed blocking catalog gaps, not a prediction of Apple approval or permission to submit.

Check whether an app version is complete enough to submit, in one call, and list what is missing. Give the app (name, bundle ID or Apple ID). Verifies the build is attached and finished processing, the export compliance answer is given, the review contact and demo account are filled in, every locale has a description and keywords, and screenshots exist. Each gap names the tool that fixes it. Read-only — it changes nothing and does not submit.

Set one anchor price and let Apple derive the equivalent price in every other country, for an app, an in-app purchase or a subscription. Give the app, which kind of product, the anchor territory (e.g. TUR) and the price (e.g. "99.99"). Apple's own currency and tax maths decides each market — a price is NOT copied across currencies, because 4.99 USD is not 4.99 EUR. REVENUE-level write covering about 175 countries; run it under --dry-run first to see the full derived table.

Read current and scheduled app purchase prices by territory, including currency, customer price, proceeds, dates, and manual or automatic source. Omit territory for all countries.

Read current and scheduled in-app purchase prices by territory, including currency, customer price, proceeds, dates, and manual or automatic source. Give an IAP ID, or give the app and IAP product ID. Omit territory for all countries.

What a subscription costs customers today — in one country, or in every country at once. Give the app (name, bundle ID or Apple ID); both other arguments are optional. Omit the territory to get worldwide pricing, grouped by price so the answer stays readable, with the currency and the country codes in each group. Omit the subscription to cover every subscription in the app, which is how you answer "what does the weekly one cost" without knowing its product ID. Use this instead of chaining apps__list / subscription_groups / prices calls. It also returns the price actually in effect: subscriptio…

Change or set an in-app purchase (IAP) price in one territory (country) without assembling a price schedule. Give an IAP ID, or the app and IAP product ID, plus the territory (e.g. TUR) and the price (e.g. "99.99"). Apple replaces an IAP price schedule as a whole, so every other manual price and scheduled change is read and re-sent unchanged. Pricing the base territory also moves Apple's automatic prices elsewhere. REVENUE-level write.

Change or set a subscription price in one territory (country) in a single step. Give it the app (name, bundle ID or Apple ID), the subscription (product ID or name), the territory (e.g. TUR, USA) and the price (e.g. "99.99") — it resolves the app, subscription and Apple price point internally and performs the one write. Use this instead of chaining apps__list / subscription_groups / price_points calls when the goal is simply "set/raise/lower the price".

Send an App Store version to Apple for review in one call — it opens the submission, puts the version in it, and hands it over. Checks first that the version is actually submittable and refuses rather than submitting something that will bounce. Use this instead of review_submissions__create, which by itself sends nothing.

Fetch the last N days of reviews for an app, with volume and rating trend (computed deterministically), and an instruction for you to summarise top complaints, standout praise and one suggested action. Read-only.

Fetch one customer review and return it with an instruction for you to draft a reply — no separate API key needed, you write the text. Returns data only — never posts. Review the draft, then post it yourself with customer_review_responses__create if you approve it.

Fetch recent reviews for an app and return them with an instruction for you to group them by theme (bug, feature request, pricing complaint, praise, spam). Read-only.

Answer the single question "does this customer currently have access?". Returns a boolean plus the active subscriptions backing it — those come back as Apple's SIGNED payloads (JWS strings), so verify and decode them before reading any field. Optionally narrow to one product ID. [App Store Server API]

Extend a subscriber's renewal date — a service gesture for an outage or a support escalation. This changes billing, so confirm with the user before calling it. [App Store Server API]

Retrieve App Store Server Notification delivery history, including failures. Use to debug a webhook endpoint that is missing events. [App Store Server API]

List every refunded transaction for a customer. Useful for auditing refund abuse before granting goodwill credit. Returns Apple's SIGNED transactions (JWS strings) unless ASC_APPLE_ROOT_CERTS is set, in which case they arrive verified and decoded. [App Store Server API]

Get the status of every subscription a customer holds, including expiry date, auto-renew state, billing retry and grace period. Apple returns those fields inside SIGNED payloads (JWS strings) on each item, so verify and decode them before reading. Use this for entitlement checks. [App Store Server API]

Get a customer's full purchase history from any one of their transaction IDs. Supports filtering by product type, product ID and date range. Returns Apple's SIGNED transactions (JWS strings) unless ASC_APPLE_ROOT_CERTS is set, in which case they arrive verified and decoded. [App Store Server API]

Get a single transaction: product, price, dates, ownership type and revocation state. Set ASC_APPLE_ROOT_CERTS and the payload arrives verified and decoded; without it you get Apple's SIGNED payload (a JWS string) to verify yourself with the App Store Server Library. [App Store Server API]

Look up all transactions tied to an order ID from a customer receipt. Use when a customer sends you the order number from their email. [App Store Server API]

Ask Apple to send a test notification to your configured webhook endpoint. Returns a token you can use to look up the delivery result. [App Store Server API]

Assign one processed, unexpired TestFlight build to named beta groups. Checks existing assignments and reports each group, including partial failures. External groups may need beta app review before testers can install the build. RELEASE-level write.

Summarize what TestFlight beta testers are reporting: recent crash and screenshot feedback grouped by build version, counts, top devices and OS versions, newest comments, and short crash log excerpts. Give the app (name, bundle ID or Apple ID), optionally a build number or UUID and days (default 14, max 90). Reads at most five pages of 50 submissions per type, ten comments per type per build, and three crash logs (first 40 lines or 4 KB each). Reports truncation. Read-only.