Skip to main content

incheck

The official Python SDK for the InCheck AI platform. Two operating modes, one client, typed end-to-end:

  • EMS mode — ask the model an EMS protocol question. No setup required beyond an API key.
  • Unified mode — onboard one or more documents into a Pod (one Pod per org_id), then chat against that Pod and the answers are grounded in your content.

Status: 0.0.2 — chat (EMS + unified, sync/async/streaming) and document onboarding (Pods, presigned uploads, processing jobs).

Install

pip install incheck
# or
uv add incheck

Requires Python 3.10+.

Authenticate

Generate an API key from the InCheck admin (/admin/api-keys — Teams plan + admin role) and set the env var:

export INCHECK_API_KEY="incheck_prod_..."

Your key is bound to one organization. InCheck derives a namespace from your org's subdomain — every org_id you use must start with <namespace>_. Cross-namespace requests are rejected at the gateway.

EMS mode — no setup, just chat

from incheck import Client

with Client() as client:
    reply = client.chat.send(
        "Adult dose of atropine for symptomatic bradycardia?",
        scope="ALS",
        state="Massachusetts",
    )
    print(reply.content)

That's it. The model answers from general EMS knowledge under the given scope/state. No org_id needed.

Unified mode — chat with your documents

Onboard documents once (a Pod), then chat against that Pod. A Pod is identified by your org_id; you can hold multiple files in the same Pod and query across all of them.

from incheck import Client

with Client() as client:
    namespace = client.documents.list_orgs().filtered_by
    org_id = f"{namespace}_dispatch"           # your Pod

    # 1. Onboard documents — initiate → upload → complete → poll, in one call.
    status = client.documents.upload(
        org_id,
        files=["./dispatch_sop.pdf", "./policies.docx"],
    )
    print("processed:", status.progress.processed_pages, "pages")

    # 2. Chat against the Pod
    reply = client.chat.send(
        "What's our hazmat escalation policy?",
        org_id=org_id,                          # ← turns on unified mode
        user_id="alice@hospital.org",
    )
    print(reply.content)

You can add or update files in the Pod later with documents.upload(...) again, or scope the change with initiate_update / complete_update.

How does the document processing work? That's our IP. The contract you see — upload, wait for the job to complete, query — is the whole public surface. If you need deeper guarantees about extraction accuracy, retention, or custom pipelines, talk to us.

Streaming

Both modes support streaming:

for chunk in client.chat.stream("Summarize the SOP.", org_id="acme_dispatch"):
    if chunk.content:
        print(chunk.content, end="", flush=True)

Async

The SDK ships an async client with the same method names:

import asyncio
from incheck import AsyncClient

async def main():
    async with AsyncClient() as client:
        # EMS
        r = await client.chat.send("Adult dose of epinephrine for anaphylaxis?")
        print(r.content)

        # Unified
        await client.documents.upload("acme_dispatch", ["./sop.pdf"])
        r = await client.chat.send("Summarize.", org_id="acme_dispatch")
        print(r.content)

asyncio.run(main())

Environments

Environment Base URL When to use
production https://api.incheck.ai live traffic
staging https://api-acceptance.incheck.ai integration testing

Pick one in code or via env var. Production is the default.

Client(environment="staging")          # explicit
# or: INCHECK_ENVIRONMENT=staging      # via env

Endpoints covered

Documents

Method What it does
client.documents.upload(org_id, files, wait=True) one-shot: initiate → upload → complete → poll
client.documents.list_orgs() every Pod (org_id) under your namespace
client.documents.list(org_id) files in a Pod's current version
client.documents.version(org_id) metadata about the current version
client.documents.initiate_upload(...) low-level — get presigned uploads
client.documents.complete_upload(...) low-level — trigger processing
client.documents.initiate_update(...) add or replace files in an existing Pod
client.documents.complete_update(...) finalise an update
client.documents.job(job_id) status snapshot
client.documents.wait_for_job(job_id) block until terminal
client.documents.delete_version(org_id, version) delete one version
client.documents.delete(org_id) delete a whole Pod

Chat

Method What it does
client.chat.send(content, *, org_id=None, ...) aggregated reply (EMS if org_id omitted, unified if set)
client.chat.stream(content, *, org_id=None, ...) streamed chunks as they arrive

AsyncClient exposes the same methods under the same names.

Errors

Every non-2xx response becomes a typed exception:

from incheck import (
    Client,
    AuthenticationError,
    PermissionError,
    ValidationError,
    JobFailedError,
    JobTimeoutError,
    RateLimitError,
)

with Client() as client:
    try:
        client.documents.upload("royal_dispatch", ["./sop.pdf"])
    except PermissionError as e:
        print("namespace mismatch:", e)
    except ValidationError as e:
        print("bad request:", e)
    except JobFailedError as e:
        print("processing failed:", e.job_id, e.status)
    except JobTimeoutError as e:
        print("still pending:", e.last_status)
    except RateLimitError as e:
        print(f"slow down; retry after {e.retry_after}s")
    except AuthenticationError:
        print("check your API key")

Hierarchy: IncheckError → AuthenticationError, PermissionError, NotFoundError, ValidationError, RateLimitError, APIError, APIConnectionError, JobFailedError, JobTimeoutError.

Configuration

Env var Default Notes
INCHECK_API_KEY — required
INCHECK_ENVIRONMENT production production or staging
INCHECK_BASE_URL — full URL override (highest priority)

You can also pass api_key=, environment=, and base_url= explicitly to either client.

Breaking changes since 0.0.1

chat.send and chat.stream no longer take org_id as the first positional argument. The new signature is:

client.chat.send(content, *, org_id=None, ...)

Callers that previously did chat.send(org_id, content) should switch to chat.send(content, org_id=org_id). Omitting org_id is the new EMS-mode shape.

License

MIT.

Metadata

Release files for incheck 0.0.4

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for incheck 0.0.4
File Size Uploaded Provenance Actions
incheck-0.0.4.tar.gz 15.9 kB With provenance Details for incheck-0.0.4.tar.gz

Built distribution (wheel)

Table of built distributions (wheels) for incheck 0.0.4
File Interpreter ABI Platform Actions
incheck-0.0.4-py3-none-any.whl Python 3 none any Details for incheck-0.0.4-py3-none-any.whl

Total release size: 36.6 kB

Release files / incheck-0.0.4.tar.gz

Download URL incheck-0.0.4.tar.gz
Size 15.9 kB
Tags Source
SHA-256 checksum
How to use checksums
850a7f5e35f1852f38f183c6025c49bd40b4adf2f52d6ac8237ae0ec32f53067
BLAKE2b-256 checksum
How to use checksums
5afc1c17aaf2be4e1b48164b2df0013205876ad749b059d88ead589c0f69a795
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.12

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on May 12, 2026.

Transparency log

Release files / incheck-0.0.4-py3-none-any.whl

Download URL incheck-0.0.4-py3-none-any.whl
Size 20.7 kB
Tags Python 3
SHA-256 checksum
How to use checksums
039ecb0a7d26d21e9390c40348849e86455da54f7970fed10d387cceb696825c
BLAKE2b-256 checksum
How to use checksums
4aef3f9c85fd8eea835c181e33a2ee82a3e936fdd35e406462e255248b9d6612
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.12

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on May 12, 2026.

Transparency log

Security for incheck 0.0.4

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

Full provenance

All 2 files in this release have been uploaded with provenance metadata.

Select from 2 files

Attestation for incheck-0.0.4.tar.gz

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on May 12, 2026.

Transparency log

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page