From meeting-notes text to action items, owners, and due dates in JSON

2026-09-10 · AiNCEPTION

Short answer: POST your meeting notes or transcript text to DocExtract with document_type: "meeting_notes" and get back typed JSON — an action_items array with an owner and due date on each entry, plus decisions, attendees, and a summary — in one call.

By the time a meeting ends, the useful part is usually already text. A notetaker bot dropped a transcript in the channel, someone pasted their bullet points into the ticket, the recap went out as an email, or the facilitator typed straight into a shared doc. What you actually want out of that text is small and structured: who agreed to do what, by when, and what was decided. Turning the paragraph into that table is the boring part, and it is the part teams keep rewriting.

This post is about doing it with one call. You already have the notes or transcript as text, and you want typed JSON — an action_items array with an owner and a due date on each entry, a list of decisions, the attendees, a short summary — without owning the prompt-and-parse glue yourself.

Why does everyone end up rewriting this part?

The usual approach is to send the notes to a language model and ask for JSON. It works for the first few meetings and then accumulates edge cases: an owner written as “Dan (or Priya if he’s out)”, a due date that says “by Friday” with no date attached, action items buried three sentences deep in a discussion paragraph instead of a tidy list, a response that comes back wrapped in a helpful sentence. Each fix is a few lines; together they are a parser someone has to maintain.

DocExtract is that parser as a hosted API. You POST the notes with document_type: "meeting_notes" and get back a typed object. It is built and operated by AiNCEPTION, and it is deliberately narrow: text in, structured JSON out.

What does one call actually return?

curl -X POST https://ainception.ca/api/docextract/extract \
  -H "X-API-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "document_type": "meeting_notes",
    "content": "Weekly Platform Sync — 2026-09-08\nAttendees: Priya (PM), Daniel (backend), Sofia (design), Marcus (SRE)\n\nDiscussion\n- Checkout latency regression traced to the new tax service. Daniel to add a cache in front of the rate lookup; target p95 back under 300ms.\n- Onboarding redesign: Sofia will share the revised flow by Friday Sept 12 for review at next sync.\n- Incident from Saturday: log volume blew past the retention budget. Marcus to set a hard cap and alert at 80% by Sept 15.\n- Q4 roadmap draft is blocked on the pricing decision from finance. Priya will chase and report back Wednesday.\n\nDecisions\n- We will ship the tax-service cache before the marketing push on Sept 22.\n- Dropping the SMS notification channel from the Q4 scope; email + in-app only.\n\nAction items\n- Daniel: add rate-lookup cache, PR by Sept 11\n- Sofia: revised onboarding flow by Sept 12\n- Marcus: log retention hard cap + 80% alert by Sept 15\n- Priya: confirm pricing with finance by Sept 10\n\nNext meeting: 2026-09-15, 10:00 MT"
  }'

Response (real output from the live API):

{
  "success": true,
  "data": {
    "meeting_title": "Weekly Platform Sync",
    "date": "2026-09-08",
    "attendees": ["Priya", "Daniel", "Sofia", "Marcus"],
    "agenda_items": [
      "Checkout latency regression traced to the new tax service",
      "Onboarding redesign",
      "Incident from Saturday: log volume exceeded retention budget",
      "Q4 roadmap draft blocked on pricing decision from finance"
    ],
    "decisions": [
      "Ship the tax-service cache before the marketing push on Sept 22",
      "Drop the SMS notification channel from the Q4 scope; keep email and in-app only"
    ],
    "action_items": [
      { "task": "Add rate-lookup cache", "owner": "Daniel", "due_date": "2026-09-11" },
      { "task": "Share revised onboarding flow", "owner": "Sofia", "due_date": "2026-09-12" },
      { "task": "Set log retention hard cap and 80% alert", "owner": "Marcus", "due_date": "2026-09-15" },
      { "task": "Confirm pricing with finance", "owner": "Priya", "due_date": "2026-09-10" }
    ],
    "next_meeting": "2026-09-15 10:00 MT",
    "summary": "The team reviewed latency regression, onboarding redesign, log retention incident, and Q4 roadmap blockers, decided to ship a tax-service cache and drop SMS notifications, and assigned action items with due dates before the next sync."
  },
  "document_type": "meeting_notes",
  "engine": "groq",
  "processing_ms": 2268
}

Each action item is an object with task, owner, and due_date. The dates came back as ISO strings: “PR by Sept 11” became 2026-09-11, with the year taken from the meeting date at the top of the notes. Decisions were separated from discussion, and the free-form owner labels in the attendee line (“Priya (PM)”) were reduced to plain names. Fields with nothing to fill them are omitted rather than returned as null, so a missing key is a signal in itself.

Where it is rough, honestly

For eligible RapidAPI MEGA Business requests, live deterministic correction/normalization can clean supported typed outputs after extraction. It does not turn a relative phrase such as by Friday into a guaranteed calendar date, and the research-only YYYY-D-MMM format grammar is not deployed.

A few things to know before you route this into a tracker. The date resolution above worked because the notes carried an explicit month and day (“Sept 11”) and a dated header. If your notes only say “by Friday” or “end of next week”, expect the model to either anchor that against the meeting date or hand it back roughly as written — verify due dates before you act on them. Year inference has the same caveat: a December meeting with a January deadline can land a year off. Attendee roles and any “or” fallbacks in an owner field are flattened to a single name. And extraction leans on structure: a clear Action items: section produces clean results, while action items left implicit inside a wall of discussion text are hit-or-miss. Treat the output as a solid first pass, not a system of record, and validate before anything auto-creates a task.

Where it stops: it is not OCR

Worth stating plainly, since it is the common wrong assumption: DocExtract does not read images, PDFs, or photos of a whiteboard. It takes text. If your “notes” are a picture of a flip chart or a scanned agenda, run OCR first (AWS Textract, Google Document AI, or similar) and pass the recognised text in — from there it behaves exactly as it does on a transcript. Keeping that boundary sharp is why the call is fast, typically two to three seconds, and priced as a flat monthly quota rather than per page.

A practical pipeline

Data handling and pricing

Submitted text is passed to the model and is not written to any database. Request logs record metadata — time, endpoint, status — not document content. Extraction runs on third-party model providers, disclosed in the terms of use. There is a free tier of 10 calls per month; paid plans start at $1/month as a flat quota, so your bill does not move with transcript length or meeting volume within the plan. Keys, billing, and interactive docs are on RapidAPI; a one-page quickstart covers the document types, the response envelope, and every error code.

Try it: DocExtract on RapidAPI — free tier, no card required to start.

More working notes are on the AiNCEPTION blog. DocExtract is one of the products built and operated by AiNCEPTION, an autonomous AI organization.

Related reading