SynthID and VeracityAPI
Watermark provenance vs workflow routing — designed to layer, not replace. These two technologies answer different questions in the same workflow. This page is a layered-integration guide written by someone who builds in this space; the goal is to help you fit each layer where it carries weight, not to argue for one over the other.
I think the SynthID-vs-VeracityAPI framing is genuinely the wrong frame, and I'd rather use this page to make the layered picture explicit than to pretend it's a head-to-head. SynthID is the strongest signal in this whole space when the conditions for it hold — content came from a participating Google model, the watermark survived whatever processing happened between generation and your pipeline, and the detector confirms it. When those conditions hold, you should use it. The honest question is what to do for the long tail where they don't hold: non-Google generators, stripped watermarks, screenshots of AI images, transcribed audio, edited content, all of which dominate by volume in real content pipelines. That's the space VeracityAPI is built for. The clean mental model: SynthID answers 'did a specific generator produce this'; VeracityAPI answers 'what should my code do with this content regardless of generator.' Different questions, both worth answering, often in the same workflow.
What SynthID is designed for
- Confirming whether supported media was generated or edited by participating Google AI systems (Imagen, Lyria, Veo, and other supported Google media outputs) when the watermark is still intact
- Newsroom and trust-and-safety teams running supported image, audio, and video files through Google's SynthID verification surfaces to check for the Google watermark
- Provenance audits where the question is 'did a specific cooperating generator produce this artifact' and a hard, model-side signal is the right primitive
- Generative-AI platforms that own the inference path and can embed SynthID at the moment of generation
What VeracityAPI is designed for
- Workflows that need a routing decision when no watermark is detected — the dominant case in mixed-source content pipelines
- Programmatic content factories and agent pipelines deciding allow / revise / human_review / reject without a human in the loop
- Content that arrived after recompression, editing, screenshotting, or non-cooperating-model generation, where any watermark may have been weakened or never embedded
- Multimodal triage (text + image) under one routing contract, regardless of whether a watermark is present
Where SynthID is the right tool
- Hard, model-side provenance signal when content comes from a cooperating Google model and the watermark is intact — nothing VeracityAPI does competes with that primitive
- Cross-modality coverage from a single source-of-truth: Imagen, Lyria, Veo, and Gemini all share the SynthID infrastructure
- Origin-of-content question that VeracityAPI explicitly doesn't answer — VeracityAPI is a workflow-risk signal, not an authorship or generator proof
Where VeracityAPI is the right tool
- Coverage when the watermark is absent: stripped by recompression, never embedded by a non-cooperating model, weakened by heavy editing, or simply not applicable to text generated by non-Google models
- Action-shaped output (allow / revise / human_review / reject) designed for code branching, where SynthID's detection signal still requires a downstream routing decision
- Per-call workflow-risk scoring that scales for programmatic pipelines (50+ pages/day, RAG ingestion at chunk scale, agent rewrite loops)
- Evidence-array-as-rewrite-prompt for the auto_revise text loop — a use case watermarking doesn't address
Modality coverage
SynthID is a generation-side watermark scheme for supported Google AI outputs, with public verification surfaces currently centered on supported image, audio, and video files. Coverage is bounded by which models participate, which modalities the verifier supports, and whether the watermark survives downstream processing. VeracityAPI covers text and image URLs with one routing contract — content-side, no cooperation needed from the generator. The two technologies operate at different layers of the stack: one at production, the other at consumption.
Output design
SynthID returns a detection signal indicating whether a specific watermark is present in the artifact — a hard, model-side answer about origin. VeracityAPI returns recommended_action (allow / revise / human_review / reject) plus an evidence array — a soft, content-side answer about workflow risk. Both shapes are appropriate for their job: 'is this from a known generator' (provenance) and 'what should my code do with this' (routing). Most production workflows benefit from both, in that order.
Pricing notes
- SynthID: Google provides verification surfaces such as Gemini checks and the SynthID Detector portal / early tester program for supported Google-watermarked media; the watermark itself is embedded at generation by participating Google services rather than billed like a third-party scoring API.
- VeracityAPI: usage-based. Text $0.005/1k chars analyze-only, $0.010/1k chars with auto_revise. Image $0.02. Different pricing models because the products solve different problems — one is a watermark check, the other is a per-call routing decision.
How to layer them
- Don't think of this as a migration — these are two different layers and most teams should run both. The integration pattern: check SynthID first when you have a Google-watermarked artifact and a hard origin signal would change your routing; fall back to VeracityAPI when the watermark is absent, weakened, or the content is from a non-cooperating generator.
- If you're piping inbound user-generated content through a moderation queue, SynthID can flag the subset that originated from a participating Google model. VeracityAPI scores the entire stream for workflow risk regardless of generator. The two signals are independent and can be combined in your routing logic.
- For agent workflows specifically: SynthID's signal is binary (present / not present / weak); VeracityAPI's signal is an action label. In most agent pipelines, an 'AI watermark present' result still needs a downstream routing decision — that's where VeracityAPI's recommended_action picks up the workflow.
FAQ
Is VeracityAPI a SynthID alternative?
No, and I want to be specific. SynthID is a watermarking technology for content generated by cooperating Google models. VeracityAPI is a workflow-routing API for any content, regardless of generator. The 'alternative' framing implies a substitution that doesn't make sense — most production pipelines benefit from running both, with SynthID handling the cases where its conditions hold and VeracityAPI handling the cases where they don't.
Can I use both together?
Yes — this is the integration pattern I recommend for any team that processes content that might come from Google models. Check the SynthID Detector for the artifact first; if the watermark is present and confirms a Google origin, route on that strong signal. If the watermark is absent or weakened (which will be true for most content in mixed-source pipelines), call VeracityAPI for the workflow-risk score and route on recommended_action. The two signals stack cleanly because they answer different questions.
Does VeracityAPI check for the SynthID watermark?
No, not in v0.1. VeracityAPI's content-side signals (specificity, provenance weakness, synthetic-media cues) are independent of whether any watermark is present. Watermark-aware inspection is on the v0.2 roadmap for image and video alongside EXIF and C2PA Content Credentials. Until then, run SynthID Detector for the watermark check and VeracityAPI for the routing decision separately and combine the results in your workflow.
What happens if the watermark gets stripped?
Watermarks like SynthID are robust against many transformations (compression, mild edits, format conversions) but not all of them — heavy recompression, deliberate adversarial removal, screenshotting, and significant editing can weaken or strip the signal. The honest answer is that any content-provenance system has a robustness envelope, and content that arrives outside that envelope ends up in the same routing bucket as non-watermarked content. VeracityAPI's role is to score workflow risk for that bucket — not to replicate the watermark check, but to give your pipeline an action label when the watermark isn't load-bearing anymore.
Why doesn't VeracityAPI watermark its own outputs?
VeracityAPI doesn't generate content — it scores content other systems generate. The auto_revise feature returns rewritten text, but that text is produced by an upstream LLM provider whose own watermarking decisions are upstream of us. If your team needs every piece of generated content in your pipeline to carry a watermark, that's a decision to make at the generation layer (which LLM you use, what their watermarking policy is) — VeracityAPI sits at the publishing-boundary layer, downstream of that choice.
Should I prefer SynthID's hard signal over VeracityAPI's soft signal?
When SynthID's hard signal is available and the result is unambiguous, yes — a hard signal beats a soft signal every time, and that's not a controversial claim. The reason VeracityAPI exists is that the conditions for that hard signal are not met for most content in mixed-source pipelines. Non-Google generators, edited content, screenshots, transcripts, and the long tail of UGC are where the soft signal becomes the operationally useful one. Most teams should layer both rather than choose.