Introducing shared SaaS risk signals
Your SaaS risk API checks risky emails, accepts verified abuse reports, and learns from dispute outcomes so checkout, signup, refunds, and support stop flying blind.
POST /check
Authorization: Bearer frddb_live_...
FRDDB-Version: 2026-05-06
{
"email": "buyer@example.com",
"context": {
"event": "signup",
"amount": 4900,
"currency": "USD"
}
}{
"risk_score": 72,
"risk_level": "high",
"confidence": 0.81,
"summary": {
"report_count": 4,
"reporting_org_count": 3
},
"recommended_action": "manual_review"
}Simple. Evidence-backed. Fast.
Same Codeforge rhythm: show the workflow first, then explain why the system exists. For FRDDB, the story is check, report, correct, and control.
Call the API with an email and context. FRDDB returns risk, confidence, reasons, and the action your product should take next.
POST /check
FRDDB-Version: 2026-05-06
{
"email": "buyer@example.com",
"context": {
"event": "checkout",
"amount": 4900,
"currency": "USD"
}
}Paid, authenticated organizations submit evidence-backed reports. That billing gate keeps the database useful instead of turning it into an angry spreadsheet.
POST /reports
Idempotency-Key: dispute_8A21
{
"email": "buyer@example.com",
"category": "chargeback",
"evidence_type": "stripe_dispute",
"occurred_at": "2026-05-04T12:00:00Z",
"amount": 9900,
"currency": "USD"
}Won disputes, false positives, retractions, and verified customer outcomes update the subject summary and cache immediately.
POST /outcomes
FRDDB-Version: 2026-05-06
{
"report_id": "rep_123",
"outcome_type": "dispute_won",
"occurred_at": "2026-05-06T12:00:00Z",
"metadata": {
"processor": "stripe"
}
}Admin-only key creation, usage logs, and entitlement checks keep lookups, reports, billing, and audit trails tied to the correct organization.
POST /dashboard/api-keys
{
"name": "production-checkout",
"scopes": ["lookup", "report"],
"mode": "live"
}Workflow
Codeforge says “clone and activate.” FRDDB says “drop the check into the path where money or access changes hands.” Same template idea, different product truth.
Step 1
Drop /check into signup, checkout, refund, support, and high-usage events. One clean response gives the product a decision without leaking raw evidence.
Step 2
Reports require auth, entitlement, category, timestamp, and evidence type. Weak reports stay out of the signal path.
Connect 1
Payment, auth, support, and product events all feed one risk surface without making the API path ugly.
Connect 2
Normalize email, hash with a server-side pepper, encrypt notes, and only expose explainable risk summaries.
Feature detail
FRDDB is not a “someone annoyed me” button. Reports need entitlement, structure, auditability, and a way to be corrected.
Reporting is gated by org entitlement, so drive-by reports do not wreck everyone else's risk checks.
A risky subject with one old report is not the same as a risky subject with multiple fresh verified reports.
Setup. Connect. Check. Report.
Three steps, no bloated portal story. The important part is getting the API into the money path and keeping report creation controlled.
Invite the teammates who can manage billing, keys, and reports. Missing admin role means forbidden, as it should.
Start with signup and checkout. Expand to refunds, coupons, support escalations, and usage spikes once you see the signal.
Send dispute results and false positives back to FRDDB so future checks improve instead of freezing yesterday's answer.
Early access
Launch pricing configured in Stripe
One-time payment for early customers
Plan
Monthly plan
For teams proving risk controls in production
Plan
Higher quota
For products where abuse volume is already obvious
Compare
Your spreadsheet can remember bad customers. It cannot safely share signal across organizations, enforce reporter entitlement, or update stale risk through outcomes.
| Capability | FRDDB | Spreadsheet | Generic dispute tool |
|---|---|---|---|
| Shared cross-SaaS signal Risk from more than one product surface. | Yes | No | Partial |
| Paid report entitlement Prevents noisy anonymous reporting. | Yes | No | No |
| Dated API version header Stable clean endpoints without path-prefix churn. | Yes | No | No |
| Outcome correction loop False positives, reversals, and wins can update the score. | Yes | Manual | Partial |
| Privacy-first identity model Hashed subject identity and encrypted report notes. | Yes | Maybe | Unknown |
Short answers for the stuff that matters before you let customers report other customers.
No. It is an API for authenticated SaaS organizations. The response is a risk decision surface, not a public wall of shame.
Yes. That is the right default. Lookups can have separate plans, but report creation should stay behind a paid organization entitlement.
Not by default. Emails are normalized and stored as a peppered HMAC identity. Report notes are encrypted.
The public API stays clean. Breaking behavior is controlled with the FRDDB-Version request header.
Usually step-up verification, manual review, usage limits, or delayed fulfillment. Auto-ban should be rare because false positives are expensive.
Paid reporting, audit trails, reporter trust, evidence requirements, retractions, and outcome feedback. That is the whole game.
Founder lifetime
Lifetime means lifetime access to a bounded plan. Infinite usage is how you end up debugging your billing bill at 2am.