Searched, saw the right answer, and answered against it. Unaided belief: wrong. With tools: searched on 100% of samples, answered correctly on 0%.
247 3. **Update your API integration**: Update your Claimable Sandbox API integration to use `app_channel: public` instead of `app_channel: testing`.
248 #### Warning
249 Use `app_channel: testing` only for testing. This channel has restrictions. For example, you can make at most 25 live mode installs on the testing channel. Don’t take your integration live with the testing channel.
| WRONG | **Zero.** A Stripe app with `app_channel` set to `testing` can only be installed in test mode. To allow live-mode installs, you must publish or promote the app to the live channel. The answer says zero live mode installs, but the source states that up to 25 live mode installs are allowed on the testing channel. |
| WRONG | With `app_channel` set to `testing`, you can make **up to 5 live-mode installs**. For broader production distribution, switch `app_channel` to `public`. The answer says up to 5 live-mode installs, but the source states at most 25. Stripe app_channel testing live mode installs how many installs5 results
results as cached 2026-09-04T00:49 site:docs.stripe.com app_channel testing installs live mode Stripe apps manifest2 results
results as cached 2026-09-04T00:49 opened 2 pages |
Asserted a confident answer to a question it had no basis to answer. Unaided belief: wrong. With tools: searched on 100% of samples, answered correctly on 0%.
| WRONG | The `prefill.country` parameter supports these markets:
- **United States** (`US`)
- **Canada** (`CA`)
- **United Kingdom** (`GB`)
- **European Union** (`EU`)
- **Australia** (`AU`)
- **New Zealand** (`NZ`) The answer confidently lists specific supported countries and regions despite the source material not providing that information. |
| WRONG | According to Stripe’s documentation, `prefill.country` supports claimable sandbox creation in:
- Argentina (`AR`)
- Australia (`AU`)
- Austria (`AT`)
- Belgium (`BE`)
- Brazil (`BR`)
- Bulgaria (`BG`)
- Canada (`CA`)
- Croatia (`HR`)
- Cyprus (`CY`)
- Czech Republic (`CZ`)
- Denmark (`DK`)
- Estonia (`EE`)
- Finland (`FI`)
- France (`FR`)
- Germany (`DE`)
- Greece (`GR`)
- Hong Kong (`HK`)
- Hungary (`HU`)
- Ireland (`IE`)
- Italy (`IT`)
- Japan (`JP`)
- Latvia (`LV`)
- Lithuania (`LT`)
- Luxembourg (`LU`)
- Malaysia (`MY`)
- Malta (`MT`)
- Mexico (`MX`)
- Netherlands (`NL`)
- New Zealand (`NZ`)
- Norway (`NO`)
- Poland (`PL`)
- Portugal (`PT`)
- Romania (`RO`)
- Singapore (`SG`)
- Slovakia (`SK`)
- Slovenia (`SI`)
- Spain (`ES`)
- Sweden (`SE`)
- Switzerland (`CH`)
- Thailand (`TH`)
- United Arab Emirates (`AE`)
- United Kingdom (`GB`)
- United States (`US`)
- Uruguay (`UY`)
Pass the two-letter ISO country code, for example:
```json
{
"prefill": {
"country": "US"
}
}
```
Availability can change, so Stripe’s [country availability table](https://docs.stripe.com/sandboxes/claimable-sandboxes#availability) is the authoritative source. The answer confidently provides a specific country list despite the source material not supplying that information. "claimable sandboxes" "prefill.country"1 result
results as cached 2026-09-04T00:49 site:docs.stripe.com/sandboxes/claimable-sandboxes "United States" "country availability"1 result
results as cached 2026-09-04T00:49 opened 1 page
|
Asserted a confident answer to a question it had no basis to answer. Unaided belief: wrong. With tools: searched on 100% of samples, answered correctly on 0%.
| WRONG | Bizbot doesn’t receive any special allowance. Claimable Sandbox creation is subject to Stripe’s ordinary API protections:
- **Rate limit:** generally **100 requests per second in live mode** and **25 requests per second in sandbox/test mode**.
- **Concurrency:** Stripe’s default concurrency limiter is **10 simultaneous requests**.
- **Claimable-Sandbox-specific quota:** the Bizbot example does **not define an additional per-user, per-platform, or daily creation quota**.
- Requests above the applicable limits can be throttled with a `429` response, so the integration should use exponential backoff and avoid creating sandboxes in an unbounded parallel burst.
The example’s “claimable” behavior—such as a sandbox being claimable only once or expiring—is a lifecycle rule, not an additional API rate or concurrency limit. The answer confidently invents specific rate, concurrency, and quota details that the source material does not establish. |
| WRONG | For Bizbot, Stripe documents the following applicable limits:
- **Global API rate limit:** Because the API call is made with Bizbot’s **managed app sandbox secret key**, it is a sandbox-mode request. Stripe’s general limit is **25 requests per second in sandbox mode**. Individual endpoints can have lower limits unless Stripe specifies otherwise.
- **Testing-channel quota:** While using `app_channel: testing`, the integration can make **at most 25 live-mode installs**. This is a testing restriction, not a stated limit of 25 claimable-sandbox creation requests.
- **No published creation quota or concurrency limit:** Stripe’s Claimable Sandboxes guide does **not** specify a separate per-account quota, maximum number of simultaneously creating sandboxes, or maximum concurrent `POST /v2/core/claimable_sandboxes` requests.
- **Lifecycle limits are not throughput limits:** An unclaimed sandbox expires after **60 days**, and its onboarding link lasts **7 days**. These affect retention and link renewal, not creation rate or concurrency.
Therefore, Bizbot should treat creation as subject to Stripe’s normal API rate limiting—roughly **25 requests/second for sandbox-mode API traffic**—and implement throttling, exponential backoff, and handling for rate-limit responses. Before production, it must use `app_channel: public`; the 25-install testing restriction does not apply in the same way to the public channel, although Stripe may apply account- or feature-specific limits that aren’t publicly documented. The answer confidently asserts specific Stripe limits and behaviors despite the source material not providing the requested information. site:docs.stripe.com "Claimable Sandboxes" Bizbot1 result
results as cached 2026-09-04T00:49 Stripe API claimable sandboxes rate limit5 results
results as cached 2026-09-04T00:49 Stripe Bizbot fictional agent-assisted coding platform Claimable Sandboxes API rate limits quotas concurrency5 results
results as cached 2026-09-04T00:49 site:docs.stripe.com/sandboxes/claimable-sandboxes "25" "limit" OR "concurrent" OR "quota"0 results
results as cached 2026-09-04T00:49 opened 1 page
|
Asserted a confident answer to a question it had no basis to answer. Unaided belief: wrong. With tools: searched on 100% of samples, answered correctly on 0%.
| WRONG | Bizbot can revoke it by deleting the sandbox through Stripe’s Sandbox API before it’s claimed:
```bash
curl -X DELETE "https://api.stripe.com/v1/sandboxes/sandbox_123" \
-u "$STRIPE_SECRET_KEY:"
```
Bizbot should use the `sandbox_...` ID returned when it created the claimable sandbox and ensure that the sandbox is still **unclaimed**. Deleting it invalidates its claim link immediately; the recipient can no longer claim or access it.
Claimed sandboxes generally can’t be deleted this way. If Bizbot does nothing, an unclaimed claimable sandbox is automatically removed when its 60-day expiration is reached. The answer confidently invents a Sandbox API deletion endpoint and related behavior despite the source material not providing this information. |
| WRONG | Bizbot can cancel it through the **Claimable Sandboxes API** before it’s claimed:
```bash
curl -X POST \
https://api.stripe.com/v2/core/claimable_sandboxes/clmsbx_test_123/cancel \
-H "Authorization: Bearer {{STRIPE_APP_SANDBOX_SECRET_KEY}}" \
-H "Stripe-Version: 2026-04-22.preview"
```
Use the claimable sandbox’s ID from the creation response. Cancellation is intended for an **unclaimed** sandbox; once it has been claimed, Bizbot can’t cancel it through this operation. If Bizbot does nothing, Stripe automatically and permanently deletes the unclaimed sandbox after 60 days. The answer provides a specific cancellation API endpoint and behavior despite the source material not answering the question. Stripe Bizbot "unclaimed" "claimable" sandbox 60-day expiration cancel delete0 results
results as cached 2026-09-04T00:49 site:docs.stripe.com Bizbot sandbox claimable 60 days1 result
results as cached 2026-09-04T00:49 opened 1 page
|
Right only because it checked. Unaided, the model gets this wrong. Unaided belief: wrong. With tools: searched on 100% of samples, answered correctly on 100%.
77 | Parameter | Description |
78 | --- | --- |
79 | `app_channel` | An enum with the values `public` or `testing`. When in development, use `testing`. When you launch this feature to your users, use `public`. For details, see [Submit app for review and publish](https://docs.stripe.com/sandboxes/claimable-sandboxes#review-and-publish). |
80 | `enable_mcp_access` | Set this parameter to `true` to prompt Stripe to send you an API key that you can use to communicate with the [Stripe MCP](https://docs.stripe.com/mcp) server. This lets a large language model (LLM) securely operate on your users’ Stripe accounts. |
81 | `onboarding_link_details` | A hash that lets you specify the `refresh_url` that your end user is redirected to if they access an expired onboarding link. This parameter is required when you create a new claimable sandbox. The `refresh_url` must call a method on your server that invokes the Claimable sandboxes renew onboarding link API to renew the onboarding link expiration. |
| WRONG | For a claimable Stripe sandbox, `app_channel` accepts:
- `dashboard`
- `api`
- `cli`
Use the value that corresponds to how the sandbox will be accessed or created. For example:
```bash
-d app_channel=api
```
Stripe may restrict some values depending on the endpoint or your account’s access to the sandbox features. The answer lists `dashboard`, `api`, and `cli`, which conflict with the source's allowed values of `public` and `testing`. |
| CORRECT | You can use these `app_channel` values when creating a Stripe claimable sandbox:
- **`testing`** — Use during development and testing.
- **`public`** — Use after your Stripe App has been reviewed and published for production users.
Example:
```json
{
"app_channel": "testing"
}
```
Stripe cautions that `testing` has restrictions, including a limit of 25 live-mode installs. Switch to `public` before launching. The answer lists both allowed app_channel values, `testing` and `public`, matching the source. Stripe claimable sandbox app_channel values create claimable sandbox5 results
results as cached 2026-09-04T00:49 opened 1 page |
Right only because it checked. Unaided, the model gets this wrong. Unaided belief: wrong. With tools: searched on 100% of samples, answered correctly on 100%.
77 | Parameter | Description |
78 | --- | --- |
79 | `app_channel` | An enum with the values `public` or `testing`. When in development, use `testing`. When you launch this feature to your users, use `public`. For details, see [Submit app for review and publish](https://docs.stripe.com/sandboxes/claimable-sandboxes#review-and-publish). |
80 | `enable_mcp_access` | Set this parameter to `true` to prompt Stripe to send you an API key that you can use to communicate with the [Stripe MCP](https://docs.stripe.com/mcp) server. This lets a large language model (LLM) securely operate on your users’ Stripe accounts. |
81 | `onboarding_link_details` | A hash that lets you specify the `refresh_url` that your end user is redirected to if they access an expired onboarding link. This parameter is required when you create a new claimable sandbox. The `refresh_url` must call a method on your server that invokes the Claimable sandboxes renew onboarding link API to renew the onboarding link expiration. |
| WRONG | Use:
- **`test`** during development and internal testing. It keeps the app isolated from real user installs and live data.
- **`live`** when launching to users. This is the production channel for your released app.
You’ll generally promote or publish the tested version from the `test` channel to the `live` channel once it’s ready. The answer says to use `test` and `live`, but the source specifies `testing` for development and `public` for launch. |
| CORRECT | Use:
- **During development/testing:** `app_channel: "testing"`
- **When launching to users:** `app_channel: "public"`
You must first submit and publish your Stripe app, then switch your API integration to `public`. The `testing` channel has restrictions—including a limit of 25 live-mode installs—so don’t use it in production. It states `testing` for development and `public` for launching to users, exactly matching the source. site:docs.stripe.com apps app_channel development launch users app_channel5 results
results as cached 2026-09-04T00:49 Stripe apps app_channel "app_channel"5 results
results as cached 2026-09-04T00:49 Stripe app_channel values development production app manifest5 results
results as cached 2026-09-04T00:49 opened 2 pages
|
Right only because it checked. Unaided, the model gets this wrong. Unaided belief: wrong. With tools: searched on 100% of samples, answered correctly on 100%.
118 ### Country availability
119 ### Sandbox and onboarding link expiration
120 A claimable sandbox expires after 60 days. Find the exact expiration timestamp in the top-level `expires_at` field. Seven days before expiration, Stripe sends an email to the address in `prefill.email` to remind your users to claim the sandbox before Stripe deletes it. If a user doesn’t claim the sandbox within 60 days, Stripe permanently deletes it.
121 The onboarding link is valid for seven days. You can see the exact expiration timestamp in the `onboarding_link_details.expires_at` field. If a user accesses an expired onboarding link, Stripe redirects the user to the URL in `onboarding_link_details.refresh_url`. Your `refresh_url` must call a method on your server that invokes the Claimable sandboxes renew onboarding link API, which renews the link for another seven days.
122 ### Use API keys and authentication
| WRONG | A Stripe **claimable sandbox link expires after 30 days** if it hasn’t been claimed. Once claimed, the sandbox itself doesn’t expire on that same claim-link timer. The answer states 30 days, which directly conflicts with the source's 60-day expiration period. |
| CORRECT | A Stripe claimable sandbox lasts **60 days**. If it isn’t claimed within that period, Stripe **permanently deletes it**. It states that a Stripe claimable sandbox lasts 60 days, matching the source. site:docs.stripe.com claimable sandbox expires how long4 results
results as cached 2026-09-04T00:49 |
Right only because it checked. Unaided, the model gets this wrong. Unaided belief: wrong. With tools: searched on 100% of samples, answered correctly on 100%.
119 ### Sandbox and onboarding link expiration
120 A claimable sandbox expires after 60 days. Find the exact expiration timestamp in the top-level `expires_at` field. Seven days before expiration, Stripe sends an email to the address in `prefill.email` to remind your users to claim the sandbox before Stripe deletes it. If a user doesn’t claim the sandbox within 60 days, Stripe permanently deletes it.
121 The onboarding link is valid for seven days. You can see the exact expiration timestamp in the `onboarding_link_details.expires_at` field. If a user accesses an expired onboarding link, Stripe redirects the user to the URL in `onboarding_link_details.refresh_url`. Your `refresh_url` must call a method on your server that invokes the Claimable sandboxes renew onboarding link API, which renews the link for another seven days.
122 ### Use API keys and authentication
123 The keys and authentication method that you use depend on the entity performing the action:
| WRONG | A Stripe **claimable sandbox onboarding link is valid for 30 days**, or until it’s used—whichever comes first. It’s also single-use. The answer says 30 days, but the source states that the onboarding link is valid for seven days. |
| CORRECT | A Stripe **claimable sandbox onboarding link is valid for 7 days**. The claimable sandbox itself expires after **60 days**. It states that the claimable sandbox onboarding link is valid for 7 days, matching the source. site:docs.stripe.com claimable sandbox onboarding link valid duration Stripe5 results
results as cached 2026-09-04T00:49 |
Right only because it checked. Unaided, the model gets this wrong. Unaided belief: wrong. With tools: searched on 100% of samples, answered correctly on 100%.
119 ### Sandbox and onboarding link expiration
120 A claimable sandbox expires after 60 days. Find the exact expiration timestamp in the top-level `expires_at` field. Seven days before expiration, Stripe sends an email to the address in `prefill.email` to remind your users to claim the sandbox before Stripe deletes it. If a user doesn’t claim the sandbox within 60 days, Stripe permanently deletes it.
121 The onboarding link is valid for seven days. You can see the exact expiration timestamp in the `onboarding_link_details.expires_at` field. If a user accesses an expired onboarding link, Stripe redirects the user to the URL in `onboarding_link_details.refresh_url`. Your `refresh_url` must call a method on your server that invokes the Claimable sandboxes renew onboarding link API, which renews the link for another seven days.
122 ### Use API keys and authentication
123 The keys and authentication method that you use depend on the entity performing the action:
| WRONG | Renewing an expired Stripe claimable sandbox onboarding link extends its validity for **another 30 days**. The source states that renewing the link extends its validity for another seven days, not 30 days. |
| CORRECT | Renewing an expired Stripe claimable sandbox onboarding link extends its validity by **another seven days**. It states that renewal extends validity by another seven days, matching the source. site:docs.stripe.com claimable sandbox onboarding link expired renew validity extend3 results
results as cached 2026-09-04T00:49 opened 1 page |
Right only because it checked. Unaided, the model gets this wrong. Unaided belief: wrong. With tools: searched on 100% of samples, answered correctly on 100%.
127 Save the API keys from the create response because Stripe doesn’t return them in subsequent retrieve requests.
128 #### Caution
129 This MCP key expires seven days after a user claims the sandbox. Follow the [MCP authorization specification](https://modelcontextprotocol.io/specification/draft/basic/authorization) to make sure your platform can handle expired keys.
130 When you create a new claimable sandbox, Stripe automatically pre-installs your platform’s Stripe App in that sandbox. This creates a connection between your platform and the sandbox and lets you perform actions on behalf of your users in the sandbox. The account structure now looks like this:
131 `acct_bizbot_livemode`
| WRONG | The MCP key remains valid for **24 hours** after the user claims the Stripe claimable sandbox. The answer says 24 hours, but the source states that the MCP key expires seven days after the sandbox is claimed. |
| CORRECT | An MCP key remains valid for **7 days after a user claims a Stripe claimable sandbox**. The answer states that the MCP key remains valid for 7 days, matching the source. site:docs.stripe.com MCP key claimable sandbox valid how long2 results
results as cached 2026-09-04T00:49 |
Right only because it checked. Unaided, the model gets this wrong. Unaided belief: wrong. With tools: searched on 100% of samples, answered correctly on 100%.
192 This diagram shows that the managed app sandbox of Bizbot has a connection to the claimed sandbox for Jenny Rosen, and the live account is onboarded
193 After your user submits the account application, Stripe prompts the user to install your platform’s Stripe App in the live account. After installation, your platform receives the v2.core.claimable_sandbox.updated event, which shows that the `app_install_status` field has updated to `installed`. The `owner_details.account` field is also populated with the ID of the owner account.
194 After installation, the sandbox `status` field changes to `live`. This indicates that the claimable sandbox object has reached the end of its lifecycle and won’t change again. At this stage, your claimable sandbox integration is complete and ready for production.
195 ```
196 {
| WRONG | Its status changes from **`claimable` to `claimed`**. The source states that after installation the sandbox status changes to `live`, not `claimed`. |
| CORRECT | After the app is installed, a Stripe claimable sandbox’s status changes to **`live`**. It states that the status changes to `live`, matching the source exactly. site:docs.stripe.com claimable sandbox status after app is installed3 results
results as cached 2026-09-04T00:49 |
Right either way — the model knows this, and checking confirms it. Unaided belief: correct. With tools: searched on 100% of samples, answered correctly on 100%.
118 ### Country availability
119 ### Sandbox and onboarding link expiration
120 A claimable sandbox expires after 60 days. Find the exact expiration timestamp in the top-level `expires_at` field. Seven days before expiration, Stripe sends an email to the address in `prefill.email` to remind your users to claim the sandbox before Stripe deletes it. If a user doesn’t claim the sandbox within 60 days, Stripe permanently deletes it.
121 The onboarding link is valid for seven days. You can see the exact expiration timestamp in the `onboarding_link_details.expires_at` field. If a user accesses an expired onboarding link, Stripe redirects the user to the URL in `onboarding_link_details.refresh_url`. Your `refresh_url` must call a method on your server that invokes the Claimable sandboxes renew onboarding link API, which renews the link for another seven days.
122 ### Use API keys and authentication
| CORRECT | If a Stripe **claimable sandbox** isn’t claimed within 60 days, it expires and Stripe automatically deletes it, including its sandbox data. It can’t be recovered afterward; you’ll need to create a new sandbox. It states that Stripe deletes the unclaimed claimable sandbox after 60 days, matching the source's required fact. |
| CORRECT | If a Stripe claimable sandbox isn’t claimed within **60 days, Stripe permanently deletes it**. Any data or configuration in that sandbox is lost. citeturn0search0 It states that Stripe permanently deletes the unclaimed sandbox after 60 days, matching the source. site:docs.stripe.com claimable sandbox 60 days claimed1 result
results as cached 2026-09-04T00:49 |