Integration Reference

VerifyAPI

VerifyAPI gives AI pipelines a tamper-evident audit trail for every output they produce. Submit any AI-generated data — invoice extractions, agent decisions, document classifications — and receive a structured proof record with a verification status, risk classification, confidence score, and list of flagged issues. Proof records are retrievable by ID, making them suitable for compliance workflows, audit logs, and automated escalation gates.

Base URL

https://api.swarmsync.ai

Authentication

All non-demo endpoints require a Bearer token in the Authorization header. Obtain a token from your dashboard or via POST /auth/login.

Authorization: Bearer {your_api_key}

Endpoints

All paths are relative to https://api.swarmsync.ai.

EndpointDescriptionAuth

POST/api/verifyVerify AI output against a rule set. Returns a proof record with status, confidence, and issues.Bearer token

GET/api/verify/:idRetrieve a previously created verification by ID. Proof records are scoped and reviewable.Bearer token

GET/api/usageReturn current period verification usage — runs used, limit, and plan name.Bearer token

POST/api/verify/demoUnauthenticated sandbox endpoint. Same verification engine as production; records are stored under an anonymous org and can be retrieved by proof_id.None

Verify an AI output

Submit the output field with a source type, task, and rule set. The response includes a proof ID you can retrieve later.

POSThttps://api.swarmsync.ai/api/verifyBearer token

curl -X POST https://api.swarmsync.ai/api/verify \
  -H "Authorization: Bearer {your_api_key}" \
  -H "Content-Type: application/json" \
  -d '{
    "source_type": "api_output",
    "task": "invoice_extraction",
    "output": {
      "vendor_name": "Acme Corp",
      "invoice_number": "INV-10492",
      "amount_total": 8450,
      "currency": "USD",
      "due_date": "2026-06-01"
    },
    "rules": [
      "required_fields_present",
      "vendor_name_present",
      "amount_total_present",
      "invoice_number_present",
      "due_date_present"
    ]
  }'

200 Response

{
  "verification_id": "vrf_01jx...",
  "proof_id": "prf_01jx...",
  "verification_status": "passed",
  "confidence": 0.94,
  "risk_level": "low",
  "issues_found": [],
  "recommended_action": "approved"
}

Retrieve a verification

Use the verification_id from any prior verification response to fetch the proof record.

GEThttps://api.swarmsync.ai/api/verify/:idBearer token

curl https://api.swarmsync.ai/api/verify/vrf_01jx... \
  -H "Authorization: Bearer {your_api_key}"

Check usage

Returns runs used and the plan limit for the current billing period.

GEThttps://api.swarmsync.ai/api/usageBearer token

curl https://api.swarmsync.ai/api/usage \
  -H "Authorization: Bearer {your_api_key}"

# Response
{
  "plan": "auditproof-comply",
  "runs_used": 47,
  "runs_limit": 500
}

Unauthenticated demo

The demo endpoint uses the same verification engine with no API key. Records are stored under an anonymous sandbox org and can be retrieved via GET /api/verify/:id. Use the interactive demo to test before integrating.

POSThttps://api.swarmsync.ai/api/verify/demoNone

curl -X POST https://api.swarmsync.ai/api/verify/demo \
  -H "Content-Type: application/json" \
  -d '{
    "source_type": "api_output",
    "task": "agent_activity",
    "output": { "agent": "GPT-4o", "task": "classify", "result": "approved" },
    "rules": ["required_fields_present", "agent_identity_present"]
  }'

Capability

Software Delivery Verification

Software delivery verification is a capability inside VerifyAPI. It runs independent checks to confirm that AI-delivered or developer-delivered code has supporting evidence, was committed after the job started, touched the right files, builds, deploys, and that pull requests merged — producing a structured check record with every run. Use the same POST /api/verify endpoint with source_type: "software_delivery".

Fields must be inside output — this is the #1 source of 400 errors

All delivery-specific fields (repoOwner, beforeSha, tier, etc.) must be nested inside the output object, not at the top level of the request body. The API returns a details[] list, an example, and a docs link on validation failure.

Wrong — top-level fields (400)

{
  "source_type": "software_delivery",
  "repoOwner": "org",
  "afterSha": "abc123",
  "tier": "BASIC"
}

Correct — nested in output (200)

{
  "source_type": "software_delivery",
  "output": {
    "repoOwner": "org",
    "afterSha": "abc123",
    "tier": "BASIC"
  }
}

curl example

POSThttps://api.swarmsync.ai/api/verifyBearer token

curl -X POST https://api.swarmsync.ai/api/verify \
  -H "Authorization: Bearer <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "source_type": "software_delivery",
    "rules": ["auto"],
    "output": {
      "repoOwner": "swarmsync-ai",
      "repoName": "atep-spec",
      "beforeSha": "3274d131e90815548d81105099a50ff8425fac47",
      "afterSha": "b1a8b5fcae619fa4f89012fec28789a04948c660",
      "jobStartedAt": "2026-03-01T00:00:00Z",
      "tier": "BASIC",
      "jobType": "NEW_FEATURE",
      "jobDescription": "Add IETF Internet-Draft files",
      "prNumber": 1
    }
  }'

Document-based mode (no git repo required)

If you do not have a git repository, pass one or more document fields instead of the git-based fields. The engine runs AI analysis against the delivery documents and returns the same proof record shape.

Document fields (use any combination)

delivery_statementPlain-text description of what was delivered and to which environment.

deployment_reportDeployment log, release note, or CI/CD summary for the delivery.

release_notesUser-facing release notes listing new features and bug fixes.

change_logStructured change log or CHANGELOG.md excerpt.

defect_listList of open or closed defects scoped to this release.

integration_scopeDescription of external services, APIs, or data sources touched.

POSThttps://api.swarmsync.ai/api/verifyBearer token

curl -X POST https://api.swarmsync.ai/api/verify \
  -H "Authorization: Bearer <your-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "source_type": "software_delivery",
    "output": {
      "delivery_statement": "System was deployed to production on 2026-06-01.",
      "deployment_report": "Version 2.1 deployed successfully via Render. Zero downtime."
    }
  }'

JavaScript / Node.js example

POSThttps://api.swarmsync.ai/api/verifyBearer token

const res = await fetch('https://api.swarmsync.ai/api/verify', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer <API_KEY>',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    source_type: 'software_delivery',
    rules: ['auto'],
    output: {
      repoOwner: 'swarmsync-ai',
      repoName: 'atep-spec',
      beforeSha: '3274d131e90815548d81105099a50ff8425fac47',
      afterSha: 'b1a8b5fcae619fa4f89012fec28789a04948c660',
      jobStartedAt: '2026-03-01T00:00:00Z',
      tier: 'BASIC',
      jobType: 'NEW_FEATURE',
      jobDescription: 'Add IETF Internet-Draft files',
      prNumber: 1,
    },
  }),
});
const proof = await res.json();
console.log(proof.proof_id, proof.verification_status);

200 response

200 Response

{
  "verification_status": "needs-review",
  "confidence": 0.7,
  "proof_id": "generated-per-run",
  "tier_run": "BASIC",
  "job_type": "NEW_FEATURE",
  "escalated": false,
  "summary": "4 of 6 checks passed. 2 failed, 0 warnings.",
  "checks_passed": 4,
  "checks_failed": 2,
  "checks_warning": 0,
  "checks_skipped": 5,
  "issues_found": [
    {
      "checkId": "B7",
      "checkName": "PR is merged (not just opened)",
      "status": "FAIL",
      "detail": "PR #1 exists but has not been merged yet"
    }
  ],
  "recommended_action": "human_review",
  "results": [
    { "checkId": "B1", "checkName": "Work exists in repo", "status": "PASS", "detail": "..." },
    { "checkId": "B7", "checkName": "PR is merged (not just opened)", "status": "FAIL", "detail": "..." }
  ]
}

Verification tiers

TierWhat it checks

BASICWork evidence exists in repo (B1), commit happened after job started (B2), correct files were touched (B3), delivery description matches the diff (B4, requires aiReport), build passes (B5, env-gated), deployment URL responds when supplied (B6, requires deployUrl), PR is merged (B7, requires prNumber).

STANDARDEverything in BASIC plus: tests pass (S2), no secrets committed (S3), types and lint are clean (S4), dependencies are safe (S5), scope matches job type (S6), CI pipeline passed on the commit (S9, via GitHub checks), production deploy evidence confirmed when deploy context is supplied (S11, requires deployPlatform + token).

THOROUGHEverything in STANDARD plus: code coverage (T1), static security analysis (T3, requires semgrepFindings), performance under load (T6, requires deployUrl), architecture review (T8), monitoring health (T11, requires sentry* fields), and up to twelve additional quality gates (T1–T12).

Allowed `jobType` values

ValueDescription

BUG_FIXA fix for a reported defect.

DEPLOY_UPDATEInfrastructure or deployment configuration change.

WRITE_TESTSAdding or improving automated tests.

MIGRATE_DATADatabase schema or data migration.

BUILD_INTEGRATIONConnecting an external service or API.

NEW_FEATUREA net-new capability added to the codebase.

CODE_REVIEWReview, cleanup, or refactor with no functional change.

Optional fields and the checks they unlock

Checks that depend on an optional field are silently skipped when the field is absent. Include the fields relevant to your delivery to get more coverage.

Field(s)CheckWhat it verifies

prNumberB7PR is merged, not just opened.

deployUrlB6, T6Live site responds; performance / load check.

aiReportB4Delivery description matches the actual diff.

deployPlatform + platform tokenS11Deployment verified on Netlify, Render, Vercel, or Railway.

semgrepFindingsT3Static security analysis results cross-checked.

sentryOrgSlug + sentryProjectSlug + sentryAuthTokenT11Error rate and monitoring health checked post-deploy.

CI checks on commit (auto)B5, S9Build and test confidence via GitHub commit status checks. Local build sandbox is env-gated and off by default.

Rate limits & quota

Two independent limits apply. A per-minute throttle of 20 requests / minute returns HTTP 429 with a Retry-After header — back off and retry. A separate monthly quota per plan (Free: 500, Build: 5,000, Scale: 50,000, Production: 250,000) returns a different 429 with a message indicating the quota is exhausted for the period — retrying immediately will not help; upgrade or wait for the next billing cycle.

PlanThrottleMonthly quota

Free20 / min500 runs / mo

Build20 / min5,000 runs / mo

Scale20 / min50,000 runs / mo

Production20 / min250,000 runs / mo

Looking up a proof

Every software delivery verification run returns a proof_id. Store this ID and use it to retrieve the proof record at any time via GET /api/verify/:id. The same proof ID appears in the dashboard run history. Proof records are reviewable — the check results, issues, and confidence score cannot be modified after creation.

GEThttps://api.swarmsync.ai/api/verify/cmpq01sf7001ksnqtwelyrma4Bearer token

curl https://api.swarmsync.ai/api/verify/cmpq01sf7001ksnqtwelyrma4 \
  -H "Authorization: Bearer <API_KEY>"

Start verifying AI outputs today

Free tier available. API endpoint at api.swarmsync.ai.

Try the demo Create account

VerifyAPI

Base URL

Authentication

Endpoints

Verify an AI output

Retrieve a verification

Check usage

Unauthenticated demo

Software Delivery Verification

curl example

Document-based mode (no git repo required)

JavaScript / Node.js example

200 response

Verification tiers

Allowed jobType values

Optional fields and the checks they unlock

Rate limits & quota

Looking up a proof

Further reading

Start verifying AI outputs today

Allowed `jobType` values