read_doc from yesterday reads existing documents. Today you create one. Same principle as create_event — test with a doc you can delete, confirm it appeared in Drive, then automate.
GOOGLEDOCS_CREATE_DOCUMENT with a title. It returns the new document dict including the doc ID I can use for further operations.
Exactly. The created document starts empty — just a title. You can use the doc_id from the response to share the link with a client, or pass it to a future update action. Check your Google Drive and the doc will be there:
result = toolset.execute_action(
Action.GOOGLEDOCS_CREATE_DOCUMENT,
{"title": "Proposal — Acme — Q2 Redesign"}
)
new_doc_id = result.get("documentId", "")
print(f"Created: {new_doc_id}")
The response key is "documentId" not "id"? Docs uses a different key from Sheets?
Google's APIs are not always consistent with key names. Docs uses documentId; Drive uses id; Tasks uses id. Always .get() and always check the actual response in your first run. The Composio wrapper surfaces the underlying API response shape.
So I can generate the doc title from the client name and project, create it, share the ID with the client. One function call to generate the deliverable container.
That is the proposal generator workflow forming. Search for a brief in Sheets, create a Doc with the client name, copy the project template — all automated:
def create_doc(title: str) -> dict:
result = toolset.execute_action(
Action.GOOGLEDOCS_CREATE_DOCUMENT,
{"title": title}
)
doc_id = result.get("documentId", "")
print(f"Created doc: {doc_id}")
return result
My proposal setup ritual — create doc, name it, set permissions — is now a function call.
And Week 4 uses read_doc and LINKEDIN_CREATE_LINKED_IN_POST together — the project-wrap post writes itself from the proposal doc.
GOOGLEDOCS_CREATE_DOCUMENT creates a new blank document with a title and returns the full document dict:
result = toolset.execute_action(
action=Action.GOOGLEDOCS_CREATE_DOCUMENT,
params={'title': title}
)
doc_id = result.get('documentId', '')The response includes documentId — store it to pass to subsequent actions (add content, share with a client, or link from an email). The ID is permanent for the lifetime of the doc.
Title naming convention: use a consistent pattern like 'Proposal — {client} — {month} {year}' so search_sheets-style queries can find docs by name. Consistent naming pays dividends when you have 50+ client documents.
read_doc from yesterday reads existing documents. Today you create one. Same principle as create_event — test with a doc you can delete, confirm it appeared in Drive, then automate.
GOOGLEDOCS_CREATE_DOCUMENT with a title. It returns the new document dict including the doc ID I can use for further operations.
Exactly. The created document starts empty — just a title. You can use the doc_id from the response to share the link with a client, or pass it to a future update action. Check your Google Drive and the doc will be there:
result = toolset.execute_action(
Action.GOOGLEDOCS_CREATE_DOCUMENT,
{"title": "Proposal — Acme — Q2 Redesign"}
)
new_doc_id = result.get("documentId", "")
print(f"Created: {new_doc_id}")The response key is "documentId" not "id"? Docs uses a different key from Sheets?
Google's APIs are not always consistent with key names. Docs uses documentId; Drive uses id; Tasks uses id. Always .get() and always check the actual response in your first run. The Composio wrapper surfaces the underlying API response shape.
So I can generate the doc title from the client name and project, create it, share the ID with the client. One function call to generate the deliverable container.
That is the proposal generator workflow forming. Search for a brief in Sheets, create a Doc with the client name, copy the project template — all automated:
def create_doc(title: str) -> dict:
result = toolset.execute_action(
Action.GOOGLEDOCS_CREATE_DOCUMENT,
{"title": title}
)
doc_id = result.get("documentId", "")
print(f"Created doc: {doc_id}")
return resultMy proposal setup ritual — create doc, name it, set permissions — is now a function call.
And Week 4 uses read_doc and LINKEDIN_CREATE_LINKED_IN_POST together — the project-wrap post writes itself from the proposal doc.
GOOGLEDOCS_CREATE_DOCUMENT creates a new blank document with a title and returns the full document dict:
result = toolset.execute_action(
action=Action.GOOGLEDOCS_CREATE_DOCUMENT,
params={'title': title}
)
doc_id = result.get('documentId', '')The response includes documentId — store it to pass to subsequent actions (add content, share with a client, or link from an email). The ID is permanent for the lifetime of the doc.
Title naming convention: use a consistent pattern like 'Proposal — {client} — {month} {year}' so search_sheets-style queries can find docs by name. Consistent naming pays dividends when you have 50+ client documents.
Create a free account to get started. Paid plans unlock all tracks.