Safest
View on GitHubMap a report flow
All guides

Use cases and implementation

Connect reports, evidence and application actions

Connect intake, signed context, evidence services, and idempotent application callbacks.

For
Product engineers, trust and safety engineers, security teams and integration owners
Last updated
29 August 2026

01

Starting point

Your product already owns users, messages, listings or workspaces. Safest Resolve should receive an explicit report and request only the context needed for the published workflow, while your application remains the source of truth.

02

What must hold

  • Putting a server API key in browser code or trusting an unsigned application reference.
  • Copying broad user or content records when the workflow needs a few named fields.
  • Retrying an application action without an idempotency key or closing before the callback confirms the result.

03

Step by step

  1. Choose the intake path: embed /widget.js, link to /report/, or submit from your server to /v1/reports/server.
  2. Create a least-privilege integration. Keep server credentials on your backend; for the widget, mint a short-lived context token containing stable application references.
  3. Submit a structured allegation with an idempotency key and retain the returned report and tracking references in your own support or product record.
  4. Define each evidence component with an explicit input allowlist, bounded response schema, timeout and immutable version. Verify signed requests before returning a typed finding.
  5. Create separate integrations for evidence_callback and action_callback. A credential allowed to submit reports does not receive callback authority automatically.
  6. Publish routing fixtures and their exact revision, publish the visual workflow, then pin that workflow version and operating policy to the destination queue.
  7. Exercise a successful report, duplicate intake, enrichment timeout, action retry, reporter message, human claim and appeal before releasing the integration.

04

Operating boundary

Use opaque references where possible. Required evidence failures block decisions, high-impact actions wait for authorized people, application calls are idempotent, and every callback records an explicit pending, succeeded or failed state.

05

Data exchange

Safest Resolve sends a stable reference in a signed, time-bounded request. Your service verifies the signature and returns only the schema-approved fields. Action requests use a separate signed connection and stable idempotency key; the application callback records what actually happened.

Stable referenceSigned requestTyped result

06

Verification

A report moves from your product into a versioned queue and durable workflow. The case record shows the evidence version, current owner, decision, requested action, confirmed result, participant messages and any appeal without duplicating your product database.

07

Implementation questions

Can we keep our current report form?+

Yes. Submit its structured output through the authenticated server API and preserve your external case reference.

Which credentials can complete callbacks?+

Use dedicated least-privilege integrations. evidence_callback and action_callback are separate capabilities and are never implied by submit_reports.

Safest Resolve

Start with one report your team handles today.

Bring its source, required evidence, decision owner, application action, messages, and appeal path.