Source: attachment support guide.
Key Takeaways
- Decide whether the client needs an attachment or simply an accessible file.
- Test each file through the send path staff and automations will actually use.
- Confirm Beam’s applicable limits and workflow support before making client commitments.
What is the difference between a native attachment and a hosted link?
For this checklist, a native attachment means media delivered as part of the message. A hosted link means the message points to a file stored elsewhere. A preview card alone is not enough to distinguish them: inspect how the file opens.
HighLevel explains that SMS carries text, while supported media sent directly uses MMS. It also separates Media Library storage from message delivery limits. Successful upload therefore does not prove direct delivery is possible. See the HighLevel file handling explanation.
Agree on the required outcome with the client before testing:
| Client requirement | Acceptance check |
|---|---|
| A customer can inspect a service photo | Open the received image and check useful detail |
| A customer can read a PDF estimate | Open the document and check every page |
| The file must appear inside the message conversation | Confirm an actual attachment on the recipient device |
| Staff need access during follow-up | Open the file from the correct CRM contact record |
| A hosted link is acceptable | Test recipient access without an agency login |
A link can meet the business requirement when the customer can use it. If the client specifically requires an attachment, mark a link result as a mismatch even when the file opens correctly.
Which messaging path actually sent the file?
Start with the action that created the message. Record whether staff used the conversation composer, a native workflow action, a Beam channel or a custom API integration. Do not use the phrase “sent from GoHighLevel” as the complete technical description.
Beam’s GoHighLevel iMessage integration guide explains that the regular Send SMS action continues using the default SMS provider. Beam workflow sends use the documented Custom Webhook path. Installing an additional conversation channel does not mean every existing workflow starts using it.
Use a test contact your agency controls. Record the location, selected sender, action name and available channel evidence. Keep that record beside the recipient screenshot so another teammate can reproduce the result.
If the client has manual and automated sends, test both separately. A successful manual photo does not establish that a workflow accepts the same media input. Likewise, a successful text-only workflow says nothing about its PDF handling.
What does Beam document about attachments, and what needs confirmation?
Beam documents an attachments array of public HTTPS file links for its message API. Those URLs are attachment inputs; their presence in an API request does not, by itself, tell you what the recipient will see. Beam also documents incoming images appearing inline in its inbox and other incoming files appearing as links.
The Beam attachment documentation lists up to 10 attachments for blue-bubble messages and up to 3 for MMS, with about 5 MB total for MMS. These are documented channel limits, not a guarantee that every carrier, recipient or GoHighLevel action will deliver every permitted file. The same page calls for public HTTPS URLs ending in a file extension and advises JPEG or PNG instead of WEBP or SVG.
The reviewed workflow example does not establish attachment-field support for that endpoint. Confirm it before adapting the message API example into a workflow. Use the Beam iMessage API overview to orient the integration review, then check the exact endpoint contract.
Ask the team to confirm these details for the planned send path:
- Accepted image and document types, including PDF.
- Per-file size, combined size and attachment count limits.
- Any compression or conversion applied before delivery.
- What happens when a file is unsupported or exceeds a limit.
- Whether inbound media reaches the intended GoHighLevel conversation.
Keep unanswered items marked unverified in the client setup sheet.
How should an agency test photos and PDFs on recipient devices?
Build a small, repeatable test set using non-sensitive sample files. Include a photo with fine detail, a PNG and a PDF with readable text across its pages. Use samples similar to the client’s actual work without exposing customer information.
Follow this sequence for each intended send path:
- Record the original. Note its name, extension, size and purpose. Open it locally so a damaged source file does not confuse the result.
- Set the expected outcome. Specify attachment required, link acceptable or either acceptable. Include any image-quality requirement.
- Send through the intended action. Use the same composer or workflow the client plans to use, with a controlled test recipient.
- Inspect the recipient phone. Record the device, messaging app, observed channel and whether the file arrives as media, a document, a preview or a plain link.
- Open the result. Check readability, missing pages, cropping, compression and unexpected access prompts.
- Repeat for the other relevant devices and paths. Save a separate result for each combination instead of extending the first success to all recipients.
Include an iPhone and an Android device when the client’s audience uses both. Record the channel actually used rather than assuming the operating system proves it. Repeat testing when the selected channel changes, especially if fallback is part of the intended workflow.
Acceptance rule: Approve a specific file, send path and recipient experience. Leave untested combinations unapproved.
What should appear in the CRM after the test?
Check the CRM as a separate acceptance step. Open the same contact’s conversation and compare it with the recipient screenshot. Look for the message text, sender, attachment or link, available status and reply placement.
Use a worksheet that makes missing evidence obvious:
| Field | What to record |
|---|---|
| Test identity | Sample file, contact and send time |
| Sending path | Composer, workflow action or API endpoint |
| Recipient result | Attachment or link, opening behavior and readability |
| CRM result | Preview, file link, message text and status |
| Reply result | Where the customer’s response appears |
| Decision | Accepted, failed or awaiting confirmation |
Do not label a file readable merely because the send was accepted. Beam’s routing guidance distinguishes queued acceptance from delivery; start with the Beam messaging documentation when interpreting statuses. Opening the file on the test phone answers a different question from receiving a delivery update.
Send a reply from the test phone and, where required, return a sample image. Check which inbox receives it and whether staff can find it in the intended CRM record. Treat missing or unusable media as an unresolved acceptance item.
How do you diagnose an unexpected link result?
Change a single variable at a time. Keep the contact and send path fixed while testing a smaller copy of the photo. Then compare a supported image with the PDF. Finally, compare manual and automated sends using the same sample.
This sequence gives support a reproducible case. It does not prove the cause on its own, so record observed results without guessing which provider transformed the file.
For an intentional hosted link, test it outside the agency’s logged-in browser session. Confirm the intended recipient can access the correct file, and ask who controls replacement, removal and access duration. Do not promise permanent availability without a documented policy.
If a call workflow sends the follow-up document, include the call-to-message handoff in testing. Teams evaluating that setup can use RizzDial’s GoHighLevel and workflow integrations to plan the connection. Still verify the file delivery separately from the call outcome.
What else should agencies ask about GoHighLevel attachments?
Why did an uploaded photo arrive as a link?
Uploading a file does not guarantee direct delivery. Check the file's size and type, the sending channel and the recipient result before changing the workflow. HighLevel documents hosted links as an option when direct delivery is unsuitable.
Can a PDF appear differently on the phone and in the CRM?
Treat those as separate checks. Record whether the recipient receives an attachment or link, then inspect how the same message appears in the CRM. A CRM preview alone does not establish the recipient experience.
Does a working Beam API attachment prove the workflow supports it?
No. Confirm the attachment fields supported by the exact GoHighLevel workflow endpoint. An attachment example for the message API does not establish support in another send action.
What should an agency promise about photo and PDF delivery?
Promise only the file types, send paths and recipient experiences confirmed in testing. Record any hosted-link behavior and unresolved cases before approving the client workflow.