Attachments & handoff
What visitors can attach and what happens when they ask to talk to a person — the behaviour, and the limits your support team will be asked about.
Two widget features you don't configure in code, but should understand — because your users will run into their edges and your support team will be asked why.
Attachments
Widget visitors can attach files to a chat. The widget handles the whole flow: picking the file, uploading it, showing a thumbnail, sending it with the message. You write nothing.
What you need to know are the limits, because your users will hit them.
| Limit | Value |
|---|---|
| Maximum file size | 5 MB |
| Allowed types | PNG, JPEG, GIF, WebP, and PDF |
| Files per message | 3 |
The allowed types are the screenshot-and-receipt use case, which is what visitors actually
send. A customer trying to attach a .docx, a .zip, or a video will be turned away — so
if your support flow depends on those, know that now rather than after launch.
The 5 MB ceiling is deliberately tighter than what your agents get. Anonymous people on the public internet get a smaller budget than your staff do.
The file type is decided by reading the bytes
Assistive determines a file's type by sniffing its actual contents — not from the filename, and not from the type the browser declares. Both of those are attacker-supplied strings; the bytes are not.
So renaming evil.exe to cat.png does not get it through: it doesn't have PNG's bytes,
and it's rejected. Worth knowing if you're the one answering a security review.
The Public API has no attachments at all
File upload exists only in the widget. The Public API has no upload endpoint, no attachment field, and no way to add one — so if your users need to send screenshots and you're building your own chat UI, that's a real constraint to weigh before you commit to that path.
Human handoff
When handoff is enabled, a visitor who isn't getting what they need can ask to talk to a person.
Doing so raises a ticket from their conversation. That's the mechanism, and it's worth being precise about it, because "handoff" sounds like it might do more. It doesn't move the chat somewhere else, it doesn't page anyone, and the visitor keeps chatting in the same thread with the same history.
What changes is on the other side of the glass. A ticket is the unit of work your agents actually manage — it has a queue, an owner, a status, and an SLA clock. Raising one turns a conversation that was sitting in an inbox into a piece of work someone is accountable for finishing. Your organization's ticket-creation routing rules run at that moment, so it can land straight in the right team's queue.
It's idempotent: a conversation that already has a ticket keeps the one it has. A visitor mashing the button doesn't create a pile of duplicates for your team to close.
Turning it off
Handoff is a dashboard switch. If it's off, the option simply isn't offered to visitors — there's no button to press and no dead end to walk into.
Switch it off when you don't have people available to answer. It's better for a visitor to never see the offer than to take it and wait for a reply that isn't coming.
What visitors never see
Two guarantees worth one sentence each, because they're the ones people ask about:
- In a chat thread, a visitor sees only customer-visible messages. Internal notes, system events, and staff identifiers are filtered out server-side — your agents can talk about a conversation without any risk of it surfacing in the widget.
- The widget's configuration exposes only branding. Never your keys, never your origin allow-list, never any other setting.