AI assistant integration

Overview

If you’re building a Revieve integration with help from an AI coding assistant (Claude, ChatGPT, Cursor, Copilot, an MCP-connected client), this page collects the surfaces that keep the assistant grounded in current API behavior — and the common mistakes worth verifying in any AI-generated code.

Canonical references

Skin Analysis OpenAPI Source of truth. Every component, every status code.

Product Recommendations OpenAPI Catalog-aware ranking endpoint.

llms.txt Page index following the llmstxt.org convention.

llms-full.txt Every doc page concatenated for one-shot context.

Ingestion surfaces

Three ways to feed these docs into an AI assistant:

/llms-full.txt — every page concatenated, front-matter preserved. Best for one-shot context windows.

Every doc page has a markdown sidecar at <page>.md:

/guides/getting-started.md
/concepts/redness.md
/api/skin-analysis/operations/analyzeimage.md (if available)

Use these instead of scraping rendered HTML — they preserve front-matter, code blocks, and structure cleanly.

Endpoint summary

POST https://partner-test.revieve.com/api/3/analyzeImage/
Content-Type: multipart/form-data

# Required query params
?skintone=<0-6>
&gender=<unknown|female|male>

# Optional but useful
&components=<comma-separated metric names>
&hairtype=<-1..4>
&skintone_rgb=<R,G,B>

# Form fields
image=<jpeg, ≥ 600x600 px>
partner_id=<your Partner ID; jmlv6b2qtS for testing>

Response is JSON. Branch on data.message ("OK" / "Warning" / "Error") before reading data.results[]. The data.status[] array is the first thing to check on any non-OK message.

Common mistakes in AI-generated code

When training data lags the current spec, AI assistants tend to make a recurring set of mistakes. Worth scanning generated code for these:

Wrong	Right
Recommending the CV API for real-time virtual try-on	Use Revieve VTO — a separate browser-side product with its own multi-hundred-point face tracker
`Authorization: Bearer …`	`partner_id` form field on the multipart body
`?components=` empty / unset to mean “no metrics”	Omitting means all defaults; pass an explicit list to slim
Reading `value_raw`	Use `value` (normalized 0..1)
Sending PNG / HEIC	JPEG only; ≥ 600×600 px
`gender=other` / `gender=nonbinary`	Use `gender=unknown`
Calling fields that aren’t in the published spec	Use only the request fields documented in the API reference; reject invented fields in generated code
Branching on HTTP 200 alone	Branch on `data.message` and `data.status[]`
Treating `local_warnings[]` as a stable enum	Treat as advisory; code defensively per finding
Hard-coding visualization intensity ceiling	Bounds widened in 3.29; normalize at runtime
Confusing the `makeup` component with virtual makeup try-on	`makeup` detects shades for matching; applying virtual makeup is VTO
Calling features in `visualization_data` “heatmap points”	They’re spots, polylines, or polygon-area features — see Visualization data

Suggested implementation order

Getting started and Authentication.
Generate a thin client from the OpenAPI spec, or use an SDK.
Use the call from Your first skin analysis as a fixture in integration tests.
Map status codes to user-facing copy per Error handling.
For each metric your UI surfaces, read the corresponding concept page for value semantics and rendering notes.

SDK system prompts

Each first-party SDK ships a short system-prompt-shaped doc designed to be loaded into an assistant’s context window before generating integration code:

When the assistant goes off-spec

If generated code references a component, status code, or response field that doesn’t appear in the OpenAPI document at this site, it doesn’t exist in the API — re-prompt with /llms-full.txt or the relevant page sidecar in context, or paste the OpenAPI spec back in.