Skip to main content

First-User Workflows

Who this is for​

This page is for new workspace operators who need the shortest path to useful value in Dralvia without turning on every module first.

Role-based start here​

  • SOC or incident triage: start with suspicious link triage.
  • Crypto or treasury reviewer: start with contract scan and pre-sign review.
  • AppSec or engineering reviewer: start with repo scan and exports.
  • Operations lead: start with reports, EvidencePacks (Dralvia's exportable evidence reports), and repeatable handoff flows.

Before you start​

  • Confirm you have platform access and an API key if you want automation.
  • Pick one real workflow to validate first.
  • Decide who will own the first report or escalation outcome.

This guide is the shortest path to proving Dralvia value without rebuilding your platform.

Step-by-step​

  • Run #/phishing or POST /scan for a suspicious URL or domain.
  • Confirm the verdict, explanation, redirect context, and EvidencePack.
  • If the result needs action, move straight into #/reports or #/escalations.

2. Wallet and pre-sign review​

  • Use #/contract when you need a fast contract posture view.
  • Use #/pre-sign before any approval, permit, or token transfer.
  • Focus on readable actions, operator grants, asset deltas, and the recommendation summary.

3. Repo and CI gating​

  • Upload a zip to #/repo-scan or POST /repo/scan/upload.
  • Export SARIF/SBOM for downstream tooling.
  • Suppress only confirmed noise; keep the raw vs effective risk distinction visible.

4. Email review​

  • Route suspicious mail to #/email-protection or POST /email/protect.
  • Use the remediation guidance as the human handoff point.
  • Save the resulting EvidencePack when the message becomes an incident candidate.

Sample integrations​

Repo CI gate:

bash examples/integrations/repo_scan_ci.sh

Unified scan plus downstream webhook:

python3 examples/integrations/unified_scan_webhook.py

Node service bootstrap:

node examples/integrations/unified_scan_service.mjs

Day-2 operations​

  • Repeat the same workflow on fresh inputs instead of testing every module once.
  • Save the EvidencePack or report bundle for anything that changes a real decision.
  • Review false positives and noisy findings before expanding rollout.

Self-check playbook​

  • Can a new operator run one scan without help?
  • Can they explain why the result matters?
  • Can they export or share the result with another team?
  • Can they repeat the same flow the next day with less friction?

What each button does​

  • Scan starts a new investigation for the selected surface.
  • Export or Download creates a portable artifact for another team or tool.
  • Send to Security forwards the result into the security review path.
  • Open Platform takes you to the full workspace for follow-up actions.

Troubleshooting​

  • If a scan stalls, retry once and check status.dralvia.tech for maintenance or outage state.
  • If a result is too shallow, confirm the input is the right object: URL, contract, approval, or repo archive.
  • If exports are missing fields, keep the raw result and open the report or EvidencePack flow instead.

API and automation​

  • POST /scan for suspicious URLs and domains.
  • POST /contract/scan and POST /web3/txsimulate for smart contract review.
  • POST /repo/scan/upload for repository intake.
  • Use one webhook or CI example only after the manual workflow is clear.

API error quick reference​

  • 401 Unauthorized: your session or API key is missing, expired, or not scoped correctly.
  • 403 Forbidden: your current role can sign in but cannot use the requested workflow or export.
  • 404 Not Found: the requested artifact, result, or workflow object is no longer available.
  • 429 Too Many Requests: your workspace hit a usage or rate limit on the selected workflow.
  • 500 Internal Server Error: the workflow backend failed while processing or exporting the result; retry once, then escalate with the timestamp.

Next best actions​

Related guides:

What to avoid early​

  • Do not try to turn on every module on day 1.
  • Do not spend the first week wiring up every long-tail configuration screen.
  • Do not hide quota and report flows from the people validating the pilot.
  1. API key
  2. One live scan
  3. One report bundle
  4. One webhook or CI example
  5. One repeatable operator workflow

Design-partner onboarding checklist​

Day 1​

  • Run one live scan against a real suspicious input.
  • Validate a second workflow that matters to the same buyer.
  • Open one report, evidence bundle, or approval preview.
  • Leave one support or product feedback note.

Day 30​

  • Return across multiple days, not just the kickoff session.
  • Use at least three core workflows.
  • Keep support noise low enough that the workflow still feels usable.
  • Reuse reports, evidence, or approval previews as part of normal decision-making.

FAQ​

Should we validate every module on day one?​

No. Validate one painful workflow first, then expand.

What is the best first proof of value?​

One real decision made faster and with better evidence than before.

When should we automate?​

After the manual flow is understandable and repeatable.

Next steps​

  • Pick the strongest first workflow for your team.
  • Run it on a real input.
  • Export the result.
  • Decide whether to deepen that same flow or move to a second one.

Known limits and rate limits​

  • Plan quotas apply: scan, render, report, repository, and API-key limits follow your plan tier. See Pricing & Plans for the enforced defaults.
  • API requests are rate limited per workspace. A 429 Too Many Requests response means a rate or quota window was exceeded; wait for the reset window, then retry once and reduce burst volume.
  • Free Evaluation has the tightest limits and is subject to anti-abuse controls. Paid plans raise the limits; Enterprise sets custom limits by contract.