RCS integration overview

​

Start with your messaging workflow

Identify the application event that should trigger a message, the target market and the customer action it should support. Prepare both the rich RCS experience and a useful plain-text SMS alternative. For an appointment reminder, that could mean a branded card with a booking link and an SMS containing the essential time, business name and the same destination. The preview on the Smerio website is illustrative.

​

Separate preview, testing and production

1. Preview: review the sender identity and message content. A preview sends nothing.
2. Test: use an enabled provider account, a test sender and an accepted test-device invitation. Observe the actual message and its delivery outcome.
3. Production: complete the applicable brand, market and carrier approval steps before reaching customers beyond the test group.

Google documents test-device invitations and launch approvals separately. Provider access and approvals determine when a real test or launch can proceed.

​

Planned API boundaries

Smerio is designing two related API surfaces:

• Messaging: send requests, delivery status and events.
• Platform management: workspaces, brands, senders, credentials and usage.

Endpoint paths, authentication examples and SDK installation instructions will be published when their contracts are implemented and verified. This page does not contain executable Smerio API examples yet.

​

Observe each delivery attempt

An accepted request is different from a delivered message. Keep RCS delivery, SMS fallback and final outcomes distinct. Define a timeout and late-event policy to avoid sending duplicate messages when a delayed RCS delivery overlaps an SMS attempt. Read RCS and SMS fallback and from a test sender to production for practical considerations.

​

Discuss an integration

Contact sales with your workflow, target market and current messaging setup. For documentation corrections or technical questions, contact support.