Skip to main content
Sending a text is one POST. The message goes out from the advisor’s own MyRepChat number, lands in their MyRepChat conversation history, and is archived like any other message they send.

Request

phone is the only way to address a recipient. Unknown fields in the body are ignored, so additive changes on your side are safe.
Unknown numbers create a contact. If the advisor has no contact with this number, MRC creates one on their account (and may import details from the advisor’s CRM). Existing contacts are never modified by an API send.

Response — per-recipient outcomes

200 means the request was processed; look inside for each recipient’s outcome:
  • successes[] — accepted for delivery. Store messageId if you want to correlate with delivery status later (endpoint upcoming). memberId is MRC’s internal contact id, returned as convenience data; you can use it for the consent-status lookup, but no flow requires it.
  • failures[] — this recipient did not get the message, with a human-readable reason. The one you must handle programmatically is consent:
That’s your signal to run the consent flow and resend.

Scheduled sends

Scheduled messages appear in the advisor’s MyRepChat scheduled queue — the advisor can see and cancel them in-app, exactly as if they scheduled it themselves.

Limits and notes

  • SMS only at launch — media (MMS) is not yet available to partner applications. A media field will be added to the send request when it ships.
  • Messages longer than one SMS segment are segmented by the carrier as usual; the 1599-character cap is the platform limit.
  • Whole-request errors (bad token, malformed body, rate limit) come back as application/problem+json — see the error table.