search_sheets found spreadsheets by name. Docs live in the same Google Drive ecosystem, but they have a different structure — prose, headings, tables — not rows and columns. The starting point is always an ID. What do you think the call looks like?
Yesterday search_sheets gave back a list of files and each one had an id. So I'd take that ID and pass it to some GET_DOCUMENT action — probably with just the one parameter?
Exactly. GOOGLEDOCS_GET_DOCUMENT_BY_ID takes a single id parameter and returns the full document object — title, revision info, and the body structure Google Docs uses internally. Here's the whole call:
result = toolset.execute_action(Action.GOOGLEDOCS_GET_DOCUMENT_BY_ID, {"id": doc_id})
The parameter is just id, not document_id or doc_id? I would've guessed one of those longer names.
Just id. Composio maps Google's own API field name here — the Docs API calls it documentId but Composio flattens it to id. The response dict comes back with a title key at the top level and a body key that holds the structural content. You return the whole dict unchanged:
def read_doc(doc_id: str) -> dict:
result = toolset.execute_action(Action.GOOGLEDOCS_GET_DOCUMENT_BY_ID, {"id": doc_id})
return result
So the function itself is simpler than search_sheets — no .get("items", []), no list unwrapping. You just pass the ID and hand back the whole response?
Right. This action fetches a single resource, so the top-level response is already the document — not a list wrapped in a key. The complexity is inside body.content, which is a list of structural elements like paragraphs and tables. You don't parse that today; you surface it.
I could chain this with search_sheets — find the right doc by name, grab its ID, then call read_doc to get the full text. That's a real lookup workflow.
That's exactly how Week 4 chains work. read_doc is the read half of the Docs API. Once you have the body structure in Python, you can extract headings, copy sections, or hand the content to a post-creation action without ever opening the browser.
GOOGLEDOCS_GET_DOCUMENT_BY_ID takes a single parameter — id — and returns the full document object as a dict.
The top-level keys you'll use most:
| Key | Value |
|---|---|
title | The document's display name |
documentId | The same ID you passed in |
body | Structural content (body.content is a list of elements) |
revisionId | Latest revision identifier |
Unlike list actions (search_sheets, list_tasks), there is no items wrapper — the response is the document itself.
Downstream actions (create post, send email, create task) each need different parts of the document. Returning result unchanged lets the caller decide what to extract.
search_sheets found spreadsheets by name. Docs live in the same Google Drive ecosystem, but they have a different structure — prose, headings, tables — not rows and columns. The starting point is always an ID. What do you think the call looks like?
Yesterday search_sheets gave back a list of files and each one had an id. So I'd take that ID and pass it to some GET_DOCUMENT action — probably with just the one parameter?
Exactly. GOOGLEDOCS_GET_DOCUMENT_BY_ID takes a single id parameter and returns the full document object — title, revision info, and the body structure Google Docs uses internally. Here's the whole call:
result = toolset.execute_action(Action.GOOGLEDOCS_GET_DOCUMENT_BY_ID, {"id": doc_id})The parameter is just id, not document_id or doc_id? I would've guessed one of those longer names.
Just id. Composio maps Google's own API field name here — the Docs API calls it documentId but Composio flattens it to id. The response dict comes back with a title key at the top level and a body key that holds the structural content. You return the whole dict unchanged:
def read_doc(doc_id: str) -> dict:
result = toolset.execute_action(Action.GOOGLEDOCS_GET_DOCUMENT_BY_ID, {"id": doc_id})
return resultSo the function itself is simpler than search_sheets — no .get("items", []), no list unwrapping. You just pass the ID and hand back the whole response?
Right. This action fetches a single resource, so the top-level response is already the document — not a list wrapped in a key. The complexity is inside body.content, which is a list of structural elements like paragraphs and tables. You don't parse that today; you surface it.
I could chain this with search_sheets — find the right doc by name, grab its ID, then call read_doc to get the full text. That's a real lookup workflow.
That's exactly how Week 4 chains work. read_doc is the read half of the Docs API. Once you have the body structure in Python, you can extract headings, copy sections, or hand the content to a post-creation action without ever opening the browser.
GOOGLEDOCS_GET_DOCUMENT_BY_ID takes a single parameter — id — and returns the full document object as a dict.
The top-level keys you'll use most:
| Key | Value |
|---|---|
title | The document's display name |
documentId | The same ID you passed in |
body | Structural content (body.content is a list of elements) |
revisionId | Latest revision identifier |
Unlike list actions (search_sheets, list_tasks), there is no items wrapper — the response is the document itself.
Downstream actions (create post, send email, create task) each need different parts of the document. Returning result unchanged lets the caller decide what to extract.
Create a free account to get started. Paid plans unlock all tracks.