Reports
Submit first-party feedback when Faro got it wrong — or when you know an artifact is bad. Reports feed the reputation graph: the next check on that node re-evaluates instead of serving a stale green verdict.
Use this when:
- Faro returned 🟢 but you know the link, payee, or message is malicious
- Faro returned 🔴 or 🟡 but the artifact is legitimate (
false_positive)
Submit a report
POST /v1/reports — Bearer auth, returns 202 Accepted.
curl -X POST https://api.farofinance.app/v1/reports \
-H "Authorization: Bearer $FARO_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"type": "url",
"value": "http://sbi-kyc-update.xyz/verify",
"kind": "phishing"
}'Request body
| Field | Type | Description |
|---|---|---|
type | url · payee · message | Same artifact types as verify |
value | string | The artifact to report |
kind | see below | Why you are reporting |
Report kinds
kind | Use when… |
|---|---|
scam | General fraud / scam |
phishing | Credential theft, impersonation links |
malware | Malicious download or site |
false_positive | Faro flagged something incorrectly |
other | Anything else worth recording |
Response
{
"accepted": true,
"artifact_id": "domain:sbi-kyc.xyz",
"message": "Report recorded. The next check on this artifact will re-evaluate."
}
artifact_id is the normalized reputation node (domain for URLs, lowercased payee
handle, content hash for messages) — the same key the engine uses for caching and tier-2
lookup.
What happens under the hood
- Stored — row in the
reportstable, tied to the normalized node. - Cache invalidated — any cached 🟢 or 🟡 verdict for that node is deleted immediately so the next verify call does not serve stale "safe."
- Future checks — tier-2 reputation emits a
reputation_reportssignal; multiple reports or other high signals can shift the verdict on re-check.