Marketplace seller verification
Score seller storefront photos, proof-of-inventory shots, and high-value listing visuals before trust badges or premium-tier privileges are granted. A 'verified seller' badge is a promise; AI-generated proof-of-stock photos break it quietly.
The category-specific abuse pattern in marketplace seller verification is consistent: bad actors don't generate photos of products — they generate photos of contexts that establish trust. 'Here's my warehouse.' 'Here's my workshop.' 'Here's my hand holding the item.' Those scenes are exactly what generation models are good at faking, and they're exactly what verification reviewers used to take as ground truth. The gate is most valuable not on the listing photos themselves, but on the context-establishment photos that sit alongside them.
Business value
- Hardens the verified-seller program against the most efficient new abuse pattern: AI-generated proof-of-inventory uploaded as 'photos of items in my warehouse.'
- Protects buyer trust on high-value listings where the listing photo is the only evidence the seller has the item.
- Catches stolen-photo recycling early — sellers who lifted product photos from other marketplaces and ran them through a generation pass to evade reverse-image-search.
Agent job to be done
Be a verification reviewer. Allow when proof photos read as authentic inventory shots. Hold when synthetic cues or recycled-photo patterns appear. Reject for sellers with combined high-risk evidence and prior policy violations.
format: otherintended_use: moderatedomain: marketplace seller verification photography
Marketplace-specific seller-verification flows
eBay's verified-seller program, Etsy's verified-seller checkmark, Mercari's Pro Seller tier, and Reverb's Preferred Seller status all use slightly different proof requirements. eBay requires utility-bill scans; Etsy requires shop-establishment documentation; Mercari weighs transaction history more heavily; Reverb often requires gear-serial-number photos. The image-scoring gate maps best onto the photo-proof step that all four flows include — but the surrounding business-process verification varies and the gate doesn't replace it.
When to call VeracityAPI
On seller verification application, on listing creation for high-value categories ($500+ items, regulated goods), and on seller-tier upgrade requests.
What image URL to submit
Public HTTPS image URL(s) for the proof shots. For inventory photos, multiple angles strengthen the signal — score independently and aggregate.
Decision policy
- allow: low risk across all proof photos, no conflicting signals from reverse-image-search or device fingerprinting.
- revise: medium risk — request additional photos (different angle, scale reference, timestamp watermark on a held-up newspaper).
- human_review: high risk OR seller has a prior listing-suppression history.
- reject: high risk combined with marketplace-platform red flags (new account, payment mismatch, listing description copied from other platforms).
Request template
The exact payload shape this use case sends. The sample below uses representative content for this workflow; substitute your own.
curl https://api.veracityapi.com/v1/analyze \
-H "Authorization: Bearer $VERACITY_API_KEY" \
-H "Content-Type: application/json" \
-d '{"type":"image","content":"https://veracityapi.com/demo/influencer-beauty-tonic.jpg","context":{"format":"other","intended_use":"moderate","domain":"marketplace seller verification photography"},"store_content":false}'Automation recipe
- Verification worker pulls the proof-photo bundle from the application.
- Score each photo independently.
- Cross-reference with reverse-image-search: a photo that scores authentic but matches a competitor marketplace's listing is a recycled-photo case.
- Aggregate evidence categories for the manual reviewer.
- Approved sellers get the verification badge; held sellers get a 'submit additional proof' prompt.
Evidence spans agents should inspect
- 'synthetic_warehouse_scene' — generated 'photos of inventory' often have impossible lighting and inventory-arrangement patterns
- 'composite_seam' — products pasted into scenes (a phone laid on a 'desk' that's actually a stock image)
- 'metadata_mismatch' — image metadata that doesn't match a phone or camera capture path
- 'scale_inconsistency' — handheld props that don't agree with the stated product size
A concrete example
Setup: A musical-instrument marketplace ran 2,800 seller verification applications through the gate over Q1 2026. Their existing verification process accepted roughly 91% of applications, with a 4.2% post-verification policy violation rate.
Result: The gate routed 18% of applications to additional-proof requests. Of those, 41% completed the additional proof and were verified; 59% abandoned the application. Post-verification policy violation rate on the gated cohort dropped to 1.1%. The abandonment rate is the signal — most legitimate sellers will provide a second proof photo; most fraud applicants won't.
Policy pseudocode
if (result.recommended_action === "allow") continueWorkflow(); if (result.recommended_action === "revise") rewriteWith(result.evidence, result.recommended_fixes); if (result.recommended_action === "human_review") queueForHumanReview(result); if (result.recommended_action === "reject") discardOrRebuild();
KPIs to track
- verification applications processed per day
- fraud-seller removal rate after gate deployment
- verified-seller policy-violation rate
- false-positive appeal rate from legitimate small sellers (high here = thresholds need loosening)
- median time-to-verify for clean applications
What can go wrong
- Small sellers often shoot product photos in non-ideal conditions (poor lighting, phone cameras) that can trip the 'composite_seam' or 'lighting_mismatch' evidence categories falsely. Calibrate thresholds against your actual seller distribution, not against ideal photography.
- Reverse-image-search is the necessary companion signal. A photo that scores authentic but appears verbatim on another marketplace is a recycled-photo case, not an AI-generation case.
- Regulated goods (firearms, cosmetics, medical devices) have additional verification requirements beyond photo scoring. Don't substitute the gate for category-specific compliance.
Cost and latency notes
Image analysis is a flat $0.02 per image. The endpoint accepts HTTPS image URLs, stores no image bytes, and logs only a URL hash plus hostname. Current v0.1 latency is vision-model-bound, so preflight balance and retry carefully.
Agent evaluation checklist
- Does this workflow have a costly failure mode from manipulated or synthetic-looking visuals?
- Can the agent store evidence categories without storing raw image bytes or full URLs?
- Should this workflow fail open, fail closed, or queue human review if image scoring is unavailable?
- Which field drives policy: recommended_action, risk_level, content_trust_score, or synthetic_image_risk?
- What local provenance check should complement the API score?