About 15 minutes

Email attachments to BinHTML

Stop sending generated HTML reports as attachments that get blocked, stripped, or opened from a stale download. Send a link with an expiry instead.

Do not migrate if

Migrating has a cost and it is not always worth paying. If one of these describes your situation, stay where you are.

  • The recipient genuinely needs the file itself for their own records.
  • Your organisation requires the document to be delivered as an attachment for retention reasons.
  • The recipient cannot open external links for policy reasons.

Before you start

  • A BinHTML API key.
  • The job or person currently attaching the file.
  • A view on how long recipients should keep access.

Steps

  1. 01

    Publish the report where it is generated

    Add the publish call at the end of the reporting job so the link exists before the email is written.

    Publish and capture the URL

    Language: bash. Replace $BINHTML_API_KEY with a key from your settings.

    # Reads report.html from disk, publishes it, prints the share URL.
jq -n \
  --arg title "Weekly report" \
  --rawfile html ./report.html \
  '{title: $title, visibility: "unlisted", sourceHtml: $html}' \
| curl -sS -X POST https://binhtml.com/api/v1/artifacts \
    -H "Authorization: Bearer $BINHTML_API_KEY" \
    -H "Content-Type: application/json" \
    -d @- \
| jq -r '.urls.share'

  2. 02

    Send the link, keep the file

    Email the share URL. If a recipient needs the file, the source download is still there, and you can send it deliberately rather than to everyone by default.

  3. 03

    Set an expiry that matches the content

    An attachment lives in an inbox forever. A link can stop working when the reporting period closes, which is usually the behaviour you actually wanted.

  4. 04

    Update in place for recurring reports

    For a weekly or monthly report, publish versions against one artifact and send the same URL each time. Recipients stop hunting through their inbox for the newest attachment.

    Update the recurring report

    Language: bash. Replace $BINHTML_API_KEY with a key from your settings.

    # Same artifact, new content. The share URL does not change.
jq -n \
  --arg label "$(date -u +%Y-%m-%d)" \
  --rawfile html ./report.html \
  '{label: $label, sourceHtml: $html}' \
| curl -sS -X POST "https://binhtml.com/api/v1/artifacts/$ARTIFACT_ID/versions" \
    -H "Authorization: Bearer $BINHTML_API_KEY" \
    -H "Content-Type: application/json" \
    -d @-

Verify the migration

Work through these before you remove anything from the old tool. A migration is finished when someone other than you has opened the new link successfully.

  • The link opens on a phone and on a work laptop without a download step.
  • The current version is what loads, not a cached copy.
  • Revoking the link actually stops access.

Known gotchas

Unlisted is not private

Anyone with an unlisted URL can open it. If the report should only open for your account, use private visibility on Pro, and remember that forwarding an email forwards the link.

Some inboxes rewrite links

Security tooling may wrap the URL. Test with a recipient inside the receiving organisation before switching a whole distribution list.

Questions about this migration

How do I migrate from email attachments to BinHTML?

Publish the report once and email the link, so recipients always open the current version and you can revoke access later.

How long does migrating from email attachments take?

About 15 minutes. The steps on this page cover creating an API key, publishing one document to confirm the output, switching repeat publishing to version updates, and verifying the result before you retire the old links.

When should I not migrate from email attachments?

The recipient genuinely needs the file itself for their own records. Your organisation requires the document to be delivered as an attachment for retention reasons. The recipient cannot open external links for policy reasons.

Will the share link change when the content is updated?

No. Publishing a new version against an existing artifact id updates the content behind the same URL, so anyone already holding the link keeps working access.

Next steps