Visora

Visora scores any image and returns a decision your product can act on directly: allow, review, or reject. Under the hood it runs Amazon Rekognition to detect unsafe content - nudity, violence, weapons, drugs, hate symbols and more - and layers a policy engine on top that turns raw labels into a real decision.

What makes it useful is not the detection, it is the control. Each project defines its own policy: which categories are blocked, the action each one takes (allow / review / reject), minimum confidence, and risk thresholds. Teams can apply compliance packs (marketplace, kids, dating, and more) and a brand-safety signal, so the same API returns a very different verdict for a kids' app than for a marketplace - with zero custom code.

Redaction detects and removes sensitive regions from an image, then returns a clean, processed version. In a single call, Visora finds faces, text, license plates and specific PII (IDs, emails, dates, financial and medical data) and blurs or black-boxes them in place - so the original never has to leave your pipeline.

Like moderation, it is fully configurable per project: choose the blur targets, the redaction style (blur or black box), which text categories to redact, custom words to always hide, and words to keep visible. The API returns a redacted image URL plus the coordinates of everything it covered.

Verification checks an identity document against a selfie in a single request and returns one decision: verified, review, or rejected. It runs three checks - document authenticity and field extraction with Amazon Textract, a face match between the selfie and the document portrait with Rekognition CompareFaces, and selfie quality / anti-spoof signals with DetectFaces.

Thresholds are configurable per project (auto-approve similarity, reject cutoff, expired-document handling), and the response includes the extracted document fields, the face-match score, and human-readable reasons for anything not auto-approved. Logs are privacy-preserving by design - the raw PII fields are never stored.

Visora ships an official TypeScript SDK (@visoracloud/client) so any product is a few lines of code away from a running backend. It handles multipart uploads, authentication, typed responses and errors, and even verified webhook handlers - so developers never touch the raw HTTP layer.

This matters because Visora competes on adoption: the faster a developer gets from npm install to a real decision, the more likely they are to ship it. moderateImage(), redactImage(), verifyImage() - same shape, same client, one key.

Every product has its own developer documentation - moderation, redaction, verify and webhooks - with copy-paste examples (SDK and cURL), response models, configuration reference and webhook signatures. It is a three-column, searchable live experience built to get a developer productive without leaving the page.

The playground runs a real image through any of your projects directly in the dashboard - no code required. It uses the project's own configuration, so what you see is exactly what the API will return. For verification it takes a document and a selfie; for moderation and redaction, a single image, with a live preview before upload.

Everything in Visora is organized around projects. A project is a moderation, redaction or verify workspace, each with its own configuration, API keys and logs. This is where the platform's flexibility lives: instead of raw model output, every project shapes its own decision - category actions and risk thresholds for moderation, blur targets for redaction, match thresholds for verify.

Every request - moderation, redaction and verification - is logged and browsable, with a detail drawer to inspect the decision, the detected regions or labels, the images, and the exact settings that produced the result. It is an audit trail and a debugging surface in the same place.

When a policy lands on the review action, the result is queued instead of auto-resolved. A built-in review queue lets a person approve or reject flagged content, and the decision fires a webhook so downstream systems stay in sync.

API keys are scoped to a single project, so a moderation key can never touch a verify project. Keys can be created, rotated and revoked from the dashboard, and every request is authenticated and counted against the account's plan.

Visora delivers events (moderation.completed, redaction.completed, verification.completed, review decisions...) to your endpoints in real time. Every delivery is HMAC-signed, sent asynchronously through a queue, retried on failure, and moved to a dead-letter queue after repeated failures - so a slow or failing endpoint never blocks the API response. The SDK verifies the signature and narrows the payload by event type for you.

Visora runs on a usage-based model: a free tier to try every product, and paid plans with per-product limits and overage. Verification is billed per verification (premium), while moderation and redaction share a monthly request pool. Billing is handled through Stripe - checkout, subscriptions and a customer portal - with usage surfaced live in the dashboard.

The frontend is a Next.js app exported to static assets and served from S3 behind CloudFront. There is no server-side rendering at runtime - it is pure static + client-side, talking to the backend over the API.

That means the frontend costs almost nothing to host, is distributed globally by the CDN, and has nothing to patch; every dynamic behavior (auth, dashboard data, playground) happens through API Gateway calls from the browser.

Registration creates two things: the user in Cognito (credentials and identity) and the account in DynamoDB (the business record plus an identity mapping). For email/password, the browser hits POST /auth/register, the Auth Lambda calls Cognito SignUp, Cognito triggers SES to email the verification code, and the same Lambda writes the account (accounts) and the identity mapping (account-identities).

The user then confirms via POST /auth/confirm. OAuth registration works two ways: GitHub goes through the backend (/auth/github/exchange, which issues an app-signed JWT), while Google is federated entirely through Cognito's hosted UI, without touching the backend.

Login is deliberately lean. POST /auth/login goes to the Auth Lambda, then Cognito InitiateAuth, which returns the JWT (id / access / refresh) straight back to the browser. There is no SES and no DynamoDB write - the account already exists.

OAuth login reuses the same exchange endpoints as registration. They are idempotent: an existing account is found, and a new one is created when needed.

Every dashboard request carries an Authorization: Bearer <idToken>. The Dashboard Lambda validates the token locally against Cognito's JWKS (the public signing keys, cached - not a call to Cognito per request), then resolves the account from DynamoDB and does the work.

The key property here is that authentication is stateless and local: the signature is verified in-process, so auth adds no network round-trip and scales for free with the rest of the platform.

Both products are synchronous, single-Lambda pipelines authenticated with an x-api-key. In one invocation, the Lambda stores or references the image in S3, calls Rekognition, applies its logic, writes a log to DynamoDB, publishes a webhook event, and responds.

Moderation uses DetectModerationLabels with a policy engine that turns labels into allow / review / reject. Redaction uses DetectFaces + DetectText, then Sharp blurs the detected regions, writes the processed image to a second S3 bucket, and returns a presigned URL. There is no S3-event trigger - the Lambda orchestrates everything inline and synchronously.

Webhook delivery is asynchronous, so it never blocks the API response. When a product finishes, its Lambda writes the event to DynamoDB (webhook-events) and enqueues the eventId to SQS, then returns immediately.

SQS triggers the Webhook Worker Lambda, which reads the event and the project's subscribed endpoints, HMAC-signs the payload, and POSTs it to the customer's URL. Failed deliveries are retried by SQS and moved to a dead-letter queue after repeated failures; the dashboard surfaces failed events by reading them back from DynamoDB.

Billing runs in two directions. User actions from the dashboard, authenticated with the Cognito JWT, go through the Billing Lambda to the Stripe API - creating a checkout session, subscription or customer portal - and return a hosted Stripe URL.

In the other direction, Stripe calls back to /billing/webhook, verified with Stripe's signature rather than a JWT, and the Billing Lambda updates the account's plan and subscription status in DynamoDB and logs the event. Stripe stays the source of truth for payment; DynamoDB is kept in sync through the webhook.