Product Feedback

1. Navigate to https://www.revenuecat.com/docs/migrating-to-revenuecat/migrating-existing-subscriptions
2. Find the section describing server-side import via 'POST /receipts'
3. Note that the endpoint is named but no request body schema, required headers, authentication details, or example payloads are provided on this page
4. Attempt to find a complete API reference for POST /receipts that covers batch/migration-specific behavior (e.g., handling of historical transactions, expected response codes, rate limits for bulk imports)

The migration page should either include inline examples of a valid POST /receipts request body (showing Apple receipt data and/or Google purchase token fields), document required vs optional parameters specific to the migration use case, explain rate limits for bulk imports, describe expected success and error responses, and link directly to the full API reference entry for this endpoint

The migration page only mentions 'sending all of the Apple receipts and/or purchase tokens to RevenueCat via the POST /receipts REST API endpoint' with no payload examples, no link to a detailed API reference, no guidance on pagination or batching for large imports, and no error handling guidance — leaving developers unable to implement the migration without significant trial and error

Add a dedicated 'Server-Side Import' subsection that includes: (1) a complete cURL or code example showing a valid POST /receipts request with authentication headers and body, (2) a field reference table covering app_user_id, fetch_token, and platform fields, (3) guidance on recommended batch sizes and rate limit considerations for bulk imports, (4) sample success (200) and error (400/401) response payloads, and (5) a direct link to the REST API reference page for POST /receipts

1. Navigate to https://www.revenuecat.com/docs/migrating-to-revenuecat/migrating-existing-subscriptions
2. Find the section describing server-side import via 'POST /receipts'
3. Look for request/response examples, required headers, body schema, or a link to the API reference for this endpoint

The migration guide should include a concrete example of the POST /receipts request (headers including Authorization, Content-Type, and body fields such as fetch_token or app_user_id), a sample response, and a direct link to the full REST API reference for this endpoint so developers can implement the import without additional searching.

The page only states that receipts should be sent 'via the POST /receipts REST API endpoint' with no example payload, no required field descriptions, no authentication guidance, and no link to the API reference — leaving developers without enough information to implement the server-side migration.

Add an inline code example showing a complete POST /receipts request with required headers (Authorization: Bearer ) and a minimal JSON body, plus a callout box linking to the full REST API reference. Also clarify whether Apple receipts and Google purchase tokens use the same endpoint with different body fields, since both are mentioned ambiguously.

1. Navigate to https://www.revenuecat.com/docs/tools/mcp/setup
2. Look for documentation on the two authentication methods mentioned
3. Attempt to find code examples or step-by-step instructions for each method

The setup page should fully describe both authentication methods with concrete examples (e.g., config snippets, token formats, environment variable names) so developers can immediately configure their AI assistant client without guessing.

The page only mentions that 'RevenueCat MCP Server offers two authentication methods depending on your client' with no further detail visible in the snippet — the methods themselves, their differences, and when to use each are not documented in the provided content.

Expand the MCP setup page to explicitly name both authentication methods (e.g., API key vs OAuth), describe which client types each applies to, and include a working configuration example for each method — similar to how RevenueCat's webhook and REST API docs provide sample payloads and headers.

1. Navigate to https://www.revenuecat.com/docs/migrating-to-revenuecat/migrating-existing-subscriptions
2. Find the section describing server-side import via 'POST /receipts'
3. Look for a request format, required headers, body schema, or authentication details for the endpoint

The migration guide should include a concrete REST API example for POST /receipts showing: required authentication headers, request body structure (receipt data fields for Apple and purchase token fields for Google), a sample cURL or code snippet, and a link to the full API reference for the endpoint

The endpoint is mentioned by name only ('POST /receipts REST API endpoint') with no request/response example, no field definitions, and no link to deeper API reference documentation — leaving developers without enough information to implement the import without additional research

Add an inline example block showing a sample POST /receipts request with headers (Authorization, Content-Type), a minimal valid body for both Apple receipts and Google purchase tokens, and a direct link to the REST API reference page for the /receipts endpoint. Clarify rate limits or batching guidance relevant to bulk migrations.

1. Navigate to https://www.revenuecat.com/docs/tools/mcp/setup
2. Look for documentation on the two authentication methods mentioned
3. Attempt to find examples, required credentials, or step-by-step instructions for each method

The setup page should clearly describe both authentication methods with: method names, required credentials/tokens, configuration examples for each supported AI client (e.g., Claude, Cursor), and guidance on which method to choose

The page only states 'RevenueCat MCP Server offers two authentication methods depending on your client' with no further detail visible in the snippet — leaving developers without actionable setup instructions

Expand the setup page to explicitly name and describe each authentication method (e.g., API key vs. OAuth), provide a configuration code block for each supported client, and add a decision guide explaining when to use each method. Cross-link from the MCP overview page at /tools/mcp.

1. Navigate to https://www.revenuecat.com/docs/migrating-to-revenuecat/migrating-existing-subscriptions
2. Find the section describing server-side import via 'POST /receipts'
3. Attempt to implement the import — note there is no example request body, required vs optional fields, authentication header format, rate limit guidance, or example success/error response shown on this page

Any documentation that directs developers to call a specific REST API endpoint should include: a complete example request (URL, headers, body), descriptions of all required and optional fields, an example success response, common error codes and their meanings, and any rate-limiting or batching considerations relevant to bulk migration

The migrating-existing-subscriptions page mentions 'sending all of the Apple receipts and/or purchase tokens to RevenueCat via the POST /receipts REST API endpoint' but provides no request/response examples, field definitions, or link to a dedicated API reference for this endpoint, leaving developers to guess at the correct payload structure

Add an inline code example showing a complete curl or HTTP request to POST /receipts with realistic sample data (receipt string, app user ID, platform), annotate each field, show a sample 200 response, list error scenarios (e.g., invalid receipt, duplicate), and link to the full REST API reference. Also clarify whether Android purchase tokens follow the same endpoint and payload structure as Apple receipts.

1. Navigate to https://www.revenuecat.com/docs/tools/mcp/setup
2. Read the section on authentication methods
3. Note that the page only mentions 'two authentication methods depending on your client' without specifying what those methods are, how to configure each, or which clients support which method

The setup page should clearly name both authentication methods (e.g., API key vs OAuth), describe when to use each, provide step-by-step configuration instructions for each method, and indicate which MCP clients are compatible with each approach

The page only states that 'RevenueCat MCP Server offers two authentication methods depending on your client' with no further elaboration visible in the provided snippet — leaving developers unable to complete setup without guessing or seeking external help

Expand the authentication section to: (1) explicitly name both methods, (2) provide a comparison table or decision guide matching client types to the appropriate method, (3) include a working configuration example for each method, and (4) link to any relevant API key generation pages in the RevenueCat dashboard

1. Navigate to https://www.revenuecat.com/docs/migrating-to-revenuecat/migrating-existing-subscriptions
2. Locate the section describing server-side import via the POST /receipts REST API endpoint
3. Look for a request/response example, required headers, body schema, or link to full API reference for this endpoint

The migration guide should include or link to a complete example of the POST /receipts call, covering: required authentication headers, full request body schema (Apple receipt data format, Android purchase tokens), expected success/error responses, and rate-limiting or batching considerations for bulk imports

The page mentions 'sending all of the Apple receipts and/or purchase tokens to RevenueCat via the POST /receipts REST API endpoint' but provides no example payload, no link to the API reference entry for this endpoint, and no guidance on handling large-scale bulk imports — leaving migrating developers without actionable implementation detail

Add a code example showing a complete POST /receipts request with sample headers and body for both Apple and Google receipts, link directly to the REST API reference page for this endpoint, and include a note on recommended batch size or rate limits when importing large subscriber histories

1. Navigate to https://www.revenuecat.com/docs/tools/mcp/setup
2. Look for documentation on the two authentication methods mentioned
3. Attempt to find complete configuration examples, required credentials, and step-by-step instructions for each method

The setup page should fully document both authentication methods with: names of each method, required credentials/tokens, example configuration snippets for common AI clients (e.g., Claude, Cursor), and guidance on when to use each method

The page only states 'RevenueCat MCP Server offers two authentication methods depending on your client' with no further detail visible in the snippet — leaving developers without the information needed to complete setup

Expand the setup page to name and describe both authentication methods explicitly, provide example configuration blocks for each supported AI client, list required API keys or OAuth credentials, and clarify which method applies to which client type

1. Navigate to https://www.revenuecat.com/docs/tools/mcp/setup
2. Read the opening statement: 'RevenueCat MCP Server offers two authentication methods depending on your client'
3. Look for an overview table, list, or summary that names both methods and indicates which clients or use-cases each applies to before diving into step-by-step instructions

The page should open with a concise comparison (e.g., a table or two-item list) naming both authentication methods, describing what each one is (e.g., OAuth vs. API key), and specifying which MCP clients or scenarios each method is appropriate for. This allows developers to immediately navigate to the relevant section without reading content that may not apply to them

The snippet only states that two methods exist 'depending on your client' without naming them upfront or providing decision criteria. Developers must read further into the page to discover which method applies to their setup, increasing friction and the risk of misconfiguration

Add a short 'Which method should I use?' section or comparison table at the top of the setup page listing both authentication method names, a one-line description of each, and the supported clients or prerequisites. For example: 'OAuth 2.0 – recommended for interactive clients that support browser-based login | API Key – recommended for headless/server-side clients.' Then link each row to its detailed setup section below.

1. Navigate to https://www.revenuecat.com/docs/migrating-to-revenuecat/migrating-existing-subscriptions
2. Locate the section describing server-side import via POST /receipts
3. Attempt to find request body parameters, required headers, authentication details, or a link to full API reference for this endpoint within the page

The migration guide should include either a complete example of a POST /receipts request (headers, body parameters for both Apple receipts and Google purchase tokens, and a sample response), or a prominent link to the relevant REST API reference page so developers can implement the import without guessing required fields

The page only mentions 'sending all of the Apple receipts and/or purchase tokens to RevenueCat via the POST /receipts REST API endpoint' with no parameters, authentication requirements, example payload, or direct link to API docs. Developers attempting a bulk migration would be left without critical implementation details at the most important step of the process

Add a code block showing a sample POST /receipts request with required headers (Authorization, Content-Type), key body fields (fetch_token, app_user_id, platform), and a truncated sample response. Include a callout box linking to the full REST API reference. Also clarify whether Google Play purchase tokens use the same endpoint and parameters as Apple receipts, since both are mentioned but treated identically in the current text.

1. Navigate to https://www.revenuecat.com/docs/migrating-to-revenuecat/migrating-existing-subscriptions
2. Find the section describing server-side import via 'POST /receipts'
3. Observe that the endpoint is named but no request body schema, required headers (e.g., Authorization, Content-Type), example payload for Apple receipts vs. Google purchase tokens, or link to the full REST API reference is provided

The migration guide should include or link to: the full endpoint URL, required and optional request headers, a JSON request body example for both Apple (receipt data) and Google (purchase token) imports, expected success and error responses, and rate-limit or batching guidance given potentially large import volumes

The page only mentions 'POST /receipts REST API endpoint' in passing without any code sample, parameter description, or reference link — developers performing a migration must hunt separately for API docs and may construct malformed requests

Add an inline code block showing a complete curl or HTTP example for both Apple and Android receipt imports, document required headers (Authorization: Bearer ), explain the receipt_data vs. fetch_token fields, note any per-request limits, and add a prominent link to the REST API reference page for POST /receipts

1. Navigate to https://www.revenuecat.com/docs/tools/mcp/setup
2. Read the section on authentication methods
3. Note that the page states 'RevenueCat MCP Server offers two authentication methods depending on your client' but provides no further detail visible in the snippet about what those two methods are, how to configure each, or which clients support which method

The setup page should clearly name both authentication methods, explain when to use each one, provide configuration examples for each supported client (e.g., Claude Desktop, Cursor, etc.), and include any required API keys or OAuth scopes needed

The snippet only states that two authentication methods exist 'depending on your client' with no elaboration on method names, client compatibility matrix, or concrete configuration examples — leaving developers unable to complete setup without guessing

Expand the setup page to: (1) explicitly name both authentication methods (e.g., API key vs. OAuth), (2) provide a compatibility table mapping each method to supported MCP clients, (3) include step-by-step configuration snippets for each client/method combination, and (4) link to where developers can generate the required credentials in the RevenueCat dashboard

1. Navigate to https://www.revenuecat.com/docs/migrating-to-revenuecat/migrating-existing-subscriptions
2. Read the section describing server-side import via 'POST /receipts'
3. Observe that the endpoint is named but no request example, required headers, body schema, or response structure is shown
4. Attempt to implement the import without additional documentation

The migration page should include a complete, runnable example of a POST /receipts request — covering the full URL, required Authorization header, Content-Type, request body fields (e.g. fetch_token, app_user_id), and a sample success/error response — so developers can implement the bulk import without needing to cross-reference multiple pages

The page only mentions 'POST /receipts REST API endpoint' by name with no accompanying request example, parameter definitions, authentication instructions, or notes on rate limits or error handling, making it difficult for developers to implement the migration without significant additional research

Add a dedicated code block to the server-side import section showing a complete curl or HTTP example of POST /receipts including the Authorization header, JSON body with all required and optional fields, and an example 201 response. Link directly to the REST API reference for the endpoint and add a note on any rate limits or recommended batch sizes for large-scale migrations

1. Navigate to https://www.revenuecat.com/docs/tools/mcp/setup
2. Read the section on authentication methods
3. Note that the page states 'RevenueCat MCP Server offers two authentication methods depending on your client' but provides no further detail in the snippet about what those two methods are, how to configure each, or which clients support which method

The setup page should clearly name and describe both authentication methods, provide configuration examples for each, and specify which MCP clients are compatible with each method so developers can successfully authenticate without guessing or searching elsewhere

The documentation only states that two authentication methods exist 'depending on your client' with no elaboration on method names, configuration steps, required credentials, or client compatibility guidance — leaving developers without actionable setup instructions

Expand the setup page to explicitly name both authentication methods (e.g. API key vs OAuth), provide step-by-step configuration instructions and credential requirements for each, include a compatibility table mapping MCP clients to the supported method, and add a working configuration code example for at least one popular client such as Claude Desktop or Cursor

1. Navigate to https://www.revenuecat.com/docs/migrating-to-revenuecat/migrating-existing-subscriptions
2. Find the section describing server-side import using the POST /receipts REST API endpoint
3. Look for a complete request example including required headers, body schema, and a sample success/error response

The migration guide should include a full cURL or code example showing the POST /receipts request with required headers (e.g., Authorization, Content-Type), a sample request body containing an Apple receipt or Google purchase token, and annotated success/failure response payloads so developers can validate their integration before running a bulk import

The documentation only mentions the endpoint name ('POST /receipts') without providing any concrete request/response examples, required fields, rate-limit considerations, or error handling guidance — all of which are critical for a bulk migration operation

Add a dedicated 'Server-Side Import' subsection containing: (1) a cURL example with all required headers and a minimal valid body for both Apple receipts and Google purchase tokens, (2) a sample success response, (3) common error codes and their resolutions, and (4) a note on rate limits and recommended batching strategy to avoid throttling during large migrations.

1. Navigate to https://www.revenuecat.com/docs/tools/mcp/setup
2. Read the section stating 'RevenueCat MCP Server offers two authentication methods depending on your client'
3. Attempt to find documentation of what those two methods are, how to configure each, and which clients support which method

The setup page should clearly enumerate both authentication methods, provide configuration examples for each, and specify which MCP clients (e.g., Claude Desktop, Cursor, etc.) are compatible with each method

The snippet only states that two authentication methods exist 'depending on your client' with no further detail provided in the extracted content, leaving developers unable to determine which method to use or how to configure it

Expand the setup page to explicitly name and describe both authentication methods (e.g., API key vs OAuth), provide step-by-step configuration snippets for each, and include a compatibility table mapping authentication methods to supported MCP clients. Cross-link from the MCP overview page directly to the relevant auth section.

1. Navigate to the Webhooks documentation page at https://www.revenuecat.com/docs/integrations/webhooks
2. Scroll to the "Syncing Subscription Status" section.
3. Read the recommendation:

   "Because different webhook events contain unique information, we recommend calling the GET /subscribers REST API endpoint after receiving any webhook. That way, the customer's information is always in the same format and is easily synced to your database."

4. Click the REST API link — it goes to https://www.revenuecat.com/docs/api-v1#tag/customers — the v1 API.
5. Now navigate to the RevenueCat REST API documentation top-level. Observe that there are two REST API versions in the nav: "API v1" and "API v2" (https://www.revenuecat.com/docs/api-v2).
6. The v2 API was described by RevenueCat as "a new and improved version with customer usability in mind" (https://www.revenuecat.com/blog/engineering/were-rebuilding-our-rest-apis/). It has been the current API for new integrations.
7. Nowhere in the Webhooks page does it explain:
8. Whether the v2 API has an equivalent customer/subscriber lookup endpoint
9. Whether v1 must be used specifically for this webhook pattern
10. Whether new integrations built against v2 need to fall back to v1 for subscriber lookups after receiving webhooks
11. A developer building a new webhook backend today will be uncertain: should they use v1 (as directed here), v2 (the newer API they may have already integrated), or both?

The "Syncing Subscription Status" section should clearly guide developers to the correct API endpoint regardless of which API version they are using. If the v2 API has an equivalent subscriber/customer lookup endpoint (e.g., a GET /projects/{project_id}/customers/{app_user_id} endpoint), the section should reference it alongside or instead of the v1 endpoint. If the v2 API does NOT yet have an equivalent endpoint (meaning v1 must still be used for this specific use case), the section should explicitly state this so developers understand why they need to call v1 even if their integration otherwise uses v2. Without this context, developers building webhook handlers for new integrations following the rest of the v2-oriented docs will hit an unexplained gap.

The Webhooks page at https://www.revenuecat.com/docs/integrations/webhooks contains:

"we recommend calling the GET /subscribers REST API endpoint after receiving any webhook."

• Only v1 is referenced: The link goes to api-v1#tag/customers. The v2 API (/docs/api-v2) is not mentioned at all in this section or anywhere else on the Webhooks page.

• No explanation of v1 vs v2 for this use case: The RestAPI navbar shows both "API v1" and "API v2," suggesting developers have a choice — but the Webhooks page never acknowledges that choice. A developer who has read RevenueCat's own blog post about v2 ("a new and improved version with customer usability in mind") would naturally try to use v2 for their webhook handler and then be confused when directed back to v1 here.

• Creates inconsistency across the docs: Other recently-updated pages (e.g., the MCP tools reference) use v2-style endpoints. The Webhooks page, which is a primary integration touchpoint for server-side developers, silently uses v1 as if v2 does not exist.

• Missing guidance on hybrid scenarios: If a developer's backend uses v2 for everything else, they would now have to maintain two API clients — one for v2 and one for v1 subscriber lookups — without any documentation explaining this architectural requirement.

Path A — If v2 has an equivalent customer lookup endpoint: Update the "Syncing Subscription Status" section to reference the v2 endpoint as the primary recommendation, with v1 as a fallback for existing integrations:

We recommend calling the customer lookup endpoint after receiving any webhook so the customer's information is always in the same consistent format:

- **REST API v2 (recommended)**: `GET /projects/{project_id}/customers/{app_user_id}` — [see API v2 docs](/api-v2)

- **REST API v1 (legacy)**: `GET /v1/subscribers/{app_user_id}` — [see API v1 docs](/api-v1#tag/customers)

Path B — If v2 does NOT yet have a customer/subscriber lookup endpoint: Add an explicit callout explaining why v1 is required for this pattern:

Why REST API v1?
The `GET /subscribers` endpoint is currently only available in REST API v1. Even if your integration otherwise uses API v2, you must use the v1 endpoint to fetch full customer subscription details after receiving a webhook. We will update this recommendation when a v2 equivalent is available.

Either path: Also add a brief note at the top of the Webhooks page indicating which API version(s) the examples on the page use, so developers can orient themselves from the start.

1. Navigate to the Configuring the SDK page at https://www.revenuecat.com/docs/getting-started/configuring-sdk
2. Read the info callout immediately after the first paragraph:

   "Using an older SDK (v3.x) View our migration guide to v4.x here. "

3. Note that this callout:
4. References "v3.x" as "an older SDK" — but the current iOS SDK is v5.43.0 (confirmed in the Test Store requirements table at the top of this same page: "iOS 5.43.0, Android 9.9.0…")
5. Links exclusively to /sdk-guides/ios-native-3x-to-4x-migration, which is an iOS-only guide — despite the Configuring SDK page being a cross-platform page covering iOS, Android, Flutter, React Native, etc.
6. Says nothing about the v4.x→v5.x migration, which is the CURRENT major migration and includes breaking changes (StoreKit 2, renamed PurchasesAreCompletedBy enum, new minimum OS targets, etc.)
7. Now navigate to the iOS Installation page at https://www.revenuecat.com/docs/getting-started/installation/ios
8. Read the info callout near the top:

   "> Already have 4.x installed? View our migration guide to 5.x → "

9. Observe: the iOS Installation page correctly points developers to the current, relevant migration (4.x→5.x). The Configuring SDK page points to a two-generations-old migration (3.x→4.x) and is silent on the current migration.

Both the iOS Installation page and the Configuring SDK page should guide developers to the current, relevant migration path. Since the iOS SDK is now at v5.43.0 (v5.x is current), a developer visiting the Configuring SDK page — whether they are on v3.x or v4.x — needs to know the full migration path. At minimum, the configuring-sdk page should match the iOS installation page's callout (v4.x→v5.x). Cross-platform developers on Android, Flutter, or React Native who visit the Configuring SDK page expecting guidance when "using an older SDK" need platform-appropriate migration links, not an iOS-only link.

The Configuring SDK page at https://www.revenuecat.com/docs/getting-started/configuring-sdk contains:

"Using an older SDK (v3.x) View our migration guide to v4.x here. "

• Stale: The iOS SDK is at v5.43.0, making the 3.x→4.x guide two major versions out of date.

• Inconsistent: The iOS Installation page (https://www.revenuecat.com/docs/getting-started/installation/ios) has a current "Already have 4.x? Migrate to 5.x" callout; the Configuring SDK page does not.

• iOS-only: The link goes to ios-native-3x-to-4x-migration — an iOS-specific page — even though the Configuring SDK page applies to all platforms. Developers on Android, Flutter, or React Native would receive no useful migration guidance.

• Misleading: The v4.x→v5.x migration introduced significant breaking changes (StoreKit 2 by default, renamed Observer Mode to PurchasesAreCompletedBy, new minimum OS/platform targets, removed .with(usesStoreKit2IfAvailable:), new trusted entitlements defaults). A developer on v4.x who only reads the configuring-sdk page would have no idea this migration even exists.

1. Remove the stale v3.x callout from the Configuring SDK page (the v3.x SDK is now two major versions old; the small fraction of developers still on it should be handled at the Installation page level).

2. Add a current migration callout matching what is already on the iOS Installation page:

Upgrading from an older SDK?

- iOS: If you have v4.x installed, see the [iOS 4.x → 5.x Migration Guide](/sdk-guides/ios-native-4x-to-5x-migration)

- Android: If you have v7.x or earlier, see the [Android Migration Guides](/sdk-guides/android-migration-guides-index)

- For other platforms, see [Migration Guides](/sdk-guides)

1. Alternatively, consider consolidating migration callouts into a single "SDK Migration Guides" index page and linking to it from both the Installation and Configuring SDK pages, so both pages stay in sync automatically.

1. Navigate to the Configuring the SDK page at https://www.revenuecat.com/docs/getting-started/configuring-sdk
2. Scroll to the "Additional Configuration" section.
3. Read the bullet for the Purchases Completed By option:

   "Purchases Completed By (optional): A boolean value to tell RevenueCat not to complete purchases. Only set purchase completion to your app if you have your own code handling purchases."

4. Click the linked page (/migrating-to-revenuecat/sdk-or-not/finishing-transactions).
5. On the Finishing Transactions page, read: "you might need to set the SDK configuration option that your app will complete the purchases itself (configuration option purchasesAreCompletedBy, see code below)."
6. Also read the iOS 4.x→5.x migration guide at https://www.revenuecat.com/docs/sdk-guides/ios-native-4x-to-5x-migration, which explicitly states: "### Observer Mode is now PurchasesAreCompletedBy — Version 5.0 of the SDK... replaces it with PurchasesAreCompletedBy (either RevenueCat or your app)."
7. Notice the contradiction: the configuring-sdk page says the option is "A boolean value," but the actual SDK API exposes PurchasesAreCompletedBy as a named enum (.revenueCat or .myApp(StoreKitVersion) on iOS; .myApp on Android), not a boolean.

The "Purchases Completed By" option description should accurately reflect its type and accepted values. Developers reading the "Additional Configuration" section of the Configuring SDK page expect to learn the correct type and meaning so they can configure the option without further research. An accurate description would read something like: "Purchases Completed By (optional): An enum value specifying who should complete (finalize) purchases — either RevenueCat (default) or MyApp. Set this to MyApp if your existing code already finalizes transactions using StoreKit/Google Play Billing. See Using the SDK with your own IAP Code for details."

The Configuring SDK page at https://www.revenuecat.com/docs/getting-started/configuring-sdk states:

"Purchases Completed By (optional): A boolean value to tell RevenueCat not to complete purchases. Only set purchase completion to your app if you have your own code handling purchases."

Two things are wrong: 1. Type is wrong: purchasesAreCompletedBy is NOT a boolean. It is a PurchasesAreCompletedBy enum. On iOS (SDK v5+), valid values are .revenueCat (default) and .myApp(StoreKitVersion.storeKit1) / .myApp(StoreKitVersion.storeKit2). The enum name and its valid values are confirmed in the iOS 4.x→5.x migration guide. 2. Description is ambiguous: "A boolean value to tell RevenueCat not to complete purchases" implies only one direction of the option (turning it off) and doesn't explain what values exist or what the default behavior is.

By contrast, the linked Finishing Transactions page correctly refers to the option by its real name (purchasesAreCompletedBy) and shows actual code examples, but no warning or correction appears on the Configuring SDK page itself.

Replace the incorrect bullet on the Configuring SDK page's "Additional Configuration" section with:

- **Purchases Completed By (optional)**: A `PurchasesAreCompletedBy` enum value that controls which party finalizes (completes) in-app purchase transactions.
  - `RevenueCat` (default) — RevenueCat's SDK calls `finishTransaction()` / `acknowledgePurchase()` automatically.
  - `MyApp` — Your own purchase code is responsible for finalizing transactions. On iOS, you must also specify the StoreKit version your app uses (`StoreKitVersion.storeKit1` or `StoreKitVersion.storeKit2`).

  Only change this from the default if you have pre-existing IAP code that already finalizes transactions. See [Using the SDK with your own IAP code](/migrating-to-revenuecat/sdk-or-not/finishing-transactions).

Additionally, since the iOS SDK v5 renamed "Observer Mode" to PurchasesAreCompletedBy, the note should cross-link the iOS 4.x→5.x migration guide for developers upgrading from v4.

1. Navigate to https://www.revenuecat.com/docs/test-and-launch/errors (or fetch the markdown at https://www.revenuecat.com/docs/test-and-launch/errors.md)
2. Locate the "Legend" section. It defines exactly 4 icons:
3. 👽 (RC alien) = Error generated from RevenueCat
4. 🍎 (Apple) = Error generated from Apple
5. 🤖 (Robot) = Error generated from Google
6. 📦 (Package) = Error generated from Amazon
7. Scroll to the "Error codes common to all methods" section and find:
8. #### 🤷 SIGNATURE_VERIFICATION_FAILED
9. #### 🤷 UNKNOWN
10. Search the Legend table for the 🤷 (person shrugging) icon — it does not appear.
11. Try to determine which system or layer generates a SIGNATURE_VERIFICATION_FAILED error based solely on the Legend — it is impossible because the 🤷 icon is undefined.
12. Compare with nearby errors: INVALID_APP_USER_ID uses 👽 (RevenueCat), STORE_PROBLEM uses 🍎🤖📦 (Apple/Google/Amazon) — all properly cross-referenced to the Legend. Only 🤷 is orphaned.

The Legend section at the top of the Error Handling page states its purpose clearly: "When debugging errors, it's important to consider whether the error was thrown by RevenueCat, Apple, or Google. This can help you pinpoint where to look for a resolution." Every icon used in error headings throughout the page should appear in this Legend table with a clear description. Developers expect to be able to look up any error's icon in the Legend and immediately understand whether to file a bug with RevenueCat, check their App Store/Play Store configuration, or investigate Amazon credentials. For the 🤷 icon, they should find an entry such as "🤷 — Error origin is ambiguous; may indicate tampering, SDK integrity issues, or an error that cannot be attributed to a specific platform."

The Legend table at https://www.revenuecat.com/docs/test-and-launch/errors defines only 4 icons (RevenueCat 👽, Apple 🍎, Google 🤖, Amazon 📦). Two error codes in the same page use a fifth icon — 🤷 (person shrugging) — that has no Legend entry:

• SIGNATURE_VERIFICATION_FAILED: "Indicates that the SDK detected a request was tampered." Resolution points to Trusted Entitlements docs.

• UNKNOWN: "Indicates an unknown error occurred." Resolution is "Help us fix it" with a jobs link. A developer encountering one of these errors in their logs will look up the icon in the Legend, find nothing, and be unable to determine whether this is a RevenueCat server issue, a network tampering issue on their infrastructure, or a third-party store problem. The ambiguity is especially problematic for SIGNATURE_VERIFICATION_FAILED, which is a security-critical error that developers need to triage quickly. The icon choice (🤷 = "I don't know") may be intentional for UNKNOWN, but SIGNATURE_VERIFICATION_FAILED is actually well-understood — it's detected by the RevenueCat SDK — suggesting its icon should be 👽 instead, or the 🤷 icon should be explicitly defined in the Legend as "RevenueCat SDK — origin of the underlying cause is indeterminate."

Option A — Add the 🤷 icon to the Legend table: | 🤷 | Error origin is unknown or ambiguous — may come from any layer |

With this addition, developers can at least understand the icon is intentional.

Option B — Re-icon the affected errors more accurately:

• SIGNATURE_VERIFICATION_FAILED: Change icon to 👽 (RevenueCat), since the SDK is detecting the tamper condition. Update the Legend if 👽 is meant only for pure server errors.

• UNKNOWN: Keep 🤷 but add it to the Legend as "Unknown origin — indeterminate error source."

Option C — Combine both: add 🤷 to the Legend AND re-evaluate whether SIGNATURE_VERIFICATION_FAILED should be 👽 (RevenueCat detects it) or remain 🤷 (the tampering source is external). Document the decision either way.

Regardless of which option is chosen, audit all error headings to verify every icon they use appears in the Legend — a simple grep/lint check could prevent this class of issue from recurring.

1. Read https://www.revenuecat.com/docs/llms.txt — note the explicit claim: "Markdown mirrors include descriptive fallbacks for interactive content and link back to embedded media."
2. Navigate to the LLM-optimized markdown mirror of the Sample Events page: https://www.revenuecat.com/docs/integrations/webhooks/sample-events.md
3. Observe the full text-content of the page:
4. "These are some representative samples of webhooks you might receive from RevenueCat. Keep in mind that webhooks can include additional fields to what's shown here."
5. "Interactive content is available in the web version of this doc."
6. "Interactive content is available in the web version of this doc."
7. "Here are some events you will see regarding trials:"
8. "Interactive content is available in the web version of this doc."
9. "When a Web Billing invoices is issued, a INVOICE_ISSUANCE webhook is created:"
10. "Interactive content is available in the web version of this doc."
11. "In cases when the stores are down, RevenueCat may grant a temporary entitlement..."
12. "Interactive content is available in the web version of this doc."
13. [etc. — every single sample payload is hidden]
14. Search the page for any {, "event_type", "app_user_id", or any JSON content — there is none.
15. Now use the RevenueCat MCP server or ask an LLM assistant using docs context to "show me an example INITIAL_PURCHASE webhook payload" — the AI has nothing to reference from this page.
16. Try to write a webhook handler schema validator against the sample events — impossible without the actual JSON.

The "Sample Events" page is the primary reference for webhook implementors needing concrete JSON payloads to: (a) understand actual field structures, (b) write schema validators, (c) build test harnesses, (d) understand platform-specific payload differences, and (e) prompt AI assistants to generate webhook handler code. Developers — and LLM tools — expect the markdown mirror to contain the actual sample JSON objects for INITIAL_PURCHASE, RENEWAL, CANCELLATION, EXPIRATION, BILLING_ISSUE, TRIAL_STARTED, INVOICE_ISSUANCE, VIRTUAL_CURRENCY_TRANSACTION, and EXPERIMENT_ENROLLMENT events. The llms.txt explicitly promises "descriptive fallbacks for interactive content," which at minimum should mean the JSON is inlined in the markdown as code blocks.

The page at https://www.revenuecat.com/docs/integrations/webhooks/sample-events.md contains zero JSON payloads. Every single sample event — covering at least 7 distinct event types and their platform variants — is replaced with only the string "Interactive content is available in the web version of this doc." This is not a "descriptive fallback" as promised in llms.txt; it is an empty placeholder. The web version of the page renders the samples through interactive JavaScript tabs (Docusaurus tab components), which are not serialized to the markdown mirror. This means the entire informational value of the Sample Events page is inaccessible to: the RevenueCat MCP server (which reads docs in markdown form), AI coding assistants prompted with RevenueCat docs context, developers accessing docs programmatically, and any toolchain using the officially advertised .md endpoint. The Event Types and Fields page (https://www.revenuecat.com/docs/integrations/webhooks/event-types-and-fields.md) documents field names in a table but provides no concrete JSON examples, making Sample Events the only source of truth for actual payload shape.

1. Inline the JSON payload for each event type directly in the markdown source as fenced code blocks (json ...). This is the most robust fix: the samples will be present in both the web UI and the markdown mirror without needing JavaScript.
2. If keeping the interactive tabs for UX reasons, use Docusaurus's details or static code blocks as the fallback rendered inside the MDX file, so the .md mirror endpoint includes the JSON even when JavaScript is unavailable.
3. At minimum, ensure the llms.txt claim ("Markdown mirrors include descriptive fallbacks for interactive content") is honored: include at least one canonical JSON example per event type in a static code block directly beneath each tab group.
4. Consider adding a direct link from the Event Types and Fields page to a raw JSON schema or downloadable Postman collection so webhook implementors have a machine-readable reference independent of page rendering.

1. Navigate to https://www.revenuecat.com/docs/getting-started/configuring-sdk
2. Scroll to the "Additional Configuration" section
3. Read the bullet: "Purchases Completed By (optional): A boolean value to tell RevenueCat not to complete purchases. Only set purchase completion to your app if you have your own code handling purchases."
4. Now open an iOS project and add RevenueCat SDK v5.x (currently v5.43.0+, the minimum required for Test Store per the same page)
5. Attempt to configure purchasesAreCompletedBy with a boolean true or false — the Swift compiler rejects it
6. Read the iOS 4.x→5.x migration guide at https://www.revenuecat.com/docs/sdk-guides/ios-native-4x-to-5x-migration which says: "Version 5.0 of the SDK deprecates the term 'Observer Mode' (and the APIs where this term was used), and replaces it with PurchasesAreCompletedBy (either RevenueCat or your app)"
7. Note the contradiction: the overview page says "boolean value", the migration guide says it's now an enum called PurchasesAreCompletedBy with cases .revenueCat and .myApp(storeKitVersion:)

The "Configuring the SDK" page is the primary onboarding reference. Developers expect accurate type information for each configuration option. For purchasesAreCompletedBy, they expect to be told it is a typed enum (PurchasesAreCompletedBy) with two cases: .revenueCat (default, RevenueCat completes purchases) and .myApp(storeKitVersion:) (your app completes purchases, with .storeKit1 or .storeKit2 as the storeKitVersion). A boolean-style API existed in iOS SDK v4.x (observerMode: Bool) and is now deprecated; iOS SDK v5.x (the minimum required for Test Store) requires the enum form.

The "Additional Configuration" section of https://www.revenuecat.com/docs/getting-started/configuring-sdk reads: "Purchases Completed By (optional): A boolean value to tell RevenueCat not to complete purchases." The word "boolean" is a leftover from the iOS SDK 4.x observerMode: Bool API. In iOS SDK 5.x (current), the parameter is the PurchasesAreCompletedBy enum. The page makes no distinction between platform SDK versions, and the same page explicitly requires iOS 5.43.0+ for Test Store — so every developer following this page is on a version where "boolean" is wrong. The iOS migration guide at https://www.revenuecat.com/docs/sdk-guides/ios-native-4x-to-5x-migration directly contradicts this by stating the boolean API was deprecated and replaced with the enum in v5.0. The finishing-transactions page (https://www.revenuecat.com/docs/migrating-to-revenuecat/sdk-or-not/finishing-transactions) further notes "Older versions of the SDK (currently including the iOS and cross-platform SDKs) still refer to this terminology" — itself a confusing sentence since the iOS SDK 5.x migration guide states the old terminology was replaced.

1. Update the bullet on the configuring-sdk page from "A boolean value to tell RevenueCat not to complete purchases" to: "Controls which party completes (finishes/acknowledges) purchases. Accepts: .revenueCat (default — RevenueCat handles it) or .myApp(storeKitVersion:) (your app handles it; iOS 5.x+ only). On older SDK versions this was a boolean observerMode flag — see the iOS 4.x→5.x migration guide for details."
2. Add a platform callout: the type and valid values differ by SDK version and platform (iOS uses the PurchasesAreCompletedBy enum in SDK 5.x; Android uses observer mode flags). Link to the finishing-transactions page for the platform-specific code examples.
3. Fix the confusing sentence in finishing-transactions that says "Older versions of the SDK (currently including the iOS and cross-platform SDKs) still refer to this terminology" — this directly contradicts the iOS 5.x migration guide. Either update it to be accurate ("The Android SDK and cross-platform SDKs still use observer mode terminology; iOS SDK 5.x+ uses PurchasesAreCompletedBy") or remove it.

1. Read the RevenueCat MCP Server overview at https://www.revenuecat.com/docs/tools/mcp
2. Note the stated capabilities: "Product Management: Manage subscription products and in-app purchases"
3. Navigate to the Tools Reference at https://www.revenuecat.com/docs/tools/mcp/tools-reference
4. Find all product-related tools: only mcp_RC_list_products and mcp_RC_create_product are documented
5. Search the page for get_product, update_product, delete_product — none exist
6. As an AI agent, try to fix a product you created with the wrong store_identifier — there is no MCP tool to update or delete it
7. Compare with App Management in the same page: mcp_RC_list_apps, mcp_RC_get_app, mcp_RC_create_app, mcp_RC_update_app, mcp_RC_delete_app — full CRUD
8. Also compare Entitlement Management: 8 operations (list, get, create, update, delete, get_products_from, attach, detach) — full CRUD
9. Similarly, find that Offerings (3 tools: list, create, update — missing get/delete) and Packages (4 tools: list, create, attach, detach — missing get/update/delete) also have incomplete operations with no documentation of the gap

The MCP overview says "Product Management: Manage subscription products and in-app purchases." The word "manage" strongly implies full lifecycle control: creating, reading, updating, and deleting. A developer (or AI agent) following the overview would expect to be able to rectify mistakes — for example, deleting a product created with a wrong store_identifier, or updating a product's display_name. They would expect parity with what App Management and Entitlement Management already offer. If product update/delete operations are truly unsupported by the underlying REST API, the documentation should say so explicitly and qualify "manage" accordingly.

The Tools Reference at https://www.revenuecat.com/docs/tools/mcp/tools-reference documents exactly 26 MCP tools. Of these, Product Management covers only 2 operations:

• mcp_RC_list_products — list all products in a project

• mcp_RC_create_product — create a new product

There is no mcp_RC_get_product, mcp_RC_update_product, or mcp_RC_delete_product. Similarly, Offering Management has no mcp_RC_get_offering or mcp_RC_delete_offering; Package Management has no mcp_RC_get_package, mcp_RC_update_package, or mcp_RC_delete_package. By contrast, App Management exposes a full 5-operation CRUD and Entitlement Management exposes 8 operations. The Usage Examples page (https://www.revenuecat.com/docs/tools/mcp/usage-examples) shows examples for creating products and offerings but conspicuously has zero examples for updating or deleting them, reinforcing the gap. An AI assistant told to "remove the product I created by mistake" would be unable to do so using only documented MCP tools.

Path 1 — If the REST API v2 DOES support GET/DELETE/PATCH for products, offerings, and packages: Add the missing MCP tools to both the server implementation and the Tools Reference docs:

• mcp_RC_get_product (project_id, product_id)

• mcp_RC_update_product (project_id, product_id, display_name)

• mcp_RC_delete_product (project_id, product_id)

• mcp_RC_get_offering (project_id, offering_id)

• mcp_RC_delete_offering (project_id, offering_id)

• mcp_RC_get_package, mcp_RC_update_package, mcp_RC_delete_package

Path 2 — If the REST API v2 does NOT support these operations: 1. Change the overview bullet from "Product Management: Manage subscription products" to "Product Management: Create and list subscription products (update/delete not currently supported)" 2. Add a "Limitations" section to the Tools Reference page listing which resource types lack full CRUD and why (e.g., "Products cannot be deleted via API; use the dashboard instead") 3. Add a warning to the Usage Examples batch-operation example: "Note: If you create a product with incorrect parameters, it must be deleted manually from the dashboard as there is no MCP tool to delete products."

1. Navigate to https://www.revenuecat.com/docs/tools/paywalls/displaying-paywalls
2. Scroll to the "React Native" → "Listeners" section and read the available callbacks for RevenueCatUI.Paywall:
3. onPurchaseStarted
4. onPurchaseCompleted
5. onPurchaseError
6. onPurchaseCancelled ← present
7. onRestoreStarted ← present
8. onRestoreCompleted
9. onRestoreError
10. onDismiss (8 callbacks total)
11. Scroll down to the "Kotlin Multiplatform" → "Listeners" section and read the callbacks for Paywall:
12. onPurchaseStarted, onPurchaseCompleted, onPurchaseError, onPurchaseCancelled, onRestoreStarted, onRestoreCompleted, onRestoreError (7 callbacks — also includes onPurchaseCancelled and onRestoreStarted)
13. Scroll to the "Flutter" → "Listeners" section and read the callbacks for PaywallView:
14. onPurchaseStarted
15. onPurchaseCompleted
16. onPurchaseError
17. onRestoreCompleted
18. onRestoreError
19. onDismiss (6 callbacks — onPurchaseCancelled and onRestoreStarted are absent with zero explanation)
20. Search the page for any note about Flutter not supporting onPurchaseCancelled or onRestoreStarted — none exists.
21. Try to implement purchase-cancellation tracking in a Flutter paywall using the documented callbacks — there is no documented callback for this event.

Developers expect the listener callback tables for each platform to either (a) list all the same callbacks, since Flutter and React Native both wrap the same underlying native iOS/Android SDK, or (b) clearly document WHY Flutter's list is shorter — e.g., a note such as "⚠️ onPurchaseCancelled and onRestoreStarted are not yet supported in Flutter (see GitHub issue #XXXX)". Without such a note, developers cannot distinguish between a feature gap (the SDK doesn't emit these events) and a documentation gap (the SDK does emit them but they're not listed). This is especially confusing because both React Native (a peer cross-platform SDK) and KMP include onPurchaseCancelled.

The "Displaying Paywalls" page at https://www.revenuecat.com/docs/tools/paywalls/displaying-paywalls lists 8 listener callbacks for React Native's RevenueCatUI.Paywall and 7 for KMP's Paywall, but only 6 for Flutter's PaywallView. The two callbacks absent in Flutter — onPurchaseCancelled and onRestoreStarted — are present in both React Native and KMP with no cross-platform note, no "not yet supported" callout, and no link to a tracking issue. Flutter also phrases its list as "Available listeners at this time are:" — identical phrasing to the React Native section, which offers no hint to the reader that these two critical lifecycle events are absent. A Flutter developer building a purchase analytics layer would have no way of knowing that user-initiated purchase cancellations cannot be caught with the documented PaywallView listeners.

Option A — If Flutter genuinely does NOT support onPurchaseCancelled / onRestoreStarted in PaywallView: Add a warning callout immediately after the Flutter listener list:

Flutter PaywallView limitations
`onPurchaseCancelled` and `onRestoreStarted` are not yet supported in Flutter's `PaywallView`. To detect purchase cancellations, check whether `onPurchaseCompleted` was NOT called after `onPurchaseStarted`. Track this issue: [purchases-flutter#XXXX].

Apply the same treatment to KMP for the missing onDismiss callback.

Option B — If these callbacks DO exist in the Flutter SDK but are undocumented: Add onPurchaseCancelled and onRestoreStarted to the Flutter listener table.

Either way, add a platform comparison table at the top of the Listeners section showing which callbacks are available per platform, so developers switching between platforms can immediately spot the differences rather than discovering them at runtime.

1. Navigate to the Paywalls overview at https://www.revenuecat.com/docs/tools/paywalls
2. Read the "Required SDK Versions" table under "Limitations":
3. purchases-ios: 5.27.1 and up
4. purchases-android: 8.19.2 and up
5. react-native-purchases: 8.11.3 and up
6. purchases-flutter: 8.10.1 and up
7. purchases-kmp: 1.8.2+13.35.0 and up
8. purchases-capacitor: 10.3.3 and up
9. Click "Install the RevenueCat UI SDK" to go to https://www.revenuecat.com/docs/tools/paywalls/installation
10. Read the "Supported SDK versions" table on that page:
11. purchases-ios: 5.16.0 and up ← 11 minor versions behind
12. purchases-android: 8.12.2 and up ← 7 minor versions behind
13. react-native-purchases: 8.6.1 and up ← 5 minor versions behind
14. purchases-flutter: 8.5.0 and up ← 5 minor versions behind
15. purchases-kmp: 1.5.1+13.18.1 and up ← significantly behind
16. purchases-capacitor: 10.3.1 and up ← 2 patch versions behind
17. Also notice the body text of the iOS SPM installation instructions still says "Make sure version is at least 5.16.0" (matching the stale table on the installation page, contradicting the 5.27.1 on the overview page)
18. Also note the two pages list different SDKs: installation page adds "purchases-js: 0.19.0 and up" (not on overview); overview lists "cordova-plugin-purchases: Not supported" (not on installation page); overview lists "purchases-unity: RevenueCatUI package required" (no version) while installation page lists "purchases-unity-ui: 8.4.0 and up"

A developer reading either the Paywalls Overview or the Paywalls Installation page should see the same, up-to-date minimum SDK version requirements. Since the Paywalls Installation page is the definitive "how to install" guide that developers follow step by step, its version table — and the specific version mentioned in the iOS SPM step-by-step instructions — should match the overview page. This is especially important because developers who install a version lower than 5.27.1 for iOS (e.g., 5.16.0 as instructed by the Installation page) may miss critical paywall features and fixes introduced between those versions.

The two pages show contradictory minimum SDK versions across every SDK: • iOS: overview says 5.27.1+, installation page says 5.16.0+ (with the in-body SPM instructions also saying 5.16.0+) • Android: overview says 8.19.2+, installation page says 8.12.2+ • React Native: overview says 8.11.3+, installation page says 8.6.1+ • Flutter: overview says 8.10.1+, installation page says 8.5.0+ • KMP: overview says 1.8.2+13.35.0, installation page says 1.5.1+13.18.1+ • Capacitor: overview says 10.3.3+, installation page says 10.3.1+ Additionally, the two pages list different sets of SDKs with no explanation: the installation page mentions purchases-js (web) and purchases-unity-ui while the overview page lists cordova-plugin-purchases as "Not supported" — which is not mentioned at all in the installation guide. A developer following the installation page instructions and pinning to 5.16.0 for iOS would be on a version 11 minor releases behind the "recommended minimum" on the overview page.

1. Designate one source of truth for the minimum SDK version table — the Paywalls Installation page is the natural home since developers go there to install.
2. Update the Installation page's version table (and the step-by-step iOS SPM instruction text that says "at least 5.16.0") to match the higher versions currently on the Overview page: iOS 5.27.1+, Android 8.19.2+, React Native 8.11.3+, Flutter 8.10.1+, KMP 1.8.2+13.35.0+, Capacitor 10.3.3+.
3. On the Paywalls Overview page, replace the version table with a short note saying "For minimum SDK version requirements, see the Installation page" — or keep the table but link it to the Installation page and ensure it stays in sync.
4. Consolidate the SDK rows: add purchases-js and the Cordova "Not supported" row to the Installation page; give purchases-unity-ui a concrete version number on the Overview page.
5. Consider adding a nightly/CI check that compares version numbers across these two pages to prevent future drift.

Open Displaying Products page. Click the "configured Offerings" link in the opening paragraph.

Link to current Offerings documentation

Links to an older version of the Offerings page

Update link to current Offerings documentation URL

Read Authentication page. Try to understand which key type to use for MCP server vs REST API vs SDK.

Clear table showing which auth method applies to each integration point

Only documents Bearer token for REST API v2. MCP and SDK auth are on separate pages with no cross-reference.

Add comparison table: API key types (public vs secret), where each is used (SDK, REST, MCP), and security implications

Navigate to Getting Subscription Status page. Click REST API link. Lands on legacy v1 docs with no redirect or note about v2.

Link should point to v2 REST API or note that v2 is the current version

Links to legacy v1 docs at docs.revenuecat.com

Update link to point to v2 REST API reference and add deprecation note for v1