Do API calls use /api/ in production?

No. Public production calls use bare routes on https://api.kernit.org, for example /hyperlink-scan. The internal Cloudflare Pages function path remains implementation detail.

Which endpoint should I start with?

Use /hyperlink-scan, then /hyperlink-crossref when DOI evidence is needed, then /hyperlink-apply. Use /hyperlink only for one-step workflows that do not require review.

Does KERNIT store my DOCX?

The API processes uploaded DOCX files to return review data or a linked DOCX. Team and billing metadata are stored for account operations, but docs should be treated as request payloads, not durable project files.

KERNIT Documentation

POST/hyperlink-scan -> /hyperlink-crossref -> /hyperlink-apply

Scan, resolve, review, apply

The safest production integration treats KERNIT as a stateful review pipeline: scan the DOCX, resolve external evidence, review every risky row in your product, and apply only approved decisions with the original request state.

FLOW scan -> resolve -> review -> apply

Review-first document automation#

Use this pattern when author manuscripts vary and your product needs an auditable checkpoint before writing links into the DOCX.

AuthBearer API key BillingScan prepares review; apply writes the linked output Hosthttps://api.kernit.org

Workflow Contract#

Step	Endpoint or UI step	State to preserve
1	`POST /hyperlink-scan`	`scanFingerprint`, `scanToken`, settings, source DOCX.
2	`POST /hyperlink-crossref`	Resolver evidence keyed by reference or bibliography target.
3	Your reviewer UI	Approved, retargeted, skipped, and link-only decisions.
4	`POST /hyperlink-apply`	Same DOCX, same settings, same scan token, same fingerprint, decisions, and optional resolver evidence.

Settings Payload#

{
  "refs": true,
  "figures": "number",
  "tables": "number",
  "equations": "number",
  "sections": "number",
  "doi": true,
  "crossref": true,
  "refTitleLink": false,
  "linkColor": "#0077BD",
  "xrefLinkColor": "#0077BD"
}

Scan Response Shape#

{
  "scanFingerprint": "sha256:2d7f8c1b6e1f1c6c3a0f4b6a9b1e2d3c4f5a60718293a4b5c6d7e8f901234567",
  "scanToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.review-session-token",
  "summary": {
    "matches": 42,
    "targets": 39,
    "needsReview": 6
  },
  "matches": [
    {
      "refId": "cite-001",
      "label": "Smith et al., 2024",
      "kind": "citation",
      "status": "candidate",
      "targetId": "bib-001",
      "confidence": 0.93
    }
  ],
  "targets": [
    {
      "targetId": "bib-001",
      "kind": "reference",
      "text": "Smith J, Nguyen R, Patel A. Reference linking in editorial systems. Journal of Publishing Systems. 2024;18(2):101-119."
    }
  ]
}

Resolver Response Shape#

{
  "resolvedWorks": {
    "bib-001": {
      "doi": "10.5555/jps.2024.18.2.101",
      "title": "Reference linking in editorial systems",
      "year": 2024,
      "containerTitle": "Journal of Publishing Systems",
      "confidence": 0.94,
      "source": "crossref"
    }
  },
  "resolverReport": {
    "resolved": 31,
    "reviewRequired": 5,
    "unresolved": 3
  }
}

Review Decision Payload#

[
  {
    "refId": "cite-001",
    "status": "approved",
    "targetId": "bib-001"
  },
  {
    "refId": "cite-017",
    "status": "retargeted",
    "targetId": "bib-014",
    "note": "Reviewer selected the corrected bibliography entry."
  },
  {
    "refId": "cite-021",
    "status": "skipped",
    "reason": "Ambiguous author-year citation."
  }
]

Apply Response Shape#

{
  "docx": "base64-encoded-docx",
  "linkCount": 47,
  "statCounts": {
    "citation": 31,
    "figure": 5,
    "table": 4,
    "equation": 3,
    "doi": 4
  },
  "warnings": []
}

Reviewer UI Rules#

Show low-confidence and identity-changing rows before straightforward rows.
Keep skip and retarget available; approving everything by default creates avoidable wrong-link risk.
Store scan state with the review session and submit it unchanged to apply.
Record the final decision payload so support can replay the review state if needed.

Complete Integration Examples#

Use the copy-paste guides for Node, Python, or cURL when wiring the whole workflow.

FAQ

Do API calls use /api/ in production?: No. Public production calls use bare routes on https://api.kernit.org, for example /hyperlink-scan. The internal Cloudflare Pages function path remains implementation detail.
Which endpoint should I start with?: Use /hyperlink-scan, then /hyperlink-crossref when DOI evidence is needed, then /hyperlink-apply. Use /hyperlink only for one-step workflows that do not require review.
Does KERNIT store my DOCX?: The API processes uploaded DOCX files to return review data or a linked DOCX. Team and billing metadata are stored for account operations, but docs should be treated as request payloads, not durable project files.

Was this page useful?Send a lightweight docs feedback event.

Last updated: May 12, 2026Canonical: https://kernit.org/docs/api/workflow/