Sync API docs from bc3: start_date on project constructions (POST /templates/:template_id/project_constructions) - #444
Conversation
Parity catch-up for the one bc3 doc/api change merged since the last mirror sync (bc3 1d8d4ce95d): - Cap the readables batch (basecamp/bc3#13232): `readables` on PUT /my/unreads.json takes at most 500 items and answers 422 over that, in my_notifications.md Synced from bc3 `doc/api/` by `script/api/sync_to_bc3_api` — not a hand-edit.
Project constructions now take a `start_date`, per basecamp/bc3#13259: - POST /templates/:template_id/project_constructions.json documents its `project` parameters — `name` (required), `description`, and `start_date` (ISO 8601), which anchors the template's relative dates to the Sunday on or before it; omitted, they anchor to the week the construction is processed - JSON and cURL examples carry `start_date` Synced from bc3 `doc/api/` by `script/api/sync_to_bc3_api` — not a hand-edit.
There was a problem hiding this comment.
🟢 Approval recommended
Changes are straightforward documentation sync updates with no functional code risk; only a minor example-string typo was noted.
Pull request overview
This PR forward-syncs Basecamp API documentation from bc3 to keep this mirror at parity, adding documentation for a new start_date parameter when creating project constructions from templates and documenting a new server-side limit for marking notifications as read.
[!TIP]
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or rungh pr ready --undo.
Click "Ready for review" or rungh pr readyto reengage.
Changes:
- Document
project.start_date(ISO 8601 date) forPOST /templates/:template_id/project_constructions.json, including updated JSON and cURL examples. - Document that
PUT /my/unreads.jsonaccepts at most 500readablesper request and returns422when exceeded.
File summaries
| File | Description |
|---|---|
| sections/templates.md | Adds parameter documentation and examples for start_date on project constructions created from templates. |
| sections/my_notifications.md | Documents the 500-item cap for readables and the 422 error behavior when exceeded. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| ```json | ||
| { | ||
| "project": { | ||
| "name": "Marketing ", |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1f58bebd57
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| The parameters are nested under `project`: | ||
|
|
||
| * `name` - the name of the new project. Required. | ||
| * `description` - a description for the new project. | ||
| * `start_date` - date (ISO 8601) the new project starts on. A template's dates (to-do start and due dates, to-do subtask and card step due dates, card due dates, schedule entries) are relative to the start of its first week, and weeks in templates start on a Sunday, so the new project's dates are anchored to the Sunday on or before `start_date`. Omit it and they are anchored to the week in which the construction is processed, which is the week it was requested unless the construction is delayed across a Sunday. |
There was a problem hiding this comment.
Separate required and optional parameters
Replace this generic parameter list with the repository-standard **Required parameters**: and _Optional parameters_: blocks. Appending “Required” only to name breaks the documented section format and makes requiredness less scannable than every endpoint's consistent headings.
AGENTS.md reference: AGENTS.md:L38-L47
Useful? React with 👍 / 👎.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Forward sync of the
start_dateparameter on project constructions shipped in bc3#13259, merged to bc3 master:templates.md, Create a Project Construction:POST /templates/:template_id/project_constructions.jsonnow documents itsprojectparameters —name(required),description, andstart_date(ISO 8601). A template's dates are relative to the start of its first week and weeks start on a Sunday, so the new project's dates are anchored to the Sunday on or beforestart_date; omitted, they anchor to the week the construction is processedstart_dateThe templates change is the second commit (1f58beb) and is exactly
sections/templates.md, +10/-3.The first commit (3487654) is a parity catch-up: the mirror was at exact parity with bc3
1d8d4ce95d(the #443 sync), and one bc3 doc change merged since then was never mirrored. It's on bc3 master, so it rides along here as its own commit rather than a separate PR:readablesonPUT /my/unreads.jsontakes at most 500 items and answers422over that, inmy_notifications.mdEach commit is the sync script's output run from the corresponding bc3 commit (
f3437f5c73then3a151536f8), so the mirror lands at exact parity with bc3 master.Reviews on this PR will be addressed.
Synced from bc3
doc/api/byscript/api/sync_to_bc3_api— not a hand-edit.