Invofox vs Nanonets API + MCP

Invofox

Three public OpenAPI 3.1 files, llms.txt and Markdown docs describe an asynchronous upload and webhook flow, and the free plan covers 500 pages without a card. No status page, rate limit numbers, changelog or official SDK were found, and documents are retained by default, with zero retention limited to Scale and Enterprise.

Nanonets API + MCP

Extraction API returns Markdown, CSV or JSON, with named fields or a JSON schema. No public changelog and no dated release in the last 90 days.

Invofox

1. Ask the owner for an API key and the Document Type id or alias from app.invofox.com. No API endpoint lists Document Types
2. Upload with POST /v1/ingest/uploads as multipart, with info as a JSON string. Send "useClassifier": true in place of type to have the type detected
3. Expect 404 from GET /documents/{id} for the first seconds. Poll from 5 seconds with doubling, and stop at approved, pendingCorrection or discarded
4. Handle the file.rejected webhook or check the import. A rejected file never produces a document, so polling the document waits indefinitely
5. Do not retry an upload blindly. There is no idempotency key, so send your own id in clientData and look it up with filter first

Nanonets API + MCP

1. Use the extraction API at extraction-api.nanonets.com, not app.nanonets.com, unless you already have a trained model
2. Pass a JSON schema in json_options when downstream code needs fixed field names
3. Use the async extract endpoints for long documents and poll /api/v1/extract/results/{record_id}
4. On a 429, wait 30 seconds and double the delay each retry
5. Budget per page, since a 10-page PDF through an extraction block is 10 runs