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 partner-facing way to address a recipient. The schema also accepts members[] (MRC contact ids) if you’ve stored memberId values from earlier responses — never required.
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), and memberId if you want to skip phone resolution on future calls (optional).
  • 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 launchmediaId (MMS) is not yet available to partner applications.
  • 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.