To integrate Sinch with Bolt.new, create Next.js API routes that call the Sinch REST API with your Service Plan ID and API token. Sinch offers SMS, MMS, RCS (rich Android messaging), and number verification. Outbound messages and OTP verification work in Bolt's WebContainer. Inbound message webhooks require a deployed URL — deploy to Netlify or Bolt Cloud before configuring inbound callbacks.
SMS, MMS, and RCS Messaging with Sinch in Bolt.new
Sinch is a global communications platform that has grown significantly through acquisitions, owning Mailgun, Mailjet, and SparkPost on the email side, and offering SMS, MMS, RCS, voice, and verification APIs on the messaging side. For Bolt.new developers, Sinch's main differentiator is RCS (Rich Communication Services) — the next generation of SMS that enables branded messages with images, carousels, quick reply buttons, and read receipts on Android devices. While standard SMS still works on all phones, RCS provides an app-like experience without requiring users to download anything.
Sinch's SMS API uses straightforward HTTP Basic authentication: your Service Plan ID as the username and your API token as the password. No OAuth dance, no token expiry management — just credentials in an Authorization header. This simplicity makes the integration clean to implement in Bolt.new: create a Next.js API route, add the credentials to your .env file, and make fetch() calls to Sinch's REST endpoints. The Sinch SDK (`@sinch/sdk-core`) is also available as an alternative to raw fetch calls if you prefer a strongly-typed SDK approach — it is pure JavaScript and works in Bolt's WebContainer.
Sinch Verification is a separate product within the Sinch ecosystem for phone number verification (OTP). It sends a one-time password via SMS (or voice) to verify that a user controls a phone number. The Verification API is separate from the SMS API with different credentials and endpoint format. This tutorial covers both the messaging API and the Verification API.
Integration method
Sinch's SMS and RCS APIs are standard REST endpoints authenticated with HTTP Basic auth (Service Plan ID + API token). All outbound calls — sending SMS, sending RCS messages, triggering OTP verification — are HTTPS requests from Next.js API routes that work in Bolt's WebContainer preview. Inbound message webhooks (receiving replies, delivery reports) require Sinch to POST to a public URL, which means deploying to Netlify or Bolt Cloud before testing inbound flows.
Prerequisites
- A Sinch account (free trial includes credit for testing)
- A Sinch Service Plan created in the Sinch Customer Dashboard for SMS
- Service Plan ID and API token from the Sinch Dashboard
- A Bolt.new project using Next.js for server-side API routes
- For RCS: a Sinch project with RCS agent configured (requires Sinch RCS approval)
Step-by-step guide
Get Sinch API Credentials
Get Sinch API Credentials
Sinch has a somewhat complex credential structure because it has multiple product lines (acquired companies) with different authentication models. For SMS, you need credentials from the Sinch Customer Dashboard at dashboard.sinch.com — these are different from the newer Sinch Platform (sinch.com/dashboard) used for other services. For SMS API credentials: log into dashboard.sinch.com → go to SMS → Service Plans. If you don't have a service plan, create one (US service plan for North American numbers). Click on your service plan to see its details. You need two values: the 'Service Plan ID' (a UUID like 'a5a17e88-...') and the 'API Token' (a long alphanumeric string). Copy both. You also need a sender number (a virtual number or short code). In the Service Plan, go to 'Numbers' and add a US number to your service plan. Trial accounts get a shared number for testing. For Sinch Verification API: this uses a different credential set — an Application Key and Application Secret. Go to dashboard.sinch.com → Verification → Apps. Create a new verification app and note the Application Key (app_key) and Application Secret (app_secret). These are separate from your SMS credentials and cannot be used interchangeably.
1# Sinch SMS API authentication (HTTP Basic Auth):2# Username: Service Plan ID (UUID from SMS → Service Plans)3# Password: API Token (long alphanumeric string)45# Sinch SMS API base URL:6# US: https://us.sms.api.sinch.com/xms/v1/{servicePlanId}/7# EU: https://eu.sms.api.sinch.com/xms/v1/{servicePlanId}/89# Sinch Verification API base URL:10# https://verificationapi-v1.sinch.com/verification/v1/11# Auth: Basic {base64(app_key:app_secret)}Pro tip: The Sinch SMS API endpoint is region-specific. Use the US endpoint (us.sms.api.sinch.com) for North America and the EU endpoint (eu.sms.api.sinch.com) for Europe. Sending to EU numbers from the US endpoint may work but incurs higher latency.
Expected result: You have your Sinch Service Plan ID, API Token, and optionally Verification App Key and Secret. You also have a sender phone number associated with your service plan.
Configure Environment Variables and Create Sinch Client
Configure Environment Variables and Create Sinch Client
Set up environment variables for all the Sinch credentials you need. Sinch SMS and Verification use different credential sets, so name them clearly to avoid confusion. All credentials are server-side only — never add NEXT_PUBLIC_ prefix to any Sinch credential. For the SMS API, Sinch uses HTTP Basic authentication where the username is your Service Plan ID and the password is your API Token. The Authorization header value is 'Basic ' + base64(servicePlanId + ':' + apiToken). All modern fetch calls support this natively via the Authorization header. Create a lib/sinch.ts client utility that exports functions for the SMS operations you need. Building typed functions for common operations (sendSMS, sendBatch, getMessageStatus) is cleaner than writing raw fetch calls in each API route. Include the service plan ID in the base URL since Sinch's SMS API uses it in the path.
Set up Sinch configuration in my Next.js project. Create a .env with SINCH_SERVICE_PLAN_ID, SINCH_API_TOKEN, SINCH_SENDER_NUMBER, SINCH_VERIFICATION_APP_KEY, and SINCH_VERIFICATION_APP_SECRET. Create lib/sinch.ts that exports: (1) sinchSMSFetch(path, method, body?) — wraps fetch with Basic Auth header for the SMS API at https://us.sms.api.sinch.com/xms/v1/{SINCH_SERVICE_PLAN_ID}/. (2) sinchVerificationFetch(path, method, body?) — wraps fetch with Basic Auth for Verification API. Include TypeScript interfaces for SinchBatch and SinchVerificationRequest.
Paste this in Bolt.new chat
1// lib/sinch.ts2const SERVICE_PLAN_ID = process.env.SINCH_SERVICE_PLAN_ID!;3const API_TOKEN = process.env.SINCH_API_TOKEN!;4const VERIFICATION_APP_KEY = process.env.SINCH_VERIFICATION_APP_KEY!;5const VERIFICATION_APP_SECRET = process.env.SINCH_VERIFICATION_APP_SECRET!;67export const SINCH_SENDER = process.env.SINCH_SENDER_NUMBER!;8const SMS_BASE = `https://us.sms.api.sinch.com/xms/v1/${SERVICE_PLAN_ID}`;9const VERIFICATION_BASE = 'https://verificationapi-v1.sinch.com/verification/v1';1011function basicAuth(user: string, pass: string): string {12 return 'Basic ' + Buffer.from(`${user}:${pass}`).toString('base64');13}1415export async function sinchSMSFetch<T>(path: string, method = 'GET', body?: object): Promise<T> {16 const response = await fetch(`${SMS_BASE}${path}`, {17 method,18 headers: {19 Authorization: basicAuth(SERVICE_PLAN_ID, API_TOKEN),20 'Content-Type': 'application/json',21 },22 body: body ? JSON.stringify(body) : undefined,23 });24 if (!response.ok) {25 const text = await response.text();26 throw new Error(`Sinch SMS ${response.status}: ${text}`);27 }28 return response.json() as Promise<T>;29}3031export async function sinchVerificationFetch<T>(path: string, method = 'POST', body?: object): Promise<T> {32 const response = await fetch(`${VERIFICATION_BASE}${path}`, {33 method,34 headers: {35 Authorization: basicAuth(VERIFICATION_APP_KEY, VERIFICATION_APP_SECRET),36 'Content-Type': 'application/json',37 },38 body: body ? JSON.stringify(body) : undefined,39 });40 if (!response.ok) {41 const text = await response.text();42 throw new Error(`Sinch Verification ${response.status}: ${text}`);43 }44 return response.json() as Promise<T>;45}Expected result: lib/sinch.ts exports authenticated fetch wrappers for both the SMS and Verification APIs. All credentials are in .env as server-side variables.
Create the SMS Sending API Route
Create the SMS Sending API Route
Sinch's SMS API uses a batching model — every send operation creates a 'batch', even for single messages. A batch can have multiple recipients (up to 1,000 in a single call). The batch creation endpoint is POST /batches, and it accepts a from (sender number), to (array of recipient numbers in E.164 format), and body (message text). Sinch's batch API response includes a batch ID (id), status, and scheduled delivery information. The batch ID can be used to retrieve delivery reports later. Store the batch ID if you want to check delivery status via GET /batches/{batchId}/deliveryreport. For personalized messages (different text for each recipient), Sinch supports parameterized messages using ${variable_name} syntax in the message body and a parameters object that maps variables to recipient-specific values. This is more efficient than sending N separate API calls for N recipients with different messages.
Create a Next.js API route at /api/sinch/send-sms (POST). Accept 'to' (string or array of E.164 numbers) and 'message' (string). Validate that numbers start with '+' and message is not empty. Call sinchSMSFetch('/batches', 'POST', { from: SINCH_SENDER, to: Array.isArray(to) ? to : [to], body: message }). Return batch id, status, and number of recipients. Include proper TypeScript interface for the SinchBatch response. Handle errors with descriptive messages.
Paste this in Bolt.new chat
1// app/api/sinch/send-sms/route.ts2import { NextResponse } from 'next/server';3import { sinchSMSFetch, SINCH_SENDER } from '@/lib/sinch';45interface SinchBatch {6 id: string;7 type: string;8 status: string;9 to: string[];10 from: string;11 created_at: string;12}1314const E164_REGEX = /^\+[1-9]\d{1,14}$/;1516export async function POST(request: Request) {17 try {18 const { to, message } = await request.json();19 const recipients = Array.isArray(to) ? to : [to];2021 const invalidNumbers = recipients.filter((n: string) => !E164_REGEX.test(n));22 if (invalidNumbers.length > 0) {23 return NextResponse.json(24 { error: `Invalid phone numbers: ${invalidNumbers.join(', ')}` },25 { status: 400 }26 );27 }2829 if (!message || message.trim().length === 0) {30 return NextResponse.json({ error: 'Message cannot be empty' }, { status: 400 });31 }3233 const batch = await sinchSMSFetch<SinchBatch>('/batches', 'POST', {34 from: SINCH_SENDER,35 to: recipients,36 body: message,37 });3839 return NextResponse.json({40 batchId: batch.id,41 status: batch.status,42 recipients: batch.to.length,43 });44 } catch (error: unknown) {45 const e = error as { message: string };46 return NextResponse.json({ error: e.message }, { status: 500 });47 }48}Pro tip: Sinch supports sending to up to 1,000 recipients in a single batch API call. For bulk notifications (newsletters, alerts), pass all recipients in one call rather than looping — it's faster and uses fewer API requests.
Expected result: POST to /api/sinch/send-sms with phone number(s) and message sends real SMS via Sinch. Returns a batch ID. Works in the Bolt preview during development.
Implement Number Verification OTP
Implement Number Verification OTP
Sinch Verification provides a managed OTP service specifically for phone number verification. Unlike building your own OTP (generate code, send SMS, store and check), Sinch Verification handles the entire lifecycle: code generation, SMS or voice delivery, expiry management, attempt limits, and fraud prevention. The Verification API flow has two steps. First, initiate verification: POST /verifications/number with the phone number and method ('sms' or 'callout'). Sinch sends the code to the user's phone. The response includes a status of 'PENDING'. Second, verify the code: PUT /verifications/number/{phoneNumber} with the code the user entered. If correct and not expired, the response status is 'SUCCESSFUL'. Sinch Verification uses different credentials from the SMS API — the app key and app secret from your Verification app. These are different services in Sinch's platform and cannot share credentials. Ensure you have both sets of credentials configured.
Create Sinch Verification OTP routes. First, /api/sinch/verify/start (POST): accepts phoneNumber (E.164), calls sinchVerificationFetch POST /verifications/number with identity: {type: 'number', endpoint: phoneNumber} and method: 'sms'. Return the verification status. Second, /api/sinch/verify/check (POST): accepts phoneNumber and code, calls sinchVerificationFetch PUT /verifications/number/{phoneNumber} with sms: {code}. Return {verified: true} on SUCCESSFUL status. Build a two-step verification UI component for phone signup.
Paste this in Bolt.new chat
1// app/api/sinch/verify/start/route.ts2import { NextResponse } from 'next/server';3import { sinchVerificationFetch } from '@/lib/sinch';45export async function POST(request: Request) {6 try {7 const { phoneNumber } = await request.json();89 const result = await sinchVerificationFetch('/verifications/number', 'POST', {10 identity: { type: 'number', endpoint: phoneNumber },11 method: 'sms',12 });1314 return NextResponse.json({ status: 'pending', result });15 } catch (error: unknown) {16 const e = error as { message: string };17 return NextResponse.json({ error: e.message }, { status: 500 });18 }19}2021// app/api/sinch/verify/check/route.ts22export async function POST(request: Request) {23 try {24 const { phoneNumber, code } = await request.json();25 const encoded = encodeURIComponent(phoneNumber);2627 const result = await sinchVerificationFetch<{ status: string }>(28 `/verifications/number/${encoded}`,29 'PUT',30 { sms: { code } }31 );3233 const verified = result.status === 'SUCCESSFUL';34 return NextResponse.json({ verified, status: result.status });35 } catch (error: unknown) {36 const e = error as { message: string };37 return NextResponse.json({ error: e.message }, { status: 500 });38 }39}Pro tip: Sinch Verification has built-in rate limiting to prevent OTP abuse — typically 5 attempts per phone number per hour. This protection is automatic and does not require any configuration.
Expected result: POST to /api/sinch/verify/start sends an OTP SMS to the phone number. POST to /api/sinch/verify/check with the received code returns {verified: true}. Both work in the Bolt preview.
Deploy and Configure Inbound Message Webhooks
Deploy and Configure Inbound Message Webhooks
All outbound Sinch operations (sending SMS, verification) work in the Bolt preview. Receiving inbound messages — when users reply to your SMS or text your Sinch number — requires Sinch to send HTTP callbacks to your server. Since Bolt's WebContainer has no public URL, webhooks cannot reach it during development. Deploy first, then configure. Deploy your Bolt project to Netlify via Settings → Applications → Netlify. After deploying, add your Sinch environment variables in Netlify (Site Settings → Environment Variables): SINCH_SERVICE_PLAN_ID, SINCH_API_TOKEN, SINCH_SENDER_NUMBER. Redeploy to apply variables. To configure inbound message callbacks in Sinch: go to dashboard.sinch.com → SMS → Service Plans → click your plan → Callback URLs. Set the 'Incoming Message Callback URL' to your deployed endpoint (e.g., https://your-app.netlify.app/api/sinch/incoming). Sinch sends POST requests with a JSON body containing the message data when someone replies to your number. For delivery reports (confirming a message was delivered), set the 'Delivery Report Callback URL' as well. Delivery reports include the batch ID, recipient number, and delivery status.
Create a Sinch inbound message webhook handler at /api/sinch/incoming (POST). Parse the Sinch webhook JSON body which contains: type ('mo_text' for incoming SMS), to (your Sinch number), from (sender's number), body (message text), id (message ID). Save inbound messages to a Supabase messages table with from, body, and received_at. Return HTTP 200 with {status: 'ok'}. This endpoint must be deployed — it cannot be tested in the Bolt preview.
Paste this in Bolt.new chat
1// app/api/sinch/incoming/route.ts2import { NextResponse } from 'next/server';34interface SinchInboundMessage {5 type: 'mo_text' | 'mo_binary';6 from: string;7 to: string;8 body: string;9 id: string;10 received_at: string;11}1213export async function POST(request: Request) {14 try {15 const message = await request.json() as SinchInboundMessage;1617 console.log(`Inbound SMS from ${message.from}: ${message.body}`);18 // Save to database:19 // await supabase.from('messages').insert({20 // from_number: message.from,21 // body: message.body,22 // sinch_id: message.id,23 // received_at: message.received_at,24 // });2526 // Return 200 quickly — Sinch retries if it doesn't receive 20027 return NextResponse.json({ status: 'ok' });28 } catch (error: unknown) {29 const e = error as { message: string };30 console.error('Sinch webhook error:', e.message);31 return NextResponse.json({ status: 'ok' }); // Return 200 even on errors to prevent retries32 }33}Pro tip: Always return HTTP 200 from Sinch webhooks even when processing fails. Sinch retries delivery of webhooks that don't receive a 200 response, which can result in duplicate message processing. Acknowledge receipt immediately and handle business logic errors separately.
Expected result: After deploying and configuring the callback URL in the Sinch dashboard, inbound SMS messages to your Sinch number trigger the webhook handler. The message is logged and saved to your database.
Common use cases
Transactional SMS Notifications
Send order confirmations, shipping updates, appointment reminders, and security alerts to users via SMS. Sinch's competitive global pricing makes it cost-effective for high-volume notifications. The API route accepts recipient numbers and messages, validates input, and sends via Sinch's Messages API.
Create a Sinch SMS notification system. Create an API route at /api/sinch/send-sms (POST) that accepts 'to' (array of E.164 phone numbers, max 10) and 'message' (string). Use HTTP Basic auth with SINCH_SERVICE_PLAN_ID and SINCH_API_TOKEN from env. POST to https://us.sms.api.sinch.com/xms/v1/{servicePlanId}/batches with the recipients and message body. Return the batch ID. Add a notification preferences form where users enter their phone number to receive order updates.
Copy this prompt to try it in Bolt.new
RCS Rich Messaging for Android Users
Send RCS messages with images, buttons, and branded sender identity to Android users. RCS messages look like native app messages with your company logo and colors. Fall back to SMS automatically for users whose devices don't support RCS. Build an order update flow that sends rich confirmation messages with tracking links as buttons.
Build an RCS order confirmation message. Create an API route at /api/sinch/send-rcs (POST) that accepts orderId, customerPhone, trackingUrl, and estimatedDelivery. Use the Sinch RCS API to send a rich message with: branded header (store logo), order summary text, and a 'Track Package' button that opens the trackingUrl. Fall back to a plain SMS if RCS is not available. Use SINCH_PROJECT_ID and SINCH_KEY_ID and SINCH_KEY_SECRET for RCS auth. Display send confirmation and message ID on success.
Copy this prompt to try it in Bolt.new
Phone Number Verification OTP
Verify user phone numbers during signup using Sinch Verification. Users enter their phone number, receive a 6-digit PIN via SMS, and enter it to complete verification. Sinch handles code generation, expiry, rate limiting, and multi-channel fallback (SMS → voice). Simpler than building OTP logic yourself.
Implement phone verification with Sinch Verification API. Create two API routes: /api/sinch/verify/start (POST) that accepts phoneNumber in E.164 format and initiates a Sinch SMS verification by calling POST https://verificationapi-v1.sinch.com/verification/v1/verifications/number with method:sms. Create /api/sinch/verify/check (POST) that accepts phoneNumber and code, then calls PUT https://verificationapi-v1.sinch.com/verification/v1/verifications/number/{phoneNumber} to verify. Use SINCH_VERIFICATION_APP_KEY and SINCH_VERIFICATION_APP_SECRET from env. Build a two-step verification UI.
Copy this prompt to try it in Bolt.new
Troubleshooting
API returns 401 Unauthorized or 'Authentication failed'
Cause: SINCH_SERVICE_PLAN_ID or SINCH_API_TOKEN is incorrect. The Basic auth username must be the Service Plan ID (UUID format), not your Sinch account email. The password is the API Token, not your account password.
Solution: Go to dashboard.sinch.com → SMS → Service Plans → click your service plan. Copy the 'Service Plan ID' (looks like a UUID: 'a5a17e88-xxxx-xxxx-xxxx-xxxxxxxxxxxx') and the 'API Token'. These are different from your Sinch login credentials. Verify no whitespace was copied around the values in your .env file.
1// Debug: log partial credentials to verify (never log full credentials):2console.log('Service Plan ID format:', process.env.SINCH_SERVICE_PLAN_ID?.slice(0, 8) + '...');3// Should look like: a5a17e88-...Message sends but never arrives at destination
Cause: The sender number may not be activated for SMS in the recipient's country, or the recipient number format is incorrect. Sinch shared numbers have geographic restrictions.
Solution: Verify the destination number is in E.164 format (+1XXXXXXXXXX for US). Check your Sinch dashboard's message logs for delivery status and error codes. For international SMS, ensure your service plan has international messaging enabled and the sender number supports that destination country.
Sinch Verification returns 'FAILED' instead of 'SUCCESSFUL'
Cause: The code entered is incorrect, the verification has expired (typically 5 minutes), or too many failed attempts have triggered rate limiting.
Solution: Sinch Verification codes expire after 5 minutes by default. If the user took too long, they need to request a new code. Implement a resend flow in your UI. After 5 failed attempts, the verification is blocked for the hour — inform users with a clear error message rather than a generic failure.
1// Check specific failure reason in the response:2if (result.status === 'FAILED') {3 // Check result.reason for: 'EXPIRED', 'TOO_MANY_ATTEMPTS', 'WRONG_CODE'4 const reason = result.reason || 'UNKNOWN';5 return NextResponse.json(6 { verified: false, reason },7 { status: 400 }8 );9}Inbound SMS webhooks not received during Bolt development
Cause: This is expected. Sinch inbound message callbacks are outbound HTTP POST requests from Sinch's infrastructure to your endpoint. Bolt's WebContainer runs inside a browser tab with no public URL.
Solution: Deploy to Netlify or Bolt Cloud first. After deployment, configure the 'Incoming Message Callback URL' in your Sinch service plan settings to point to your deployed API endpoint. Use Sinch's dashboard message logs to verify that inbound messages are received and the callback is being attempted.
Best practices
- Store SINCH_SERVICE_PLAN_ID, SINCH_API_TOKEN, and verification credentials as server-side environment variables only — never use NEXT_PUBLIC_ prefix for communication API credentials
- Use Sinch's batch API for bulk sending rather than individual API calls in a loop — a single batch call can send to 1,000 recipients and is dramatically more efficient
- Always return HTTP 200 from Sinch webhook handlers before processing — Sinch retries webhooks that don't get a quick 200 response, potentially causing duplicate message delivery
- Validate phone numbers to E.164 format before sending to Sinch — invalid formats cause API errors and wasted credits
- Use Sinch Verification for OTP instead of building custom code generation — it handles expiry, rate limiting, and fraud prevention automatically
- Store Sinch batch IDs after sending so you can later check delivery reports for each batch — important for debugging undelivered notifications
- For RCS messages, always implement SMS fallback — only about 60% of Android users have RCS enabled, and iOS users don't have it at all
Alternatives
Twilio has the largest developer ecosystem, most extensive documentation, and the Twilio Verify managed OTP service, making it the default choice despite higher per-message pricing than Sinch.
Plivo offers 40-60% lower SMS costs than most competitors with an npm package that integrates cleanly into Next.js API routes, ideal for price-sensitive high-volume SMS applications.
Vonage provides strong EU and APAC coverage with a unified API for SMS, voice, and WhatsApp Business messaging, better for international-first applications.
Bandwidth operates its own carrier network for lower latency and direct relationships, suitable for enterprise applications that need carrier-grade reliability and dedicated numbers.
Frequently asked questions
Does Sinch have an npm package that works in Bolt's WebContainer?
Yes. The @sinch/sdk-core npm package is pure JavaScript and works in Bolt's WebContainer. Alternatively, you can use the raw REST API with fetch(), which also works perfectly. Both approaches communicate over HTTPS and have no native binary dependencies. The raw fetch approach is simpler to set up; the SDK provides TypeScript types and method signatures for each API operation.
What makes Sinch different from Twilio for SMS?
Sinch's primary differentiators are RCS support (rich messaging on Android with images and buttons), competitive global pricing especially in Asian and Latin American markets, and its email capabilities through Mailgun and SparkPost acquisitions. Twilio has a larger developer community, more extensive documentation, and the Twilio Verify service for managed OTP. For pure SMS volume in regions where Sinch has strong carrier relationships, Sinch can be 20-40% cheaper than Twilio.
What is RCS and does it work with all phones?
RCS (Rich Communication Services) is an upgraded messaging standard that enables branded sender identity, images, carousels, quick reply buttons, and read receipts — similar to iMessage but for Android's native messaging app. RCS works on Android devices with Google Messages and an RCS-enabled carrier. It does NOT work on iOS (Apple uses iMessage instead). For RCS messages, Sinch automatically falls back to standard SMS when the recipient's device doesn't support RCS, so you always need SMS fallback content.
Can I send MMS (picture messages) with Sinch?
Yes. Sinch supports MMS in the US and Canada. To send an MMS, use the same batch API endpoint but include a media_urls array in the request body alongside the text body. Media URLs must be publicly accessible HTTPS URLs. MMS pricing is higher than SMS — typically $0.01-0.03 per message compared to $0.003-0.008 for SMS. US-only carriers impose size limits (typically 600KB for MMS attachments).
How do I test Sinch SMS without spending credits?
Sinch trial accounts include free credits sufficient for testing. Sinch does not have a separate sandbox with fake numbers like Twilio's test credentials — your test messages use real credits but the amounts are small ($0.003-0.008 per message). Create a test phone number in your Sinch service plan and send test messages to your own verified mobile number. Check the message logs in the Sinch dashboard to verify delivery without waiting for the physical message.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation