What Is a Photo Verification API? (How It Works + When to Use One)

A photo verification API is an endpoint you send an image to, along with a reference to a set of rules, and get back a structured verdict: a pass/fail decision, a confidence score, a matched category, and the specific reasons each rule passed or failed. It replaces the human who would otherwise look at the photo — confirming in real time that the image shows the required real-world state, such as a correctly parked scooter, an undamaged panel, or a package placed at a door, so your code can gate a workflow on the answer rather than queue it for review.

If you've ever built a flow where a user uploads a photo and someone has to check it, you've felt the gap this fills. What follows is the developer view: how it differs from the identity-verification APIs that share the word "verify," how it works under the hood, and when reaching for one makes sense.

In brief

• The contract is photo in, structured verdict out — a decision your code can branch on, not a description of the image.
• "Photo verification" names two different jobs. Identity verification is about a person and a file; condition/compliance verification is about the state of an object or scene. VerifyAI does the second.
• Three layers do the work: vision models, an explicit policy-as-code ruleset, and a confidence-scored verdict.
• Because the policy is configuration rather than a model, you version it, review it in a diff, and vary it per city or per SOP without retraining anything.
• Deployment model is the biggest fork between vendors: server-side needs a round trip per image; on-device completes offline and syncs later.
• Pricing shape decides the economics at scale: per-image beats per-seat as soon as verification volume grows faster than headcount.

What a photo verification API does

It decides something about an image and hands you the decision. The contract is simple: photo in, structured verdict out.

You send an image (base64 or a multipart upload) plus a reference to the rules you want applied. You get back a machine-readable decision — typically a pass/fail outcome, the category it matched, and the specific reasons each rule passed or failed. No screen for a human to stare at; just a JSON response your code can branch on.

That's the key difference from "image storage" or "image upload." A storage API keeps the photo. A verification API decides something about it — and hands you that decision in a form you can gate a workflow on.

Condition/compliance verification vs. identity verification

The line is simple: identity verification is about who and whether the file is authentic; condition verification is about what state the thing in the photo is in. They share a word and almost nothing else.

In prose, "photo verification" gets used for two genuinely different jobs:

• Identity / deepfake verification (SwitchID, Truepic, Persona, Onfido-style flows) answers: "Is this the right person, and is this image authentic?" It matches a selfie to a government ID, checks liveness, and detects spoofing or manipulation.
• Condition / compliance verification (what VerifyAI does) answers: "Does this photo show the correct real-world state?" Is the scooter upright and in a legal zone? Is the vehicle panel damaged? Was the package placed at the door?

Same word, different problem. If you need to know who is in the photo or whether the file was tampered with, you want identity verification; if Stripe is on the shortlist, the SwitchID vs Stripe Identity comparison covers that identity-provider choice. If you need to know whether the thing in the photo is in the right state, you want condition/compliance verification.

How it works under the hood

Under the hood there are three layers: a vision model that reads the image, a policy that decides what the model's output means for your rules, and a confidence-scored verdict returned fast enough to gate a live action.

1. Vision models. The image is analyzed by computer-vision models trained to recognize the relevant objects and states — a scooter and its orientation, vehicle body damage, a package and where it's sitting.
2. Policy-as-code rules. The model output is evaluated against an explicit, editable ruleset — your policy. Each criterion ("not blocking the sidewalk," "no broken glass," "package placed at a location") has a severity and can be required or advisory. Because the policy is just configuration, you version it, diff it in code review, and tune it per city or per SOP.
3. A confidence-scored verdict. The result comes back as a structured decision — matched category plus per-criterion reasons — fast enough to gate a live flow. VerifyAI runs in under 200ms, on-device and offline-capable, so the check completes even with no connectivity and syncs later.

A minimal request and response looks like this:

curl https://verify.switchlabs.dev/api/v1/verify \
  -H "X-API-Key: $VERIFY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "policy": "scooter_parking",
    "image": "data:image/jpeg;base64,/9j/4AAQSkZJRg..."
  }'

{
  "id": "ver_8x92m4k9",
  "status": "success",
  "is_compliant": false,
  "confidence": 0.94,
  "policy": "scooter_parking",
  "category": "unsafe",
  "violation_reasons": ["blocking_sidewalk", "kickstand_up"],
  "feedback": "Please deploy the kickstand and move away from the walkway."
}

Field by field, and what each one is for:

Your code reads is_compliant (or the failed violation_reasons) and decides what to do — complete the ride, flag the vehicle, accept the delivery, open a dispute record. The feedback string is what you put on screen; the violation_reasons array is what you branch on. The verify endpoint reference documents the full request and response shapes, how verifications work covers the object model, and criteria explains how individual rules are written.

Common use cases

The common use cases are parking compliance, vehicle damage grading, proof of delivery, and asset condition logging — all variations on the same shape: a high-frequency photo check that doesn't scale by hand. A photo verification API is a fit anywhere a workflow currently depends on someone eyeballing an uploaded image:

• Parking compliance — confirm a shared scooter or e-bike is parked correctly at end of ride. This is VerifyAI's flagship; see micromobility parking verification.
• Damage grading — detect and grade vehicle damage at rental check-in/out or fleet handover. See vehicle damage inspection.
• Proof of delivery — verify a package was actually placed at the delivery location. See proof of delivery.
• Asset and condition logging — confirm equipment, sites, or returns are in the expected state. See equipment rental condition and insurance claim photos.

The common shape: a high-frequency photo check, where doing it by hand doesn't scale and doing it inconsistently creates disputes. The features page and the fleet management industry view map the pattern onto specific operations.

When to use one (and when not to)

Use one when the verdict must be programmatic, real-time, and consistent at volume. Skip it when you need identity verification, when an expert genuinely must adjudicate, or when the volume is small enough that a person can just look.

Reach for a photo verification API when the verdict needs to be programmatic and real-time — you're gating a user action (end ride, accept delivery, close out an inspection) on whether the photo is acceptable, and you can't wait for a human. Reach for it when consistency matters — manual review drifts between reviewers, and a policy-as-code ruleset applies the same standard every time. And reach for it when volume is high — at thousands of checks a day, per-image pricing beats both manual review and per-seat tooling.

It's not the right tool when you actually need identity verification (use an identity API), when a human genuinely must adjudicate a nuanced case (verification can route low-confidence captures to manual review, but it won't replace expert judgment on edge cases), or when you only have a handful of photos to check and a person can just look.

Pricing model

Per-image pricing is what makes an API cheaper than human review: cost tracks the number of photos you check, not the number of people you employ to check them. The reason an API beats human review economically is the pricing shape. VerifyAI is per-image, not per-seat: from about $0.008 per verification, dropping to $0.006 and $0.005 at volume, with no annual minimum (see pricing). Cost scales with how many photos you verify, not how many people are on your team — which is exactly the curve you want when verification volume grows.

To go deeper on the mechanics, the features and methodology pages cover how VerifyAI verifies images, and the glossary defines the terms you'll hit along the way — starting with photo verification API itself, plus before/after delta, on-device inference, and the AIAG damage grade. For data handling, see security and GDPR.

Try it in the sandbox

The fastest way to understand a photo verification API is to make a call.

Get an API key and verify your first image free — $5 sandbox credit, no card. Send a photo, read the structured verdict, and wire it into your flow. When you're ready, the quickstart gets you from key to first verified image in a few minutes, and the damage inspection API quickstart walks a full example end to end. SDKs are available for REST, Python, and Node.js.