Version 1
New REST integrations can use /api/v1/vectorize, /api/v1/billing, and /api/v1/files/{conversion_id}/svg at https://api.vectali.com. They use the same request/response shapes, credentials and billing ledger as the original API. The OpenAPI document describes these endpoints.
The original /api/vectorize, /api/billing, and file URLs remain supported. They are not deprecated by this release. Existing limits on image size, dimensions, SVG size, and subscription allowance remain unchanged.
The response header Vectali-API-Version: 1 identifies API behavior. Backward-compatible fields may be added, so clients should tolerate unknown JSON fields. Breaking changes will use a new major version. Vectali will give at least 90 days’ notice before removing a supported version, announce the replacement in these docs, and send Deprecation and Sunset headers on affected endpoints. No sunset date is currently scheduled; we do not send a fictional deprecation date.
Rate limits
Authenticated v1 REST and MCP requests share a 60 requests/minute/account fixed window. Conversion attempts on these interfaces additionally share a 6 attempts/minute/account window. These are operational limits, separate from the 500 successful conversions included in API Starter. Legacy REST endpoints retain their prior behavior.
Successful authenticated responses include RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset (seconds until the current minute window resets), plus RateLimit-Policy. HTTP 429 responses include Retry-After and the exhausted window’s remaining allowance. MCP tool failures appear inside the protocol’s tool result with isError: true, a stable error code and retry_after_seconds when appropriate; inspect the result even if HTTP returned 200.
For 429 or 503, wait at least the indicated delay. For 409 conversion_in_progress, wait before retrying. Preserve the original request ID and exact image bytes. Stop automatic retries after two attempts and surface the error. Authentication, quota and invalid-input errors require a correction, not an immediate retry loop. Idempotency prevents double billing; it does not make unlimited retries useful.
Do not use the compatibility endpoints to evade rate limits. Contact support if your integration needs a different throughput pattern.