Skip to main content
MRC is compliance-grade texting: every message is sent from an advisor’s MyRepChat number, consent rules are enforced server-side, and everything is archived. Your integration only ever does what the advisor’s own MyRepChat app does — there is no separate “API behavior” to learn.
Phone numbers are the only identifier you need. Every MRC endpoint accepts phone numbers directly. Responses include a memberId (MRC’s internal contact id) as convenience data you may store and reuse, but no flow requires it — you never have to create, look up, or manage contacts.

​
Prerequisites

  1. OAuth — complete the OAuth Integration Guide (OAuth 2.1 Authorization Code + PKCE, one authorization per advisor). Your access token carries the advisor’s identity and your granted scopes.
  2. Scopes — the messaging surface uses two:
  3. API key — every request also carries your usage-plan key in the x-api-key header, alongside the Authorization: Bearer token.

​
The canonical flow

Send first; handle consent only when the platform tells you to. Most contacts in an advisor’s book have already consented, so the happy path is one call. The three steps in words:
  1. Send the message — POST /mrc/messaging/messages. A 200 with your recipient in successes[] means the platform accepted it for delivery. Done.
  2. If the recipient appears in failures[] with a consent message, the advisor’s account requires consent this contact hasn’t granted — request consent with POST /mrc/messaging/consent-requests, then poll GET /mrc/messaging/consents?phone=… until state is accepted.
  3. Resend the original message. Nothing else changes.

​
Reading responses

Send-type endpoints are batch operations: they return 200 with per-recipient outcomes rather than failing the whole request when one recipient can’t receive.
  • successes[] — accepted for delivery; keep messageId for your records (it will drive delivery-status lookups when that endpoint releases).
  • failures[] — human-readable, per-recipient reasons. Today these are strings; a structured failureDetails array with stable reason codes is planned and will be additive (the strings will not change shape).

​
Error handling

Whole-request problems use real HTTP status codes with an RFC 7807 application/problem+json body — never a 200 in disguise:
The type URL of every problem resolves to a page describing that code; the full list is in Errors. Include the traceId in any support request. Unknown fields you send in request bodies are ignored (stripped), so additive changes on your side are safe.

​
Behaviors worth knowing

  • Consent requests have no cooldown — the API behaves exactly like the advisor’s in-app “request consent” button. If you retry, throttle yourself.
  • Sending to an unknown phone number creates a contact on the advisor’s account (and may import from the advisor’s CRM). Existing contacts are never modified by API traffic.
  • SMS only at launch. Media/MMS is a fast-follow; a media field will be added to the send request when it is released to partner applications.
  • Scheduled sends are supported on the send call (scheduleDelivery + deliveryDate + frequency).
  • Delivery status endpoint is coming. Until it releases, a successes[] entry means the platform and carrier pipeline accepted the message.

​
Integration checklist

  • OAuth flow completed per advisor; tokens refreshed server-side
  • x-api-key on every request
  • Send → check failures[] for consent → request consent → poll → resend
  • Poll cadence: 30s for the first 5 minutes, then every 5 minutes, stop at 24h
  • 429/5xx retried with backoff; traceId logged
  • Phone numbers in E.164 (+12185551234) — required on every phone field; other formats are rejected with a 400