Skip to content

Authentication

Revieve identifies callers by Partner ID — a short string issued per partner, per environment. There is no OAuth flow, no JWT, no session cookie, and no Authorization header. Authentication is a single multipart form field on every request.

The Partner ID rides as a form field in the multipart body of POST /analyzeImage/:

POST /api/3/analyzeImage/?skintone=0&gender=unknown HTTP/1.1
Content-Type: multipart/form-data; boundary=----X
----X
Content-Disposition: form-data; name="partner_id"
jmlv6b2qtS
----X
Content-Disposition: form-data; name="image"; filename="selfie.jpg"
Content-Type: image/jpeg
<binary>
----X--

That’s it. Don’t add Authorization headers; they aren’t read.

EnvironmentPartner IDBase URL
Testjmlv6b2qtS (shared demo)https://partner-test.revieve.com/api/3/
ProductionIssued per partnerRegion-specific, supplied at handoff

The test ID is rate-limited and shared. Treat it like any public demo key — fine for evaluation, never for real users.

Treat the Partner ID like a long-lived secret:

  • Never embed it in client-side bundles in production. Proxy through your own backend.
  • Don’t commit production IDs to source control. Test ID is fine.
  • Rotate by request to your Revieve account contact. Old IDs continue to work until revoked.

The CV service itself does not validate Partner ID — auth and rate-limiting live at the gateway. From the partner side this means:

  • Quota is per Partner ID, not per IP.
  • Throttling returns standard 429 responses with a Retry-After header.
  • Region routing is determined by the production base URL you receive — not by anything in the request.

The test environment permits browser-origin requests with Access-Control-Allow-Origin: *, which is convenient for prototyping but means you should still proxy through your own backend in production to avoid leaking the Partner ID into the client bundle.