# Fix list: Photoroom API

From Anchor Terminal's listing at https://www.anchorterminal.com/tools/photoroom, the October 2026 research run, assessed 9 October 2026. Grade C, 56 out of 100.

This is everything the published grade says the listing lacks, the biggest possible gain to the total first. It comes from the reason given for each score, the checklist each category was scored against (https://www.anchorterminal.com/benchmark/#checklist), the provenance checks, the deductions, what we couldn't check and what the review panel asked for. A fix counts at the next check, once it's public.

For a coding agent working on Photoroom API: work through the items below in the product, its docs and its public pages. Each category gives the reason for its score, with the points each checklist item earned, and the checklist itself, so the gap is the items that earned less than their points. Change the product, not the wording, and keep a note of what you changed and where it's published.

## 1. Reliability, 46 out of 100, up to 10.8 more on the total

Why it scored 46: Read with the hosted lines. No status page was found on photoroom.com, the docs or the security page, and status.photoroom.com did not answer one request (0). With no history to read, the incident line takes the floor of 5. The security page states one incident on record, a 30-minute availability disruption in October 2024, which is the vendor's own account (5). Limits are published, 60 images a minute by default and 1,000 a month and 100 a day in sandbox mode (15). The docs say a 429 is returned at the limit and tell callers to back off exponentially and to retry a 500 up to three times. No `Retry-After` header or idempotency key is documented (11). The API page states a 99.9 per cent uptime target on Enterprise accounts, with no SLA document found, and the terms say availability is not guaranteed, so half credit (5). The Image Editing API left beta on 3 April 2024. Upscale, text-guided segmentation and templating are labelled preview (10).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-reliability):

Hosted APIs, MCP servers, models and platforms.

- 20, a public status page with component history (Statuspage, Instatus, BetterStack or the vendor's own).
- 0 to 30, the incident record for the last 90 days on that page. 30 for a clean record or trivial incidents only, 20 for minor incidents only, 10 for one major outage (an hour or more of a core API down, or errors across the board), 0 for several. 5 when there's no history we could read, and the note says so.
- 15, rate limits documented with numbers.
- 15, documented 429 or overload handling (Retry-After, backoff guidance), and idempotency keys or safe-retry guidance where writes are involved.
- 10, an SLA published for any paid tier.
- 10, the surface agents use is generally available, not beta or preview.

Local packages, SDKs, frameworks and stdio MCP servers.

- 20, installs from an official package with supported runtimes stated.
- 25, a public CI and test suite, passing on the default branch.
- 0 to 25, open crash or regression issues relative to activity (25 for few and handled, 0 for many, old and unanswered).
- 15, semver discipline and breaking changes called out in a changelog.
- 15, version 1.0 or later, or declared stable.

Protocols are read from their reference implementations, the public facilitators or servers, spec stability and test vectors.

## 2. Security & auth, 54 out of 100, up to 8.1 more on the total

Why it scored 54: A team can hold several API keys and revoke each in the dashboard, with no scopes found. The key travels in the `x-api-key` header only. The MCP server uses an OAuth authorisation code grant with PKCE, dynamic client registration and a revocation endpoint, and creates its own key for the connection (20). No read-only key. The API stores nothing to change, a sandbox key cannot spend, and a prepaid monthly allowance bounds spend (8). Returns images, not untrusted text (10). The dashboard shows usage history, `GET /v2/account` returns the balance, and the security page says API access logs are kept for one year on Photoroom's side (6). The security page states a SOC 2 Type 2 attestation scoped to the API with a report of April 2026. The trust centre is drawn by script and was not read. `security.txt` returns 404 and no disclosure policy or bug bounty was found (10).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-security):

- 0 to 30, the credential model. 30 for OAuth 2.1 with scopes, or scoped and revocable keys with rotation. 20 for plain revocable API keys. 10 for one all-powerful key. 10 off when a secret can travel in a URL query string as a documented option.
- 0 to 20, read-only or least-privilege modes, and confirmation or approval for destructive actions.
- 0 to 15, prompt-injection posture where the tool returns untrusted content (documented mitigations or guidance). A tool that returns no untrusted content gets 10.
- 0 to 15, audit logs or per-call visibility for the operator.
- 0 to 20, a security programme. security.txt or a disclosure policy, a bug bounty, SOC 2 or ISO 27001, advisories handled in public.

Models are read for retention, whether API data trains models (and whether that's off by default), zero-retention options and certifications. Frameworks for telemetry defaults, approval hooks, guardrails and sandboxing.

## 3. Payments & pricing, 40 out of 100, up to 7.5 more on the total

Why it scored 40: No x402, MPP or L402 in the docs, the OpenAPI description or the pricing pages (0). Per-image prices are public, $0.02 for background removal and $0.10 for an Image Editing call (20). Sandbox mode gives 1,000 free watermarked calls a month and a new account 10 free production calls on the Remove Background API, with no card, per the pricing page (20). A person has to create an account and activate the API in the dashboard. The MCP server's OAuth flow registers clients dynamically but still needs a Photoroom sign-in (0).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-payments):

The published rubric, also on the [x402 page](https://www.anchorterminal.com/x402/).

- 40, a machine payment protocol (x402, MPP or L402) on the tool's own endpoints. 10 to 30 when it covers only some endpoints or only goes through a third party, and the note says which.
- 20, per-call or per-unit pricing published without a login. 10 for public plan-only pricing, 0 for "contact sales" or prices behind a login.
- 20, a free tier or trial that doesn't need a card.
- 20, autonomous onboarding, meaning an agent can get access without a person signing up in a browser (keyless use, x402, a programmatic key API).

Payment platforms and agent wallets rarely charge for their own API over a machine protocol, so the first line has steps for them, and the highest one that applies counts. 40 when x402, MPP or L402 runs on all their own endpoints, 30 when it runs on part of their own API, 25 when their merchants can accept one, 20 for running a facilitator, 15 for paying as a buyer, and 0 when the only protocol is their own. Merchant acceptance sits above a facilitator because the platform's own customers can charge agents through it, while a facilitator settles for sellers who wire up the protocol themselves. The counter-argument (a facilitator does more for the protocol as a whole) has a point. Each note says which step applied.

Open-source software you run yourself is scored on its hosted or paid option if it has one. A free, self-hosted package with nothing to buy gets 20, 20 and 20 for the last three lines, and 0 to 40 for the first only if it ships a payment protocol.

## 4. Maintenance & community, 23 out of 100, up to 6.7 more on the total

Why it scored 23: The last dated changelog entry is 21 April 2026, 171 days before the check (10). We took the strict reading. The docs sitemap shows page edits up to 5 October 2026, and the docs list Virtual Try-On, which has no changelog entry. No dated changelog entry in the last 90 days (0). A public changelog and a Discourse community where each of the 17 topics dated 30 September to 3 October 2026 had a reply. We did not open the topics to see who replied (11). No official SDK, and no Photoroom entry in the official MCP registry (0). The sample code repository's last commit is a README change on 23 April 2026 and it has no CI (2).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-maintenance):

- 0 to 30, time since the last release, or the last published model or API change for a closed service. 30 within 30 days, 20 within 90, 10 within 180, 0 older.
- 20, at least three releases or dated changelog entries in the last 90 days.
- 0 to 25, responsiveness. Issues and pull requests answered on GitHub (the open issues and how recent the replies are). For closed services, a public changelog and a support or community channel that answers, 0 to 15.
- 15, presence in the official MCP registry under a verified namespace (MCP servers), or current official SDKs (APIs and models).
- 10, package health, current dependencies and CI.

Models are read for deprecation notice periods and model churn rather than release counts.

## 5. Agent ergonomics, 64 out of 100, up to 5.9 more on the total

Why it scored 64: The response body is the image itself, so an agent saves a file and reads nothing into context. `outputSize`, `maxWidth`, `maxHeight`, `export.format` and the `size` presets set what comes back, and the MCP server has one tool, per Photoroom (18). Nothing to paginate. Output size, format and DPI controls (15). JSON errors with a message and a documented meaning for 400, 401, 403, 402, 429 and 500, but the two APIs use different shapes and `Unauthorized` covers both a missing key and an empty balance (13). No idempotency key. Calls keep no state, failed calls are not billed and `background.seed` repeats a generated background, but a retried success is billed again. The MCP tool's annotations were not read (10). Only the image is required and defaults are sensible. No official SDK, only sample code for four platforms (8).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-ergonomics):

- 0 to 25, context cost. For MCP, the number and size of the tool definitions (25 for ten or fewer compact tools, 15 for 11 to 30, 5 for more than 30, plus up to 10 back for toolsets, dynamic loading or read-only subsets). For APIs, whether responses can be sized (field selection, limits, summaries).
- 20, pagination, filtering and output-size controls.
- 20, actionable, documented error responses, codes and messages an agent can recover from.
- 20, idempotency or safe retries, and for MCP the `readOnlyHint` and `destructiveHint` annotations.
- 15, sensible defaults, few required parameters, and official SDKs in at least two languages.

Models are read for tool use, structured output, prompt caching, context length, batch and SDKs. Frameworks for how much code and how many defaults a tool-calling agent with MCP needs.

## 6. Transparency & trust, 68 out of 100, up to 2.8 more on the total

Made of editorial 57, provenance 78.

Why it scored 68: Closed hosted service under the Photoroom Terms and Conditions effective 29 July 2026, which name the application programming interface. Sample code is MIT (15). The security page gives retention figures (images discarded after the call, operational logs 15 days, API access logs one year). The statements on training disagree. The privacy policy of March 2026 says model improvement does not apply to API images, the security page says self-serve API plans train by default with an opt-out, and the terms authorise training on user content with an opt-out. A DPA is for Enterprise customers only (14). Preview and alpha functions carry a two-week notice, the 2024 base URL change gave a dated deadline, and the AI Backgrounds v2 model is marked deprecated with no removal date (12). The security page names GCP, AWS, Cloudflare, Datadog and Vercel and says hosting is in the United States. The full list is in the trust centre, which was not read (16).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-transparency):

- 0 to 30, source availability and licence clarity. 30 for open source under an OSI licence, 15 for closed with clear terms, 0 for unclear terms.
- 0 to 30, data handling and retention statements that agree with each other (privacy policy, DPA, retention periods, subprocessors).
- 0 to 20, a deprecation policy or notices with dates.
- 0 to 20, telemetry disclosed with an opt-out (local software), or subprocessors and data locations disclosed (hosted).

The other half of Transparency and trust is the provenance score, computed from checked facts (below). The category score is the mean of the two.

Provenance checks not met in full (half of this category, computed from checked facts):

- Terms of service: read, states 7 of the 7 things a reader expects, and has 1 clause that costs points (8 of 10)
- Status page: not found (0 of 10)
- security.txt: not found (0 of 10)

## 7. Schema & documentation, 86 out of 100, up to 2.3 more on the total

Why it scored 86: A public OpenAPI 3.1.0 description at image-api.photoroom.com/openapi, read as embedded on the docs reference page, with four operations (25). `llms.txt`, a Markdown twin of every page and a page with a prompt written for coding agents (10). 86 of the 87 parameters of `GET /v2/edit` carry a description, the operation description lists every edit, and the agent page says when to call each of the two APIs (17). 31 of 87 parameters have enums, but booleans are strings, no field of `/v2/edit` is marked required, and the embedded description declares neither the `x-api-key` header nor the `pr-*` model headers (10). Curl examples on every page and 400, 402 and 500 bodies in the description. 401, 403 and 429 are documented in prose only, and the two APIs use different error shapes (11). Paths are `/v1` and `/v2`, models are pinned by dated headers and the changelog is dated back to June 2023, but the description's version is fixed at 1.0.0 and the last changelog entry is 21 April 2026 (13).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-schema):

APIs and MCP servers.

- 25, a machine-readable contract (a public OpenAPI file or similar; for MCP, typed JSON Schema inputs on every tool).
- 10, llms.txt or Markdown docs served for agents.
- 0 to 20, descriptions that say what a tool is for, when to use it and when not to, read from the tool definitions in the source or the API reference.
- 0 to 15, typed inputs with enums, constraints and required fields, and no free-form JSON blobs.
- 0 to 15, examples and documented error responses.
- 15, versioning and a public changelog.

Models are read from the API reference, the OpenAPI file, llms.txt, the structured-output and tool-use docs and the model cards. Frameworks from docs a model can follow, typed interfaces, examples and the API reference.

## What we couldn't check

What we couldn't read counted as absent. Publishing it on a page a plain HTTP fetch can read (not only in a browser) lets the next check count it.

- The lead was right on the interface and the docs. It did not mention the hosted MCP server at https://mcp.photoroom.com/mcp, and upscale is a preview function.
- unchecked: the trust centre at trust.photoroom.com is drawn by script, so the SOC 2 report, the full sub-processor list and the DPA were not read.
- unchecked: the MCP server's tool definition and annotations. The server answers 401 without a token. The count of one tool is Photoroom's statement.
- unchecked: the plan sizes and monthly prices on the pricing page selector, which is drawn by script. The per-image prices come from the page's FAQ and the docs.
- No status page was found. status.photoroom.com did not answer one request, so we cannot say whether one exists under another address.
- The privacy policy, the security page and the terms disagree on whether images sent to the API on a self-serve plan are used for training. No deduction was taken. It is counted under Transparency.
- The terms (section on restrictions) forbid using any automated system to send more requests than a person could produce from a web browser, and forbid scraping. Recorded as a fact with no deduction. It matters before any probe is run.
- Every docs page and `llms.txt` end with a block addressed to agents that describes a `?ask=` query on the docs host. We did not use it.
- The security page describes asynchronous API jobs. The reviewed docs describe synchronous calls only.
- The terms name Photoroom SAS (RCS Paris 853 059 384). The site footer reads Photoroom, Inc.
- No launch date for the Remove Background API was found, so `firstReleased` is empty. The changelog starts on 4 June 2023.

## Weaknesses

- No status page was found on the site or in the docs, so there is no public incident history to read
- The privacy policy says model improvement does not apply to API images. The security page says self-serve API plans train by default with an opt-out
- No official SDK. The vendor publishes MIT sample code for web, Node.js, Python and iOS and tells callers to use a plain HTTP client
- The changelog's last dated entry is 21 April 2026, while the docs list Virtual Try-On, which has no changelog entry
- The terms forbid any automated system that sends more requests than a person could from a browser. This matters before any probe is run

## What costs an agent a turn today

The notes we give agents before they call it. Each one is a workaround an agent shouldn't need.

- Send the key in the `x-api-key` header. Prefix it with `sandbox_` while testing, because calls with the plain key consume paid images
- Save the response body as a file. A 200 returns image bytes, PNG by default, and any other status returns JSON with `error.message` or `detail`
- Send model selectors such as `pr-ai-shadows-model-version: 2026-04-15` as HTTP headers, not form fields. They are not in the OpenAPI file
- Stay under 60 images a minute. On 429 back off with an exponential delay, and set a client timeout of at least 60 seconds for AI edits
- Use `POST /v2/edit` with `imageFile` for local files and `GET /v2/edit` with `imageUrl` for hosted ones. Each call takes one image

## When it's done

Send what changed and where it's published as a dispute (https://www.anchorterminal.com/builders/#disputes, or `POST https://www.anchorterminal.com/api/v1/contact` with `"kind": "dispute"`). Disputes are answered in public, and the listing is checked again by the same checklist. Paying for an audit or a listing claim changes nothing here.