Shapo vs. ShowTrust: Collecting Video and Text Testimonials

A head-to-head comparison that settles whether Shapo or ShowTrust fits your testimonial pipeline — video requirement, proof display model (wall of love vs widgets), collection entrypoint, workflow and moderation, imports and portability, install/API/automation surface area, plus a decision table so you can commit without “coming soon” surprises.

Sev LeoLinkedInTwitter

Founder and sole developer of ShowTrust.to and Skribra.com

Non-negotiables first

This matchup rarely gets decided by price alone—it gets decided by what is shipped and operational today versus what you’re willing to verify (or wait for). Shapo vs. ShowTrust usually comes down to four hard requirements: video timing, whether you’re importing an existing library, how you want to display proof on-site, and what plan caps/branding you’ll tolerate.

Video requirement

If video is required now, Shapo is the safer fork. It supports video collection through a collection form setting (“Accept Video Testimonials”) and then lets you manage/moderate those video submissions in the dashboard, with approved items flowing into widgets automatically.

If video can be “verify and then commit,” treat the other product’s video story as a live-check item. Its homepage FAQ says video testimonials are “Coming soon” and “Not shipped yet,” but its Features page also claims in-browser video capture (including a 90-second limit) plus transcoding and transcription. That contradiction is the line: if video is non-negotiable, you don’t want to discover the gap after you’ve already built the request flow.

Proof display model

Decide what “good enough” proof looks like on your site.

A Wall of Love is a public page (or on-site section) that displays multiple testimonials together so prospects can scan real proof quickly. Both tools play in this model: you collect testimonials, approve/curate, then publish a wall and embed smaller widgets where they matter (homepage, pricing, checkout).

Where the difference shows up is performance posture and limits. The other product explicitly positions its widget as performance-first: it claims the script is under 5kb gzipped, lazy-loads, and renders server-cached HTML.

Collection entrypoint

A collection page / collection form is the page customers land on to submit a testimonial (text and/or video) via a link you share. Your non-negotiable here is control: can you ask the fields you need (name/company/role), capture permission/consent, and avoid extra friction?

Also decide whether plan caps are acceptable in the collection flow. Shapo’s Free plan is “up to 10 testimonials” and includes Shapo branding; once you hit the free testimonial limit, incoming testimonials “will not be visible.” If you can’t risk submissions silently piling up unseen, bake that into your choice (or your upgrade decision) upfront: https://shapo.io/pricing rel=“nofollow”.

Finally, if automation is non-negotiable (API + webhooks), get concrete about what you’ll actually implement: ShowTrust’s v1 API auth expects x-showtrust-account-id plus x-api-key, while Shapo uses Authorization: Bearer <YOUR API KEY>. And for “webhooks,” confirm there’s a documented, working event you can subscribe to—not just a marketing checkbox.

Workflow and moderation

The workflow you’re buying is: someone submits → it lands in an approval queue (a moderation state where new submissions are captured but not publicly visible until reviewed) → you publish the approved items to your site.

With Shapo, that “pending → approved → live” path is explicit for video: you enable video collection in a form, submissions are managed/moderated in the dashboard, and approved video testimonials then flow into widgets automatically. That’s the kind of governance model teams like because it’s hard to accidentally publish the wrong thing, and once you approve it, it becomes usable proof without extra steps.

With ShowTrust, the mechanics skew toward speed and manual control. In the v1 API, when you create a testimonial via POST /v1/projects/:id/testimonials, it’s created with status: "approved" and is visible immediately—equivalent to adding it manually in the dashboard. The flip side is governance is less “automatable”: approve/reject/pin/edit/delete actions are dashboard-only (not exposed in v1), so you can’t build a fully programmatic moderation pipeline.

If your priority is strict review gates, Shapo’s moderation-first publishing is clearer. If your priority is predictable speed to “live,” the immediate-approved path is hard to beat—as long as you’re comfortable that some ingestion routes can bypass “pending.”

Video: shipped or not

Video is the one area where you should treat public pages as hypotheses, not guarantees—especially when one product simultaneously says video testimonials are “Coming soon” / “Not shipped yet” and also describes in-browser capture (including a 90-second limit) plus transcoding and transcription. When the story conflicts, the only safe move is a quick in-product test before you build your request flow around it.

• Treat “coming soon” and “we shipped it” as two separate claims. One product’s changelog has an entry titled “Collect text & video testimonials” dated May 20, 2026. That’s useful context, but it’s not the same as confirming that new accounts can capture, store, moderate, and publish video reliably today.

• Compare that to Shapo’s video documentation (it’s operational, not aspirational). Shapo’s help center describes an “Accept Video Testimonials” toggle inside a collection form, and says submitted videos can be moderated in the dashboard and then displayed across widgets once approved. That’s the kind of “here’s the switch, here’s the lifecycle” detail that reduces rollout risk. (See how to collect video testimonials.)

• Run this live-test checklist (15 minutes, no debating).

• Recording: Can you record in-browser on both desktop and mobile, and does it complete without retries?

• Re-recording: Can the submitter discard and re-record before submitting (without refreshing the page)?

• Playback: After submission, does the video play back cleanly in the dashboard and in the published widget?

• Moderation: Can you keep a video private (pending/rejected) and confirm it does not render publicly until approved?

• Storage & persistence: Does the video still play the next day, and can you delete it and confirm it’s gone everywhere it was embedded?

• One practical constraint to note if you’re API-heavy. Shapo rate-limits its API for adding testimonials (30/hour) and its GET endpoints (60/hour), which matters if you plan to sync or backfill lots of content programmatically.

If video is truly non-negotiable, prefer the product that can show you a working capture → approve → publish loop in your own account, not just a changelog headline.

Imports and portability

If you already have a backlog of reviews, the import story is where “easy to start” turns into “easy to live with.” Shapo is built for backfilling: it supports importing reviews from 25+ sources (Google, Trustpilot, G2, Capterra, and more), so you can move an existing library in without re-collecting it.

The other product is murkier today. Its public pages don’t line up: you’ll see “imports coming soon” for things like Tweet URL/CSV, while other pages imply X/LinkedIn imports exist, and its changelog later references filtering by publisher and sources that include X/LinkedIn imports. That’s a lock-in signal of a different kind: you may be committing before you can prove you can bring your history with you.

If you’re importing via API, watch for “migration ergonomics,” not just whether an endpoint exists. Shapo’s API import runs in the background (processing: true), but it does not return a job ID (a unique identifier for tracking a long-running import) and it does not offer a completion callback (an automatic HTTP notification when the import finishes). The documented path is polling the GET testimonials API to confirm what landed. (Details: import reviews using the Shapo API.)

On the flip side, the other product’s v1 API is a viable DIY migration path if you can’t wait for URL/CSV imports—but it’s also strict: authenticated calls require both an account ID header and an API key, and API keys are shown once and regenerating the key invalidates the previous one immediately. If you’re planning a big backfill or future re-platform, that’s the stuff that determines whether moving proof is a one-time project or recurring friction.

Install, API, automation

Embed model (and what you actually paste)

An embed snippet—the script (and sometimes a container element) you paste into your website so testimonials render on your page—is where the “easy install” story either holds up or falls apart. ShowTrust positions this as a single snippet, but the documented shape is effectively two pieces: a script plus a container div. That’s still a straightforward copy‑paste in most stacks (and a common pattern for embeddable widgets), but it matters if you’re injecting it through a CMS that only allows one of those locations.

On performance posture, the same widget is positioned as lightweight: the script is claimed to be under 5kb gzipped, plus lazy-loading and server-cached HTML. Those are the kinds of implementation choices that can keep social proof from becoming a performance tax—still, treat it as a claim you can validate quickly in your own pages (network waterfall + Core Web Vitals), not a guarantee.

API auth and agent-based setup

If you want “install by automation,” the standout is agent-init—a public API endpoint that lets an AI agent sign a user up and obtain API credentials from an email. The documented ShowTrust API authentication flow rejects disposable-email domains and is tightly rate-limited: 5 requests/hour per IP and 3 requests/hour per email. The companion “skill” (a single markdown file) can configure a project/widget, fetch the snippet, and inject it into Next.js (App Router/Pages) (see Next.js App Router integration guide), Vite + React, Astro, or plain HTML—which is genuinely useful if you’re trying to roll out a consistent testimonial collection + display flow across multiple properties—but there’s a hard lifecycle constraint: if the user doesn’t claim the account via magic link, the widget stays live for 3 days and then stops rendering.

Authenticated API calls use x-showtrust-account-id plus x-api-key. Plan for API key rotation—replacing an API key so the old one stops working immediately—because agent retries, leaked keys, or team handoffs will force it.

Automation surface area (and what’s missing)

A webhook—an event push (HTTP POST) sent to your server when something happens (like a testimonial submission)—is the difference between real-time automation and polling. The marketing claim includes “webhooks,” but the API reference doesn’t document webhook endpoints, event types, signatures, or retry behavior. If automation is a hard requirement, that documentation gap is a risk you should price in (and one to clarify early), even if your initial workflow can tolerate manual approval/curation and periodic syncs.

Decision table

In this table, “the other tool” refers to ShowTrust.

Who Shapo is best for: teams that need video capture working today (capture → approve → publish) and want to backfill from 25+ review sources—and who are comfortable with Shapo’s Free plan cap (up to 10 visible testimonials) as the tradeoff for a more “shipped” feature set.

Choose based on what’s shipped

If your goal is to publish believable proof quickly with minimal install friction, ShowTrust is the cleaner default—especially when you’re text-first and want a performance-minded embed plus a fast path from collection link to on-site Wall of Love. Just don’t commit on promises: before you wire your request flow, verify in your own account the items its public pages treat inconsistently (video, imports, and any “webhooks” automation). If video has to work end-to-end on day one—or you need a proven backfill path from existing review sources—pick Shapo and accept the trade-off of its free-plan visibility cap. Your first move: write down your non-negotiables, then run one live test (video capture → approve → publish, or import/backfill → display) and choose the tool that passes without creating a new moderation chore.