Consent Capture API

Use your organisation's API key. The contact is matched by your own id, email or phone, else created. Send nothing (show the link yourself) or let us send it.

POST https://api.scrutora.com/api/v1/forms/{form_id}/invitations
Authorization: Bearer sk_live_...

{
  "contact":   {"name": "Suresh Yadav", "phone": "98765 00001", "external_id": "DRV-1001"},
  "channel":   "none",
  "reference": "onboarding-77"
}

201 {"id": "...", "url": "https://scrutora.com/i/...", "status": "sent", "submission": null}

Register an endpoint under Consent Capture, Settings. Every answer, withdrawal and review decision arrives signed with your endpoint secret, retried for six hours.

POST https://your-product.example/hooks/consent
X-Scrutora-Event: form.submitted
X-Scrutora-Signature-256: sha256=...

{"event": "form.submitted", "data": {
  "reference": "onboarding-77", "status": "submitted",
  "consents": {"gps": true, "dashcam": false},
  "verified": "otp:sms", "proof_hash": "10566e...", "receipt_url": "https://scrutora.com/fr/..."
}}

GET the invitation by id, or list by your reference. The full answer, with the fields the person typed, is one more call for the endpoints and keys that need it.

GET https://api.scrutora.com/api/v1/forms/{form_id}/invitations?reference=onboarding-77

By default nothing leaves your runner, which is why the scan above needs no account and no key. Add --upload and the scan posts its RESULTS to your Scrutora account when it finishes: the findings, the data map, the RoPA entries and the dependency inventory travel, your source never does. Paid plans only; the scan itself stays free forever. Store the key as a secret (GitHub: Actions secret, GitLab: masked CI variable, Bitbucket: repository variable, CircleCI: context, Azure: pipeline secret, Cloud Build: Secret Manager) and expose it as SCRUTORA_API_KEY so it never reaches your build log. Repository, commit, branch and PR number are read from the CI environment, and the scan is filed under a project named after the repository unless you pass --project. Re-running the same commit returns the scan already stored rather than adding a second one, so a retried pipeline does not distort the trend line. If the upload fails, the build result is unchanged: the scan already gave its verdict, and the step logs a warning rather than failing the job. On GitHub Actions you can set upload: true on the action itself instead of running the container by hand, and read the resulting scan id from the scan-id output.

docker run --rm -v "$PWD:/src" -w /src \
  -e SCRUTORA_API_KEY \
  ghcr.io/nirvahana/dpdp-scan@sha256:71e306bdab91587e01ed6b83a1d2c3baecf4c55ecf880b440a5ab76fe85eb461 \
  scan . --no-ai \
    --frameworks dpdpa,hipaa \
    --json-output scrutora.json \
    --output scrutora-report.pdf \
    --upload

# SCRUTORA_API_KEY is read from the environment, never passed on the command
# line, so it stays out of your build log. Add --project "my-service" to file
# the scan somewhere other than a project named after the repository.

# ── GitHub Actions: use the action's own inputs instead ─────────────────────
#   - id: scan
#     uses: scrutora/scrutora-scan@v1
#     with:
#       upload: true
#       api-key: ${{ secrets.SCRUTORA_API_KEY }}
#   - run: echo "Synced as ${{ steps.scan.outputs.scan-id }}"