> For the complete documentation index, see [llms.txt](https://developers-apps-in-toss.toss.im/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developers-apps-in-toss.toss.im/documentation/api-and-sdk-en/common/growth/review.md).

# Review request

`requestReview`is an API that lets you request users to write a review in a mini app.

Android's `In-App Review` API, and iOS's `SKStoreReviewController`work in a similar direction, helping users leave a review naturally at the point when they have fully experienced the value of the service.

**Signature**

```typescript
function requestReview(): Promise<void>;
```

### When should I call it?

`requestReview`It is recommended to call it when users have fully felt the value of the app.

For example, the following moments are appropriate.

* Right after successfully completing a core task
* Right after achieving a goal or earning a reward
* A moment when satisfaction is expected to be high after repeated use

Calling it at this point lets users leave a review while they are having a positive experience, so you can expect better review quality.

### How it works

`requestReview`When requestReview is called, the review flow may appear to the user in the following order.

1. The star rating input screen appears first.
2. When the user **selects 4 stars or more**, the text review input screen is shown additionally.
3. When the user **When selecting 3 stars or less**, only the star rating is collected without a text review.

### Usage guide

{% hint style="info" %}
**It does not always appear even when called**

`requestReview`Even if you call requestReview, the review input screen is not always shown.

Whether it is shown is determined according to Apps in Toss internal policies, taking user fatigue into account. Therefore, you should not design your UX flow with the assumption that the review screen will definitely appear.
{% endhint %}

* Please call it only when the user feels satisfied.
* Do not call it repeatedly within the same session.
* Please design it so that the user flow continues naturally even if the review request is not shown.
* Do not create a flow where you move to the next screen or grant a reward based on whether the review request is shown.
* Since it may look like nothing happens after the call, separate it from flows that are functionally required.

**Example**

**Requesting a review after completing a core action**

{% tabs %}
{% tab title="js" %}

```js
import { requestReview } from '@apps-in-toss/web-framework';

async function handleTaskCompleted() {
  await saveMissionResult();

  try {
    await requestReview();
  } catch (error) {
    console.error('Review request failed:', error);
  }
}
```

{% endtab %}

{% tab title="React" %}

```tsx
import { requestReview } from '@apps-in-toss/web-framework';

function CompleteButton() {
  const handleComplete = async () => {
    await completeGoal();

    try {
      await requestReview();
    } catch (error) {
      console.error('Review request failed:', error);
    }
  };

  return <button onClick={handleComplete}>Complete</button>;
}
```

{% endtab %}

{% tab title="React Native" %}

```tsx
import { Button, Alert } from 'react-native';
import { requestReview } from '@apps-in-toss/framework';

function CompleteButton() {
  const handleComplete = async () => {
    await completeGoal();

    try {
      await requestReview();
    } catch (error) {
      Alert.alert('Review request failed', String(error));
    }
  };

  return <Button title="Complete" onPress={handleComplete} />;
}
```

{% endtab %}
{% endtabs %}

### Checking reviews

In the console's 'Ratings and Reviews' menu, `requestReview`you can view both reviews collected through requestReview and reviews written through 'Leave a Review' in the navigation bar.

### Frequently asked questions

<details>

<summary>What happens if you call it for a user who has already left a review?</summary>

For users who have already left a star rating or review, the review UI is not shown and they are taken past it.

</details>

<details>

<summary>Is it the same for users who wrote a review through the navigation bar's Leave a Review?</summary>

Yes. For users who left a review through the navigation bar's Leave a Review, the UI is also not shown.

</details>

<details>

<summary>When does the Promise resolve?</summary>

It resolves when the review request is completed. In practice, `the Promise`does not need to be awaited.

</details>

<details>

<summary>Does it resolve even if it is blocked by the fatigue policy?</summary>

Yes. It resolves normally even when the review UI is not shown due to the fatigue policy.

</details>

<details>

<summary>Can you distinguish between review completion and dismiss?</summary>

No. It is intentionally not provided so that functionality or behavior cannot differ depending on whether a review was written.

</details>

<details>

<summary>Can I check a specific user's review status?</summary>

No. There is currently no feature provided by the SDK or console API to check whether a specific user has written a review.

</details>

<details>

<summary>Is there a plan to provide an API like getReviewStatus()?</summary>

No. There is no plan to provide one, for the same reason that review results are not returned.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://developers-apps-in-toss.toss.im/documentation/api-and-sdk-en/common/growth/review.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.