Why there is no endpoint
The model, the runtime and the analysis all download to the browser and run there. That is not a deployment choice that could be reversed with a flag; it is the whole architecture, and it is why an image never leaves the device it is checked on.
An API inverts that. Somebody sends an image to a server, the server scores it and sends a number back, and the image now exists on infrastructure somebody else controls, however briefly and however good their intentions.
For a tool whose entire proposition is that nothing is uploaded, offering an upload endpoint would be the product contradicting itself. So this page does not describe a roadmap; it describes a limit and what to do about it.
It is worth saying plainly because the alternative is worse. A page implying an endpoint that does not exist wastes an engineer afternoon, and the pricing page on this site already states there is no paid tier and no API.
What automation is actually for
Before reaching for an endpoint it is worth being precise about the job, because a good share of intended automation is better solved another way.
| Needs a service | Browser tool works | Human step is better | |
|---|---|---|---|
| Screening user uploads at scale | Yes Volume and latency | No | No |
| Checking a supplier delivery | No | Yes A batch of 25 covers it | Partly |
| Reviewing a claim bundle | No | Yes One batch per submission | Yes Judgement is the work |
| Auditing your own site | Partly Only if enormous | Yes Extract and batch | No |
Three of those four rows are satisfied by a person running batches, which is worth establishing before anybody writes code. The first row is genuinely different, and it is the one that needs a hosted service.
If you genuinely need automation
There are three honest routes, and each trades something different. Pretending otherwise helps nobody.
| Option | Trade | Suits |
|---|---|---|
| A commercial API | Images leave your infrastructure | High volume, low sensitivity |
| Self-host an open model | Engineering and hardware time | Sensitive data, in-house capability |
| Run it in a browser you control | Awkward but private | Moderate volume, strict privacy |
| Sample rather than screen | Coverage is partial | Most real workloads |
| A human review step | Slower, better judgement | Anything affecting a person |
The third row deserves explanation because it is underused. A headless browser running on your own machine, driving a page that does the analysis locally, is a legitimate way to automate without shipping images anywhere. It is unglamorous and it works.
The fourth row is the one most teams should choose and rarely consider. Screening every image is expensive and usually unnecessary; sampling ten per cent, plus everything from a source that has produced a problem before, catches most of what matters at a fraction of the cost.
If you self-host
This is more achievable than people assume, because the research models in this field are largely public. A checkpoint published with a permissive licence, an inference runtime and a modest server will reproduce most of what a commercial service sells.
What you take on is everything around the model. Keeping it current as generators change, calibrating a threshold for your own material, measuring your own false positive rate, and having somebody who can explain a result when it is challenged.
That last point is the hidden cost. A detection capability nobody in the organisation understands well enough to defend is a liability the first time a decision based on it is questioned, and that question always arrives eventually.
Whatever you build, build this in
Two design decisions matter more than which model you use, and both are about what happens after the score.
Never let a score decide anything about a person automatically. Route flags to a human, record what the human decided rather than what the model said, and make sure the person being affected can be told why something was queried.
And store outcomes, not scores. A searchable history of numbers attached to named users or suppliers is a profiling record that will need its own justification, adds no operational value, and becomes a problem the moment somebody requests their data.
A realistic starting point
For most teams that arrive here wanting automation, the sensible first version involves no engineering at all. One person, one batch per incoming submission, and a note in the file about what they found.
That produces something valuable within a week: a sense of what your own material scores. Almost nobody has that when they start, and without it any threshold you set in code is a guess about a distribution you have never measured.
Once you know where your images sit, the case for automation becomes concrete rather than theoretical. You will know how many submissions a week actually warrant a look, and often the answer makes the engineering unnecessary.
Where it does not, you will at least be automating against a measured baseline rather than a published one, which is the difference between a control that works on your data and one that works on somebody else benchmark.
What to measure before you build anything
Three numbers turn a vague intention into a specification, and all three come from running batches by hand for a fortnight.
The distribution of your own material: where genuine images from your normal sources actually land. Almost every team is surprised, usually because their inputs are more processed than they realised.
Your own false positive rate: how often a flag turns out to be ordinary processing when somebody investigates. This is the number that decides whether a control is usable on real people, and it is never the number on a vendor page.
The volume that would actually be flagged: how many items a week a human would need to look at. If that number is small, the automation you were planning is a spreadsheet and a habit.