Ship Recurring AI Reports Without Sending a New URL Every Time

Table of contents

1. One-off links break recurring handoffs
2. Use one stable project link and version the leaves
3. Keep reviewer access separate from source access
4. Use API for deterministic runs and MCP for agent-shaped packets
5. A default workflow for daily or weekly report delivery

One-off links break recurring handoffs

GitHub Actions makes recurring report generation easy: workflows can run on a schedule, on the latest commit of the default branch, and on a timezone-aware cron if you need the delivery to match a team routine. The operational problem usually starts after the report is generated.

If every scheduled run creates a fresh set of unrelated URLs, the human handoff gets worse over time:

• reviewers have to rediscover which link is the current packet
• dashboards, appendices, and summaries drift into separate threads
• follow-up notes point at stale URLs instead of the current review surface

That is why recurring report workflows need a stable handoff URL, not just a way to publish HTML. If the packet is something people open every day or every week, the link structure should stay boring.

Use one stable project link and version the leaves

BinHTML's API docs describe the right primitive for this: publish artifacts with the same projectName, then create one unlisted project link for the collection. The same docs also note two details that matter for recurring delivery:

• project links are a Pro feature
• version updates keep the existing artifact share URL the same

That leads to a practical pattern for recurring reports:

1. Publish the summary, appendix, and any supporting dashboard as separate artifacts under one project.
2. Create one project share link for the packet.
3. On the next run, update the existing artifacts as new versions instead of creating unrelated siblings.
4. Reuse the same project link as the handoff URL in Slack, email, tickets, or an agent final message.

The project page becomes the stable entry point. The artifact pages stay the detailed leaves. Reviewers stop chasing fresh links, and the owner keeps version history where it belongs.

If your team is still deciding when to use one artifact link versus a grouped handoff, see Use Artifact Links, Project Links, and Compare Views for Different Review Jobs.

Keep reviewer access separate from source access

Recurring reports often have two audiences:

• people who need to review the rendered packet
• people who need to inspect the source behind it

BinHTML's public API docs make that separation explicit. The publish response includes a share URL, a management URL, and a source download URL, while source downloads remain owner-controlled in the dashboard. That is the right model for recurring handoffs.

Do not assume everyone who can open the report should also get the raw source. In many workflows, the safe default is:

• share the unlisted project link with reviewers
• keep source downloads limited to the signed-in owner or the smaller operator group
• use Compare before announcing a materially revised report
• check /pricing when you need permanent artifacts, private artifacts, or shareable project links

This keeps the review surface simple without flattening your governance model.

Use API for deterministic runs and MCP for agent-shaped packets

The split between API docs and MCP docs matters more for recurring work than for one-off uploads.

Use the API when the report packet is deterministic. A scheduled job already knows which files it will produce, which project they belong to, and whether it should create a new artifact or upload a new version. That fits the normal scheduled-workflow shape cleanly.

Use MCP when the agent is still deciding what belongs in the packet. The MCP tools spec defines tools as model-controlled operations with declared schemas, and OpenAI's remote MCP guide recommends explicit output schemas so clients can validate result shapes. BinHTML's MCP docs mirror that workflow with publish_html for one artifact and publish_project for several related artifacts under one project link.

A simple decision rule works well:

• API: cron jobs, CI summaries, scheduled report generation, backend-owned publishing
• MCP: agent research runs, coding-agent handoffs, dynamic report packets, multi-artifact explainers assembled in-session

If the agent is choosing the packet, let it use MCP. If the pipeline already knows the packet, keep it deterministic.

A default workflow for daily or weekly report delivery

For most teams, the repeatable pattern is straightforward:

1. Generate the HTML outputs on a schedule.
2. Publish each output into a shared project name.
3. Update existing artifacts in place when the packet is a revision.
4. Share one project link as the durable entry point.
5. Keep source access, compare review, expiry, and visibility as separate lifecycle controls around that link.

That approach matches how people actually consume recurring reports. They want one place to open, one packet to review, and a clear path for checking what changed.

Final thought: recurring AI-generated reports do not need a new URL every time they run. They need one stable handoff surface with controlled updates behind it.