> ## Documentation Index
> Fetch the complete documentation index at: https://www.octogen.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Request a product refresh

> Refresh a specific set of products by URL or UUID.

Product refresh lets you update a known set of product pages without waiting for the standard catalog update cadence. Use it when your system already knows which products changed, such as a new drop, a merchandiser correction, or a small set of products that should be updated quickly.

Refresh starts an asynchronous Octogen workflow: the product pages are recrawled, re-extracted, and re-indexed in sequence. The API returns as soon as the request is accepted; refreshed data — including a product's active status on lookup — typically becomes visible within a few **hours**, not minutes.

## Choose identifiers

Use the identifier you already have:

| You have                                                        | Send                |
| --------------------------------------------------------------- | ------------------- |
| An indexed Octogen product                                      | `uuid`              |
| A canonical product page URL                                    | `url`               |
| A product page URL that may not be indexed yet                  | `catalog` and `url` |
| A URL that could appear in more than one active crawled catalog | `catalog` and `url` |

Every target must contain exactly one of `url` or `uuid`. Add `catalog` when you want to pin the request to one active crawled catalog.

## Make a request

```bash theme={null}
curl -sS https://api.octogen.ai/v1/products/refresh \
  -H "Authorization: Bearer $OCTOGEN_PLATFORM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "targets": [
      {"uuid": "11111111-1111-4111-8111-111111111111"},
      {
        "catalog": "warrenlotas",
        "url": "https://warrenlotas.com/products/new-drop"
      }
    ]
  }'
```

The response includes a `workflowId` that Octogen support can use to trace the refresh. You do not need to poll it for normal use.

## Handle partial success

The endpoint accepts valid targets and rejects invalid targets in the same response. Treat `accepted` as scheduled work and `rejected` as caller-actionable feedback.

```json theme={null}
{
  "requestId": "62cf3df6-30f2-4c0e-b13d-fc509bba8d4f",
  "submitted": 2,
  "workflowId": "4b4b68de-65f3-4f79-af57-a4a1d6ef4e13",
  "workflowError": null,
  "accepted": [
    {
      "catalog": "warrenlotas",
      "url": "https://warrenlotas.com/products/new-drop"
    }
  ],
  "rejected": [
    {
      "target": {"url": "https://shared.example/products/1"},
      "code": "ambiguous_url",
      "message": "URL matched more than one active crawled catalog; include catalog."
    }
  ]
}
```

If every target is rejected, the API returns `400` with the same response shape. Fix the rejected targets and retry.

## Retry guidance

Retry `503` responses and transient network errors. Do not automatically retry `400`, `403`, or `422`; those require a request change.

Avoid sending the same large request repeatedly. If you need to refresh many products, batch up to 500 targets per call and retry only the targets that were rejected for transient reasons.