---
title: "Migrate to Arrow 2"
description: "Update retired model IDs, check API key authority, and verify native SVG requests before October 16, 2026."
icon: "arrow-right"
---

Migrate integrations using `arrow-1`, `arrow-preview`, `arrow-1.1`, or `arrow-1.1-max` before **October 16, 2026 at `08:00` UTC (`10:00` Europe/Berlin)**. After the retirement cutover, requests naming these IDs are expected to return `404 model_not_found`. They will not redirect to Arrow 2.

`arrow-1.0` is already rejected; it is not an accepted ID newly retiring at this cutoff.

## Find affected callers

Inventory the model IDs, API keys, and SVG operations used by each application, background job, and deployment environment. Record the organization and project that own each key. This shows which generation, vectorization, editing, and animation callers still use a retiring ID or a key restricted to it.

Then call [`GET /v1/models`](/api-reference/models/list-models) with the key each integration will use:

```bash
curl https://api.quiver.ai/v1/models \
  -H "Authorization: Bearer $QUIVERAI_API_KEY"
```

Use `arrow-2` for public SVG generation, vectorization, editing, and animation. Check that it appears and that `supported_operations` includes the operation each caller needs: `svg_generate`, `svg_vectorize`, `svg_edit`, or `svg_animate`. Listing models requires `catalog_read`. The catalog shows availability for the organization; the key must also authorize the model and operation. Arrow 2 Telos (`arrow-2-telos`) is an alternative only when it appears in the catalog, the key permits it, and it supports the required operation.

Native SVG endpoints remain supported. This retirement does not require a move to `/v1/responses`; if you choose that endpoint separately, confirm the model advertises `open_responses` and the key permits it.

## Keep or replace the key

Check whether each key allows Arrow 2 and the operations its integration needs:

| Existing key authority | Migration action |
| --- | --- |
| Wildcard model access, with the required operation permitted | Keep the key; migrate and test the requests. |
| Already allows `arrow-2`, with the required operation permitted | Keep the key; migrate and test the requests. |
| Model allowlist excludes `arrow-2`, or the required operation is missing | Create a replacement inference key with the needed model and operation permissions. Include `catalog_read` if it needs to list models. |

Key authority is fixed at creation. Rotating the secret preserves that authority, so it cannot grant Arrow 2 access. If a replacement is needed, create a project inference key in [API Platform API Keys](https://platform.quiver.ai/api-keys) for the intended organization, project, environment, and owner or service account. Organization admin keys cannot run inference. See [API keys](/developers/platform/api-keys) for scope and secret lifecycle details.

## Update requests

For native SVG callers, keep the endpoint path and change the `model` field after checking the operation, key, and model-specific input limits. An Arrow 1.1 Max generation request can have 16 reference images; Arrow 2 accepts at most 14. Reduce any 15- or 16-image request to 14 or fewer before switching models, or it will return `400 invalid_request`.

These examples show request bodies. Send them with Bearer authorization and `Content-Type: application/json`.

For [`POST /v1/svgs/generations`](/api-reference/create-svgs/generate-svg), change:

```json
{ "model": "arrow-1.1", "prompt": "A simple compass icon" }
```

to:

```json
{ "model": "arrow-2", "prompt": "A simple compass icon" }
```

For [`POST /v1/svgs/vectorizations`](/api-reference/vectorize-svg/vectorize-svg), change:

```json
{ "model": "arrow-1.1", "image": { "url": "https://example.com/source.png" } }
```

to:

```json
{ "model": "arrow-2", "image": { "url": "https://example.com/source.png" } }
```

Replace the example URL with your publicly accessible source image. The linked endpoint schemas cover other request fields. For editing and animation, use the API Reference for [`POST /v1/svgs/edits`](/api-reference/edit-svg/edit-svg) and [`POST /v1/svgs/animations`](/api-reference/animate-svg/animate-svg), then change their model field once `svg_edit` or `svg_animate` is confirmed.

Arrow 1.1 uses fixed credits per completed SVG generation or successful vectorization. Arrow 2 uses measured token usage, so its cost depends on the request. Read current `billing.rates` from `GET /v1/models` and review [API pricing](/developers/pricing) before forecasting charges.

## Roll out and verify

Store any new secret in a secrets manager, then update application and deployment configuration. Check organization funding before rolling out Arrow 2 to each consumer. A Test key returns mock responses without inference or charges, so verify the live behavior with a Production key. If you stream native SVGs, treat `draft` events as previews and `content` events as completed output. Revoke an old key only after all of its consumers have moved.

Before completing the rollout:

- Send a Production request for each operation you use. Inspect the completed SVG, output handling, and usage or charge for the intended organization.
- For a failed request, check the model ID, endpoint, required fields, reference-image count, and key permissions. After the cutoff, retired IDs return `404 model_not_found`; unknown or non-visible models can do the same. A key that denies the model or operation returns `403 unauthorized`.
- Use [Errors and debugging](/developers/guides/errors-and-debugging) for streaming failures, request IDs, Logs, and support if a problem persists.