Messages

Review and action channel conversations in one Inbox view.

Last updated:

Use Inbox → Messages to manage buyer conversations across connected channels.

The list header uses 1 result or N results, consistent with other lists. Each result is a conversation, not an individual message; accessible count labels retain “conversation” or “conversations”.

Seller-only storage

ChannelWeave stores eBay selling conversations with your buyers, not your purchases or conversations with your sellers. Both polling and signed message webhooks verify selling context before writing a thread, message body, subject, participant or attachment. Confirmed buying and unverified activity are skipped, not archived or placed in a local retry-content queue.

The verifier compares the authenticated eBay account with the item's seller using an exact-item provider lookup, even for locally imported listings. A local listing alone cannot prove ownership after an account change. Message direction is independent: replies you send to your buyers are selling activity too. Neither an incoming message nor the event name AskSellerQuestion proves that you are the seller. A missing local listing does not prove buying. Identity-only lookup caches last for one sync or webhook request and are not saved in the database.

Missing item references, unavailable identity evidence and conflicting participants fail closed: no content is stored. This may omit genuine selling messages. Check eBay directly for anything missing; a later provider fetch can import it if selling context can then be verified within the sync window. Itemless account notices are not stored. Item-linked eBay notices are stored only when the item is verified as yours; eBay is labelled Sender, not Buyer.

Excluded activity does not enter lists, counts, AI assistant reply drafts or seller actions. Offers follow the same seller-only inclusion rule. Exclusion never withdraws an offer, deletes a conversation on eBay or marks it read there.

Existing records and diagnostic data

An explicitly authorised, account-specific clean-up removes stored buying and unverified conversations, their messages and their attachment metadata. It also clears historical Inbox retry-error text, which may contain old provider response excerpts. Seller conversations and other accounts are untouched. A database constraint rejects eBay conversations unless selling context has been verified.

Raw message notification XML has no database staging table. Polling retry jobs hold counts and scheduling data, not message payloads. Inbox Trading responses are not returned as raw XML, and their error messages omit provider response content. These controls cover the live Inbox database and ingestion paths, not erasure from historical backups, PostgreSQL recovery files or old filesystem logs. Do not restore an older database into service without reapplying this policy and the account-authorised clean-up. Account-deletion compliance handling remains separate from buying/selling message ingestion.

What you can do

  • Filter by channel, unread state, and message type
  • Filter assignment by All, Mine, or Unassigned
  • Search by buyer, subject, listing reference, thread reference, or message-body text; the search field keeps focus after the debounced list refresh so you can keep typing
  • Assign or unassign a conversation to an active team member
  • Use Assign to me from the list or the conversation header for quick pickup
  • Use the right-aligned Offers header button to jump from Messages to offer handling
  • Mark a conversation as read, or mark the latest inbound message as unread for follow-up
  • Bulk assign, unassign, mark read, mark unread, archive, or delete selected conversations from the bulk-action row beneath the filters. The whole row, including assignment controls, appears only while at least one conversation is selected and disappears when the selection is cleared. On mobile, choose Select first, then select a conversation to reveal the actions
  • Open a conversation from the linked subject
  • Use the Subject column as the primary summary cell on narrower layouts:
    • The layout follows the space available beside the sidebar, not just the browser width
    • On compact rows, the timestamp and up to three lines of preview appear beneath the subject; type, latest-event, reply-state, and archive-state badges have their own line rather than squeezing the subject
    • On wide panels, the timestamp and preview move together into a separate Preview column. Status badges stay beneath the subject until the Subject cell itself has enough space for a separate, non-shrinking status area on the right; showing Preview does not squeeze these labels beside a narrow subject
    • On narrow panels, conversations use cards with up to two lines of preview, channel and unread badges inside the card, and actions below the content; pagination controls stack when needed to stay within the panel
    • A compact unread-count slot sits beside Subject when rows have room for separate columns; buyer and owner details remain beneath the subject
  • Open a conversation and review full history
  • Change the assignee from inside the conversation detail card
  • Use Mark as unread from the conversation detail actions to return the latest inbound message to the unread queue
  • Reply where channel reply is supported
  • Review bold response-state labels such as Awaiting reply, Reply due soon, Reply overdue, and Reply urgent when the latest inbound message has not been answered. Reply due soon uses an informational/soft-warning treatment, Reply overdue uses warning, and Reply urgent uses a stronger warning. List labels have no pill border or background; warnings keep an icon and urgent replies use heavier text. These labels are not send errors. Unread counts say 3 unread in both the compact row and the separate unread column. The conversation At a glance summary uses the same bold reply labels and readable unread counts. Other detail badges and navigation counters are unchanged. Very overdue conversations move to Reply urgent so the list can separate normal follow-up from conversations needing immediate attention. Reply timers apply only when the conversation can be actioned: read-only eBay system notifications show No reply needed, blocked reply paths show Reply unavailable, and archived or deleted conversations do not show an active reply status
  • Insert a saved reply, save the current reply as a new template, and append or save your per-user reply signature from the composer
  • Use Ask ChannelWeave in the reply composer to draft a buyer response from the current conversation context, then review and send it yourself
  • Review attachment metadata and linked images/files captured from channel message content or forwarded inbound email
  • Archive, unarchive, delete, and restore conversations

Message types

  • Buyer question
  • Offer update
  • Order financial
  • Order cancellation
  • Returns and cases
  • Shipping or fulfilment update
  • Account notice
  • Other

eBay-specific behaviour

For eligible eBay conversations, you can reply from inside ChannelWeave.

Image attachments use eBay's image service and upload in order before the reply is sent. If an image fails to upload, the reply is not sent. A partly completed batch can leave unused images at eBay until they expire; it does not count as a sent reply. Image uploads are not automatically retried. eBay Sandbox does not support this image-upload service, so replies with images are blocked there; text-only replies are unaffected.

eBay system notifications are read-only and show No reply needed rather than entering the buyer-reply timer. Their age can therefore never produce a misleading Reply overdue or Reply urgent warning.

Cancellation requests and completed cancellations

Order cancellation is a message category, not evidence that a decision is still outstanding. When the linked sales order is cancelled, the conversation shows Order cancelled — no action needed and hides Accept cancellation and Decline cancellation, including the decline confirmation. Open order and the cancellation reference remain available, including in archived conversations. These controls cannot reopen a cancelled order.

For active conversations with a cancellation ID and a linked order, ChannelWeave checks the current request on eBay before offering a decision. It requires a matching buyer request awaiting seller approval. Closed, rejected, already accepted, expired or unverified requests do not offer these actions. If the order is not linked or the check is unavailable, check the order on eBay; the message text alone is not used to enable decisions. Cancelled orders and archived or deleted conversations do not trigger this provider check. The check is unavailable in eBay Sandbox.

For an eligible pending request, Accept cancellation opens the linked sales order for its existing cancellation workflow; opening the link does not itself accept the request. Decline cancellation asks for confirmation, then checks eligibility again before sending the response to eBay. No order status is reversed by declining a request. Refund processing is separate from whether a cancellation decision remains available.

The Inbox eligibility check is read-only with respect to the sales order. Cancellation request closed — no decision needed does not itself reconcile the order or confirm a refund. Separately, order sync and the confirmed Cancel order action check order-level evidence and reconcile completed cancellations without another cancellation or refund. Opening the order or its confirmation dialog does not perform that check; see Sales orders.

The provider check uses eBay's Get Cancellation response to verify the buyer-initiated, awaiting-approval state and matching cancellation and order identifiers. Unknown responses fail closed.

Replies are recorded with a deterministic ChannelWeave outbound id before the external eBay send is attempted. If a send is retried after a local error, ChannelWeave reuses the same reply identity instead of creating a new buyer message.

Opening a conversation, marking it read, or marking it unread updates local read state first. For eBay conversations, ChannelWeave also makes a best-effort Trading API read-state update so eBay My Messages stays aligned.

The reply composer includes Ask ChannelWeave for eligible conversations. AI assistant drafts plain-text reply copy from the recent thread context, but it never sends the message. Review the draft, adjust it where needed, then choose Send reply.

The header sync control queues an eBay Inbox sync only when viewing all channels or the eBay channel filter. It does not enqueue eBay work when another channel is selected. The sync runs in the background; wait a moment, then reload the list to check for newly imported conversations. Repeated sync clicks coalesce into the active background job rather than starting duplicate eBay fetches.

Amazon-specific behaviour

Amazon can be selected as a Messages channel filter, and Amazon conversation rows for your account will be shown with the Amazon badge.

Amazon buyer-message import is not available through the Selling Partner API connection. Amazon's SP-API Messaging surface is order-scoped for supported messaging actions rather than a general inbound buyer-message inbox feed.

From Sales → Orders → order detail, Contact buyer can initiate an Amazon order-scoped message when Amazon returns the required Messaging action for that order. ChannelWeave stores the outbound message in the Inbox as an Amazon conversation row for audit and continuity.

Amazon buyer replies can appear in the ChannelWeave Inbox when Seller Central message emails are forwarded through the signed Amazon inbound email bridge. The bridge is email-based: it does not pretend that SP-API provides a general inbound buyer-message feed. Forwarded emails are parsed, matched to Amazon orders or message headers where possible, and shown as an Amazon conversation.

Shopify and Website behaviour

Shopify and Website contact/buyer messages can appear in the same Inbox list when their channel message setup is enabled. Shopify storefront contact-form previews start with the customer's message in the list; source/path/contact metadata remains available inside the conversation detail. Shopify and Website rows show the buyer name without repeating the email suffix in the Subject column.

For eligible Website conversations, you can reply from inside ChannelWeave when:

  • The Website thread has a valid buyer email address
  • Your Website relay accepts signed outbound reply requests at /api/website/replies/send
  • Your relay has email-sender credentials configured (for example SMTP credentials for your mailbox provider)

Website replies use the same deterministic ChannelWeave reply id that is sent to the relay as the idempotency key.