Building a Bulk Broadcast Messaging System with Sinch, Node.js, and Next.js

This guide provides a complete walkthrough for building a Next.js application capable of sending bulk or broadcast messages using the Sinch Conversation API (Application Programming Interface). We'll cover everything from project setup and core implementation to security, error handling, and deployment.

This implementation enables you to leverage Sinch's robust communication infrastructure for sending notifications, alerts, or marketing messages to multiple recipients efficiently directly from your Next.js application. By the end, you'll have a functional API endpoint and a basic interface to trigger bulk message sends.

Project Overview and Goals

What You're Building:

• A Next.js application with a serverless API route (/api/send-bulk).
• A simple frontend form to input a list of recipient phone numbers and a message body.
• Backend logic to interact with the Sinch Conversation API to send messages individually to each recipient in the list (simulating a bulk send).
• Secure handling of API credentials.
• Error handling, logging, and a basic retry mechanism.

Problem Solved: This guide addresses your need to programmatically send the same message content to a list of recipients via Short Message Service (SMS) (or other channels supported by the Conversation API) using Sinch, integrated within a modern web framework like Next.js.

Technologies Used:

• Next.js: A React framework for building server-side rendering (SSR) and static web applications, including API routes for backend logic. Chosen for its developer experience, performance, and integrated API capabilities. Note: Next.js 15.5 (latest as of October 2025) requires Node.js 18.18+, but Node.js 18 support is deprecated in Next.js 15.4+ – use Node.js 20 or 22 for future compatibility. [Source: Next.js 15.5 Release Notes]
• Sinch Conversation API: A unified API for sending and receiving messages across various channels (SMS, WhatsApp, etc.). Chosen for its channel flexibility and robust infrastructure.
• Node.js: The underlying runtime for Next.js. Note: Node.js v18 reaches End-of-Life on April 30, 2025 – migrate to v20 (Maintenance LTS – Long-Term Support) or v22 (Active LTS until October 2025, then Maintenance until April 2027) for production use. [Source: Node.js Release Schedule]
• Axios: For making HTTP (Hypertext Transfer Protocol) requests to the Sinch API. Note: Use axios v1.12.2 or later to address CVE-2025-58754 (Denial of Service vulnerability). [Source: npm axios security advisories]
• jsonwebtoken: Not required for Sinch authentication (Sinch uses OAuth2.0 tokens, not self-generated JSON Web Tokens – JWTs), but included if you need internal application tokens.
• libphonenumber-js: For phone number validation and formatting.
• (Optional) Prisma & PostgreSQL: For persistent storage of contacts or message logs (discussed conceptually).

System Architecture:

User Browser --(1. Submits Form)--> Next.js Frontend
Next.js Frontend --(2. POST Request)--> Next.js API Route (/api/send-bulk)
Next.js API Route --(3. Reads Credentials)--> Environment Variables (.env.local)
Next.js API Route --(4. Loops through Recipients)--> For Each Recipient
  For Each Recipient --(5. Prepare & Send Request w/ Retries)--> Sinch Conversation API
    Sinch Conversation API --(6. Send Message)--> Recipient Phone
    Sinch Conversation API --(7. API Response)--> For Each Recipient
  For Each Recipient --(8. Aggregated Results)--> Next.js API Route
Next.js API Route --(9. API Response)--> Next.js Frontend
Next.js Frontend --(10. Display Status)--> User Browser

Prerequisites:

• Node.js (v20 or v22 recommended for Next.js 15.5+ compatibility) – Note: Node.js 18 reaches EOL (End-of-Life) April 30, 2025 and is deprecated in Next.js 15.4+. [Source: Node.js Release Schedule, Next.js 15.4 Release Notes]
• npm/yarn/pnpm package manager
• A Sinch account with access to the Conversation API.
• A registered Sinch Application (APP_ID) within your Sinch project.
• Sinch API Credentials:
  • SINCH_PROJECT_ID: Your project's unique identifier.
  • SINCH_ACCESS_KEY_ID: The Key ID for your API access key pair (used as OAuth2.0 client_id).
  • SINCH_ACCESS_KEY: The Key Secret for your API access key pair (used as OAuth2.0 client_secret, treat like a password).
• A provisioned phone number or sender ID from Sinch capable of sending messages, linked to your APP_ID.
• Important: Determine your Sinch regional server (US, EU, or BR) based on where you created your Conversation API app. [Source: Sinch Conversation API Documentation]

Expected Outcome: A Next.js application where you can input a comma-separated list of phone numbers, type a message, and click "Send". Your application's backend will then iterate through the numbers and attempt to send the message to each via the Sinch Conversation API, providing feedback on success or failure.

1. Setting up the Project

Initialize a new Next.js project and configure the necessary environment.

1.1 Create Next.js App:

Open your terminal and run the following command:

npx create-next-app@latest sinch-bulk-messaging --typescript --eslint --tailwind --src-dir --app --import-alias "@/*"

• sinch-bulk-messaging: Your project name.
• --typescript: Enables TypeScript (recommended).
• --eslint: Includes ESLint for code linting.
• --tailwind: Includes Tailwind CSS for styling (optional).
• --src-dir: Creates a src directory for code.
• --app: Uses the App Router (standard for new projects).
• --import-alias "@/*": Configures path aliases.

Navigate into your new project directory:

cd sinch-bulk-messaging

1.2 Install Dependencies:

Install axios for API requests (v1.12.2+ for security), and libphonenumber-js for validation. The jsonwebtoken package is not required for Sinch OAuth2.0 authentication.

npm install axios libphonenumber-js
# Note: axios v1.12.2+ required to address CVE-2025-58754 (DoS vulnerability)

# or using yarn
# yarn add axios libphonenumber-js

# or using pnpm
# pnpm add axios libphonenumber-js

1.3 Configure Environment Variables:

Create a file named .env.local in the root of your project. Never commit this file to version control.

# .env.local

# Sinch API Credentials (Obtain from your Sinch Dashboard)
SINCH_PROJECT_ID="YOUR_SINCH_PROJECT_ID"
SINCH_ACCESS_KEY_ID="YOUR_SINCH_ACCESS_KEY_ID"    # The Key ID (OAuth2.0 client_id)
SINCH_ACCESS_KEY="YOUR_SINCH_ACCESS_KEY_SECRET" # The Key Secret (OAuth2.0 client_secret)
SINCH_APP_ID="YOUR_REGISTERED_SINCH_APP_ID"

# Sender ID (e.g., your provisioned Sinch phone number in E.164 format)
# This MUST be associated with your SINCH_APP_ID
SINCH_SENDER_ID="YOUR_SINCH_PHONE_NUMBER_OR_SENDER_ID"

# Sinch API Region Base URL – MUST match the region where you created your app
# US: https://us.conversation.api.sinch.com
# EU: https://eu.conversation.api.sinch.com
# BR: https://br.conversation.api.sinch.com
# [Source: Sinch Conversation API Base URLs]
SINCH_API_BASE_URL="https://us.conversation.api.sinch.com"

# OAuth2.0 Token Endpoint (same for all regions)
SINCH_AUTH_URL="https://auth.sinch.com/oauth2/token"

• Why .env.local? Next.js automatically loads variables from this file into process.env on the server side. It's designated for secret keys and should be listed in your .gitignore file (which create-next-app does by default).
• Obtaining Credentials: Log in to your Sinch account/portal. Navigate to your Project settings and API access keys section to find your SINCH_PROJECT_ID and create an ACCESS_KEY (consisting of a Key ID (SINCH_ACCESS_KEY_ID) and a Key Secret (SINCH_ACCESS_KEY)). Find your Application (SINCH_APP_ID) under the Conversation API section or Apps. Your SINCH_SENDER_ID is the phone number or identifier you've configured within Sinch to send messages from. Ensure this sender is linked to your SINCH_APP_ID.
• Regional Server: Your base URL must correspond to the region where you created your Conversation API app. Using the wrong region will result in 404 errors. [Source: Sinch Conversation API Documentation]

1.4 Project Structure:

Your src directory will primarily contain:

• app/: App Router files (pages, layouts, API routes).
  • page.tsx: The main frontend page with the form.
  • api/send-bulk/route.ts: The API route handler for sending messages.
• lib/: Utility functions (e.g., Sinch API interaction logic).

This structure separates your frontend, backend (API routes), and reusable logic.

2. Implementing Core Functionality

Build the frontend form and the backend API route logic.

2.1 Frontend Form (src/app/page.tsx):

Replace the contents of src/app/page.tsx with a simple form:

// src/app/page.tsx
'use client'; // Required for interactive components in App Router

import { useState } from 'react';
import axios from 'axios';

export default function HomePage() {
  const [recipients, setRecipients] = useState('');
  const [message, setMessage] = useState('');
  const [status, setStatus] = useState('');
  const [isLoading, setIsLoading] = useState(false);

  const handleSubmit = async (event: React.FormEvent<HTMLFormElement>) => {
    event.preventDefault();
    setIsLoading(true);
    setStatus('Sending messages…');

    // Basic validation
    if (!recipients.trim() || !message.trim()) {
      setStatus('Please enter recipients and a message.');
      setIsLoading(false);
      return;
    }

    // Split recipients string into an array, trim whitespace, filter empty strings
    const recipientList = recipients
      .split(',')
      .map(num => num.trim())
      .filter(num => num.length > 0);

    if (recipientList.length === 0) {
        setStatus('Invalid recipient list.');
        setIsLoading(false);
        return;
    }

    try {
      const response = await axios.post('/api/send-bulk', {
        recipients: recipientList,
        message,
      });

      if (response.data.success) {
        setStatus(`Successfully initiated sending to ${response.data.sentCount} recipients. Failures: ${response.data.failedCount}.`);
        // Optionally display failure details if needed: response.data.failures
      } else {
        setStatus(`Error: ${response.data.error || 'Failed to send messages.'}`);
      }
    } catch (error: any) {
      console.error('Error sending bulk message:', error);
      const errorMessage = error.response?.data?.error || error.message || 'An unexpected error occurred.';
      setStatus(`Error: ${errorMessage}`);
    } finally {
      setIsLoading(false);
    }
  };

  return (
    <main className="flex min-h-screen flex-col items-center justify-center p-12 bg-gray-50">
      <div className="w-full max-w-md p-8 space-y-6 bg-white rounded-lg shadow-md">
        <h1 className="text-2xl font-bold text-center text-gray-800">Sinch Bulk Message Sender</h1>

        <form onSubmit={handleSubmit} className="space-y-4">
          <div>
            <label htmlFor="recipients" className="block text-sm font-medium text-gray-700">
              Recipients (comma-separated phone numbers, e.g., +15551234567,+447700900000)
            </label>
            <textarea
              id="recipients"
              name="recipients"
              rows={3}
              value={recipients}
              onChange={(e) => setRecipients(e.target.value)}
              required
              className="mt-1 block w-full px-3 py-2 border border-gray-300 rounded-md shadow-sm focus:outline-none focus:ring-indigo-500 focus:border-indigo-500 sm:text-sm"
              placeholder="+15551234567,+447700900000"
            />
          </div>

          <div>
            <label htmlFor="message" className="block text-sm font-medium text-gray-700">
              Message
            </label>
            <textarea
              id="message"
              name="message"
              rows={4}
              value={message}
              onChange={(e) => setMessage(e.target.value)}
              required
              className="mt-1 block w-full px-3 py-2 border border-gray-300 rounded-md shadow-sm focus:outline-none focus:ring-indigo-500 focus:border-indigo-500 sm:text-sm"
              placeholder="Enter your message here…"
            />
          </div>

          <div>
            <button
              type="submit"
              disabled={isLoading}
              className={`w-full flex justify-center py-2 px-4 border border-transparent rounded-md shadow-sm text-sm font-medium text-white ${
                isLoading ? 'bg-indigo-400 cursor-not-allowed' : 'bg-indigo-600 hover:bg-indigo-700 focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-indigo-500'
              }`}
            >
              {isLoading ? 'Sending…' : 'Send Bulk Message'}
            </button>
          </div>
        </form>

        {status && (
          <div className={`mt-4 p-3 rounded-md text-sm ${status.startsWith('Error:') ? 'bg-red-100 text-red-700' : 'bg-green-100 text-green-700'}`}>
            {status}
          </div>
        )}
      </div>
    </main>
  );
}

• 'use client': Marks this as a Client Component, necessary for using hooks like useState and handling events.
• State: Manages input values (recipients, message), loading state (isLoading), and status messages (status).
• handleSubmit: Prevents default form submission, performs basic validation, formats the recipient list, calls the /api/send-bulk endpoint, and updates the status based on the response.

2.2 Sinch API Utility (src/lib/sinch.ts):

Create a utility file to encapsulate Sinch API interactions with proper OAuth2.0 authentication.

// src/lib/sinch.ts
import axios, { AxiosInstance } from 'axios';

// --- Environment Variable Validation ---
const projectId = process.env.SINCH_PROJECT_ID;
const accessKeyId = process.env.SINCH_ACCESS_KEY_ID; // Key ID (OAuth2.0 client_id)
const accessKeySecret = process.env.SINCH_ACCESS_KEY; // Key Secret (OAuth2.0 client_secret)
const appId = process.env.SINCH_APP_ID;
const senderId = process.env.SINCH_SENDER_ID;
const sinchApiBaseUrl = process.env.SINCH_API_BASE_URL;
const sinchAuthUrl = process.env.SINCH_AUTH_URL || 'https://auth.sinch.com/oauth2/token';

if (!projectId || !accessKeyId || !accessKeySecret || !appId || !senderId || !sinchApiBaseUrl) {
    console.error("FATAL ERROR: Missing required Sinch environment variables.");
    throw new Error("Missing required Sinch environment variables.");
}
// --- End Environment Variable Validation ---

// --- OAuth2.0 Token Management ---
// Sinch uses OAuth2.0 client credentials flow for production authentication.
// Tokens are short-lived (1 hour) and should be cached and refreshed as needed.
// [Source: Sinch Conversation API Authentication Documentation]

let cachedAccessToken: string | null = null;
let tokenExpiryTime: number = 0;

async function getSinchAccessToken(): Promise<string> {
    // Check if we have a valid cached token
    const now = Math.floor(Date.now() / 1000);
    if (cachedAccessToken && tokenExpiryTime > now + 60) {
        // Token still valid for at least 1 more minute
        return cachedAccessToken;
    }

    console.log("Fetching new Sinch OAuth2.0 access token...");

    try {
        // OAuth2.0 client credentials grant
        // [Source: Sinch OAuth2.0 Authentication]
        const response = await axios.post(
            sinchAuthUrl,
            new URLSearchParams({
                grant_type: 'client_credentials'
            }),
            {
                auth: {
                    username: accessKeyId,
                    password: accessKeySecret
                },
                headers: {
                    'Content-Type': 'application/x-www-form-urlencoded'
                }
            }
        );

        const accessToken = response.data.access_token;
        const expiresIn = response.data.expires_in || 3600; // Default to 1 hour

        cachedAccessToken = accessToken;
        tokenExpiryTime = now + expiresIn;

        console.log(`New Sinch access token obtained. Expires in ${expiresIn} seconds.`);
        return accessToken;

    } catch (error: any) {
        console.error("Error obtaining Sinch OAuth2.0 access token:", error.response?.data || error.message);
        throw new Error("Failed to obtain Sinch authentication token.");
    }
}

// --- Axios Instance for Sinch API ---
const sinchApiClient = axios.create({
    baseURL: sinchApiBaseUrl,
    headers: {
        'Content-Type': 'application/json',
        'Accept': 'application/json',
    },
    timeout: 15000, // 15 seconds
});

// Add an interceptor to dynamically add the Authorization header
sinchApiClient.interceptors.request.use(async (config) => {
    try {
        const token = await getSinchAccessToken();
        config.headers.Authorization = `Bearer ${token}`;
        return config;
    } catch (error) {
        console.error("Error setting Sinch auth header:", error);
        return Promise.reject(new Error('Failed to set Sinch authentication header.'));
    }
}, (error) => {
    return Promise.reject(error);
});

// --- Send Message Function ---
export interface SendMessageResult {
    success: boolean;
    messageId?: string;
    error?: string;
    recipient: string;
    status?: number;
}

export async function sendSinchMessage(recipient: string, messageBody: string): Promise<SendMessageResult> {
    // Basic phone number validation (E.164 format)
    if (!/^\+?[1-9]\d{1,14}$/.test(recipient)) {
         console.warn(`Invalid phone number format skipped: ${recipient}`);
         return { success: false, error: 'Invalid phone number format', recipient, status: 400 };
    }

    // Sinch Conversation API endpoint for sending messages
    // [Source: Sinch Conversation API - Send Message Endpoint]
    const endpoint = `/v1/projects/${projectId}/messages:send`;

    // Payload structure verified against Sinch Conversation API documentation
    // [Source: Sinch Conversation API Message Payload Structure]
    const payload = {
        app_id: appId,
        recipient: {
            identified_by: {
                channel_identities: [
                    {
                        channel: "SMS",
                        identity: recipient // E.164 phone number
                    }
                ]
            }
        },
        message: {
            text_message: {
                text: messageBody
            }
        },
        channel_priority_order: ["SMS"] // Prioritize SMS channel
    };

    try {
        console.log(`Attempting to send message via Sinch to ${recipient}...`);
        const response = await sinchApiClient.post(endpoint, payload);

        // Sinch returns message_id in the response
        const messageId = response.data?.message_id || 'N/A';

        if (response.status >= 200 && response.status < 300) {
             console.log(`Message accepted by Sinch for ${recipient}. Message ID: ${messageId}, Status: ${response.status}`);
            return { success: true, messageId: messageId, recipient, status: response.status };
        } else {
            console.warn(`Sinch API returned non-success status ${response.status} for ${recipient}:`, response.data);
            return { success: false, error: `Sinch API Error: Status ${response.status}`, recipient, status: response.status };
        }
    } catch (error: any) {
        let errorMessage = 'Unknown Sinch API error';
        let status = 500;

        if (axios.isAxiosError(error)) {
            status = error.response?.status || 500;
            const errorData = error.response?.data;
            const sinchError = errorData?.error?.message || JSON.stringify(errorData);
            errorMessage = `Sinch API Error (${status}): ${sinchError || error.message}`;
            console.error(`Sinch API error for ${recipient}: Status ${status}, Data:`, errorData || error.message);
        } else {
            console.error(`Non-Axios error sending to ${recipient}:`, error);
            errorMessage = error.message || 'An unexpected error occurred during Sinch request.';
        }
        return { success: false, error: errorMessage, recipient, status };
    }
}

// --- Retry Mechanism ---
export async function sendSinchMessageWithRetry(
    recipient: string,
    messageBody: string,
    maxRetries = 2
): Promise<SendMessageResult> {
    let attempt = 0;
    while (attempt <= maxRetries) {
        const result = await sendSinchMessage(recipient, messageBody);

        if (result.success) {
            return result;
        }

        attempt++;

        // Retry on rate limit (429) or server errors (5xx)
        // [Source: Sinch Conversation API Rate Limits and Error Codes]
        const isRetryable = result.status === 429 || result.status >= 500;
        const shouldRetry = isRetryable && attempt <= maxRetries;

        if (!shouldRetry) {
            if (isRetryable) {
                 console.warn(`Send failed permanently for ${recipient} after ${attempt} attempts. Error: ${result.error}`);
            }
            return result;
        }

        // Exponential backoff with jitter
        const delay = Math.pow(2, attempt - 1) * 200 + Math.random() * 100;
        console.log(`Retrying send for ${recipient} (attempt ${attempt}/${maxRetries + 1}) after ${Math.round(delay)}ms due to status ${result.status}...`);
        await new Promise(resolve => setTimeout(resolve, delay));
    }

    return { success: false, error: `Max retries (${maxRetries}) exceeded`, recipient, status: -1 };
}

• OAuth2.0 Authentication: Implements the correct OAuth2.0 client credentials flow required by Sinch for production use. Access tokens are short-lived (1 hour) and are cached and refreshed automatically. [Source: Sinch Conversation API Authentication Documentation]
• Token Caching: Caches your access token and refreshes it before expiry to avoid unnecessary token requests.
• Axios Instance: Configured with your regional base URL and automatic Bearer token injection via interceptor.
• Message Payload: Uses the correct structure for Sinch Conversation API's /messages:send endpoint with proper recipient identification and channel specification. [Source: Sinch Conversation API Message Structure]
• Error Handling: Comprehensive error handling with Sinch-specific error message extraction.
• Retry Logic: Retries only on retryable HTTP status codes (429 rate limit, 5xx server errors) with exponential backoff.

2.3 Backend API Route (src/app/api/send-bulk/route.ts):

Create the API route handler.

// src/app/api/send-bulk/route.ts
import { NextResponse } from 'next/server';
import { sendSinchMessageWithRetry, SendMessageResult } from '@/lib/sinch'; // Use retry wrapper

export async function POST(request: Request) {
  console.log("Received request on /api/send-bulk");

  let requestBody;
  try {
    requestBody = await request.json();
  } catch (error) {
    console.error("Error parsing request body:", error);
    return NextResponse.json({ success: false, error: 'Invalid request body. Must be JSON.' }, { status: 400 });
  }

  const { recipients, message } = requestBody;

  // --- Input Validation ---
  if (!Array.isArray(recipients) || recipients.length === 0) {
    return NextResponse.json({ success: false, error: '`recipients` must be a non-empty array of strings.' }, { status: 400 });
  }
  if (typeof message !== 'string' || !message.trim()) {
    return NextResponse.json({ success: false, error: '`message` must be a non-empty string.' }, { status: 400 });
  }
  // Consider adding more validation (e.g., max recipients, message length)
  const MAX_RECIPIENTS = 1000; // Example limit
  if (recipients.length > MAX_RECIPIENTS) {
     return NextResponse.json({ success: false, error: `Too many recipients. Maximum allowed is ${MAX_RECIPIENTS}.` }, { status: 400 });
  }
  // --- End Input Validation ---


  // --- Rate Limiting (Conceptual – Implement with a library) ---
  // In production, add rate limiting here using libraries like '@upstash/ratelimit'
  // const ip = request.headers.get('x-forwarded-for') ?? '127.0.0.1';
  // const { success } = await rateLimiter.limit(ip);
  // if (!success) {
  //   console.warn(`Rate limit exceeded for IP: ${ip}`);
  //   return NextResponse.json({ error: 'Rate limit exceeded' }, { status: 429 });
  // }
  // --- End Rate Limiting ---

  console.log(`Initiating bulk send to ${recipients.length} recipients.`);

  // Send messages concurrently using the retry wrapper
  // Use Promise.allSettled to wait for all attempts, even failures
  const sendPromises: Promise<SendMessageResult>[] = recipients.map(recipient =>
    sendSinchMessageWithRetry(String(recipient), message) // Ensure recipient is string, call retry wrapper
  );

  let results: SendMessageResult[] = [];
  try {
    const settledResults = await Promise.allSettled(sendPromises);

    results = settledResults.map((result, index) => {
        const recipient = String(recipients[index]); // Get corresponding recipient
        if (result.status === 'fulfilled') {
            // Promise resolved (sendSinchMessageWithRetry returned a result)
            return result.value; // Contains { success: boolean, messageId?, error?, recipient, status? }
        } else {
            // Promise rejected (unexpected error in sendSinchMessageWithRetry itself, less likely)
            console.error(`Unexpected failure sending to ${recipient}:`, result.reason);
            return {
                success: false,
                error: result.reason?.message || 'Unknown error during promise execution',
                recipient: recipient,
                status: 500 // Indicate internal server error
            };
        }
    });

  } catch (error) {
      // Catch errors in the Promise.allSettled processing itself (unlikely)
      console.error("Catastrophic error processing bulk send results:", error);
      return NextResponse.json({ success: false, error: 'Server error processing send results' }, { status: 500 });
  }

  const sentCount = results.filter(r => r.success).length;
  const failedCount = results.length - sentCount;
  // Collect details only for failures
  const failures = results
      .filter(r => !r.success)
      .map(r => ({ recipient: r.recipient, error: r.error, status: r.status }));

  console.log(`Bulk send processing completed. Accepted by Sinch: ${sentCount}, Failed Attempts: ${failedCount}`);
  if (failedCount > 0) {
      console.warn("Failures occurred:", JSON.stringify(failures, null, 2)); // Log failure details
  }

  // Return a summary response
  return NextResponse.json({
    success: true, // Indicates the API call itself succeeded in processing
    sentCount,     // Count of messages accepted by Sinch (after retries)
    failedCount,   // Count of messages that failed all attempts
    // Optionally include failure details, but be mindful of response size for large lists
    failures: failedCount > 0 ? failures : undefined,
  });
}

• Imports: NextResponse, sendSinchMessageWithRetry, SendMessageResult.
• POST Handler: Standard structure for Next.js App Router API routes.
• Body Parsing & Validation: Safely parses JSON, validates recipients array and message string, includes an example max recipient limit.
• Rate Limiting Placeholder: Comments indicate where to integrate rate limiting.
• Concurrent Sending with Retries: Uses recipients.map with sendSinchMessageWithRetry and Promise.allSettled. This ensures each message attempt benefits from the retry logic, and the API waits for all attempts to complete or fail definitively.
• Result Aggregation: Processes allSettled results, distinguishing between fulfilled promises (which contain the SendMessageResult) and rejected promises (unexpected errors). Counts successes and failures, collecting details for failures.
• Response: Returns a JSON response summarizing the outcome (sentCount, failedCount, optional failures details).

3. Building a Complete API Layer

Your /api/send-bulk/route.ts file constitutes your basic API layer.

• Authentication/Authorization:
  • End-User Auth: This example lacks end-user authentication. In a real app, protect this API route using methods like NextAuth.js or Clerk to ensure only logged-in, authorized users can trigger sends. You'd verify the session/token within the POST handler.
  • Service Auth: Your route authenticates with Sinch using API keys stored securely as environment variables.

• Request Validation: Robust validation is crucial. The example includes basic checks. Enhance using libraries like zod for schema validation, including format checks (e.g., E.164 for numbers) and length limits.
  typescriptCopy

  // Example using Zod (install zod: npm install zod)
  import { z } from 'zod';
  
  const phoneRegex = /^\+?[1-9]\d{1,14}$/; // Basic E.164 regex
  
  const sendBulkSchema = z.object({
    recipients: z.array(z.string().regex(phoneRegex, { message: "Invalid phone number format. Use E.164." }))
                 .min(1, { message: "Recipients array cannot be empty." })
                 .max(1000, { message: "Maximum 1000 recipients allowed." }), // Example max limit
    message: z.string()
              .trim()
              .min(1, { message: "Message cannot be empty." })
              .max(1600, { message: "Message exceeds maximum length." }), // Example SMS max length (check channel specifics)
  });
  
  // Inside POST handler, before processing:
  // const validationResult = sendBulkSchema.safeParse(requestBody);
  // if (!validationResult.success) {
  //   return NextResponse.json(
  //     { success: false, error: 'Validation failed.', details: validationResult.error.flatten().fieldErrors },
  //     { status: 400 }
  //     );
  // }
  // Use validated data: validationResult.data.recipients, validationResult.data.message
  // const { recipients, message } = validationResult.data; // Destructure validated data

• API Endpoint Documentation (Summary):
  • Endpoint: POST /api/send-bulk
  • Description: Accepts a list of E.164 phone numbers and a message, attempts to send via Sinch SMS (with retries), and returns a summary.
  • Request Body (JSON): { "recipients": ["+1…", "+44…"], "message": "…" }
  • Success Response (200 OK): { "success": true, "sentCount": N, "failedCount": M, "failures": […] } (failures optional)
  • Error Responses: 400 (Bad Request/Validation), 429 (Rate Limit), 500 (Server Error).

• Testing with curl:
  bashCopy

  curl -X POST http://localhost:3000/api/send-bulk \
  -H "Content-Type: application/json" \
  -d '{
    "recipients": ["+1YOUR_TEST_NUMBER_1", "+1YOUR_TEST_NUMBER_2"],
    "message": "Hello from curl test!"
  }'

  (Replace localhost:3000 and use valid test numbers).

4. Integrating with Third-Party Services (Sinch)

This section details obtaining and configuring Sinch credentials and understanding authentication.

Ensure you have correctly obtained the following from your Sinch dashboard and placed them in .env.local:

• SINCH_PROJECT_ID
• SINCH_ACCESS_KEY_ID (OAuth2.0 client_id)
• SINCH_ACCESS_KEY (OAuth2.0 client_secret – Secret)
• SINCH_APP_ID
• SINCH_SENDER_ID (Your provisioned number/ID linked to the App ID)
• SINCH_API_BASE_URL (Correct regional URL: US, EU, or BR)

Authentication Methods:

1. OAuth2.0 Bearer Tokens (Production – Recommended):

   • Sinch uses OAuth2.0 client credentials flow for production authentication.
   • Access tokens are short-lived (1 hour typically) for enhanced security.
   • Obtain tokens by exchanging your Key ID and Key Secret at https://auth.sinch.com/oauth2/token.
   • This implementation automatically handles token caching and renewal.
   • [Source: Sinch Conversation API Authentication Documentation]

2. Basic Authentication (Testing Only – Not Recommended):

   • Basic auth uses Authorization: Basic <base64(keyId:keySecret)>.
   • Important: Basic authentication is heavily rate-limited and should only be used for testing and prototyping.
   • Use OAuth2.0 access tokens for production systems.
   • [Source: Sinch Conversation API Basic Authentication]

Regional Considerations:

Your API base URL must match the region where you created your Conversation API app:

• US: https://us.conversation.api.sinch.com
• EU: https://eu.conversation.api.sinch.com
• BR: https://br.conversation.api.sinch.com

Using the wrong regional URL will result in 404 errors. [Source: Sinch Conversation API Base URLs]

Rate Limits:

• Conversation API apps have a maximum MT (Mobile Terminated) ingress queue size of 500,000 messages, drained at 20 messages/second by default.
• Projects are limited to 800 requests/second across all apps and endpoints.
• Exceeding rate limits returns HTTP 429 (Too Many Requests).
• [Source: Sinch Conversation API Rate Limits]

5. Security Considerations

• Environment Variables: Keep .env.local out of version control (.gitignore). Use platform-specific environment variable management for deployment (Vercel, AWS Secrets Manager, etc.).
• Input Validation: Sanitize and validate all inputs (recipients, message) on the server-side (/api/send-bulk) to prevent injection attacks or malformed requests. Use libraries like zod. Validate phone number formats strictly (e.g., using libphonenumber-js for more robust validation than regex). Limit message length and recipient count.
• Rate Limiting: Implement rate limiting on your API endpoint (/api/send-bulk) to prevent abuse and manage costs. Use libraries like @upstash/ratelimit with Redis or similar solutions. Limit based on IP address, user ID (if authenticated), or other factors.
• Authentication: Protect your API endpoint so only authorized users or systems can trigger bulk sends. Use NextAuth.js, Clerk, or similar for user authentication, or API keys/tokens for system-to-system communication.
• Error Handling: Avoid leaking sensitive information (like full error stacks or internal paths) in API error responses sent to the client. Log detailed errors server-side.
• Sinch Credentials: Treat SINCH_ACCESS_KEY as highly sensitive. Ensure it's stored securely and never exposed client-side. Rotate keys periodically if possible.
• Dependencies: Keep dependencies (npm/yarn/pnpm) updated to patch security vulnerabilities (npm audit fix or similar).

6. Error Handling and Logging

• API Route: Your /api/send-bulk route uses try…catch for request parsing and Promise.allSettled to handle individual send failures gracefully. It logs errors and returns structured JSON responses (including failure details).
• Sinch Utility: sendSinchMessage catches Axios errors, extracts status codes and Sinch error messages, and returns a SendMessageResult. sendSinchMessageWithRetry handles retry logic based on status codes and logs retry attempts.
• Frontend: Your HomePage component uses try…catch for the axios.post call and updates the UI based on the API response (success, error, counts). It displays user-friendly status messages.
• Logging: Use a structured logging library (e.g., pino, winston) instead of console.log in production for better log management, filtering, and integration with monitoring services. Log key events: request received, validation success/failure, Sinch request initiation, Sinch response (success/failure, ID), retry attempts, final outcome. Include correlation IDs to track requests.

7. Deployment

• Platform: Choose a hosting platform for Next.js (Vercel, Netlify, AWS Amplify, self-hosting with Node.js).
• Environment Variables: Configure your production environment variables securely on the chosen platform. Do not commit .env.local.
• Build: Run npm run build (or yarn build, pnpm build) to create an optimized production build.
• Start: Use the platform's deployment mechanism or run npm start (or yarn start, pnpm start) to serve your application.
• HTTPS: Ensure your deployment uses HTTPS (Hypertext Transfer Protocol Secure). Most platforms handle this automatically.
• Monitoring: Set up monitoring and alerting (e.g., Sentry, Datadog, platform-specific tools) to track application health, errors, and API performance.
• Rate Limiting Service: Ensure your rate limiting infrastructure (e.g., Redis instance for Upstash) is available and configured for the production environment.

8. Conclusion and Next Steps

You have successfully built a Next.js application that can send bulk messages via the Sinch Conversation API. This includes a basic frontend, a robust API route with validation and error handling, and integration with Sinch using secure practices.

Potential Enhancements:

• Robust Phone Validation: Integrate libphonenumber-js fully in your API route for stricter E.164 validation and formatting.
• User Authentication: Add user login/signup (NextAuth.js, Clerk) to protect the sending functionality.
• Contact Management: Store recipient lists in a database (e.g., PostgreSQL with Prisma) instead of manual input.
• Message Templates: Allow users to select pre-defined message templates.
• Scheduling: Implement message scheduling capabilities.
• Delivery Status Tracking: Use Sinch webhooks (callback_url in the payload) to receive real-time delivery status updates and store/display them.
• Channel Selection: Extend the UI and API to support other Sinch channels (WhatsApp, etc.).
• Scalability: For very large lists, consider background job queues (e.g., BullMQ, Celery via an external service) to process sends asynchronously instead of relying solely on serverless function timeouts.
• Advanced Rate Limiting: Implement more sophisticated rate limiting strategies.
• UI Improvements: Enhance your frontend with better loading indicators, progress bars for large sends, and detailed result displays.

Deploy your application to a production environment like Vercel, Netlify, or AWS. Remember to properly configure your environment variables and monitor your application's performance.

Frequently Asked Questions

How do I send bulk SMS messages with Next.js and Sinch?

Create a Next.js API route that accepts recipient lists and message content, then use the Sinch Conversation API with OAuth2.0 authentication to send messages. Implement the client credentials flow to obtain access tokens, cache tokens for the 1-hour lifetime, and send individual messages to each recipient using the /messages:send endpoint with proper E.164 formatted phone numbers. Use Promise.all() or batch processing for concurrent sends while respecting rate limits.

What is Sinch Conversation API authentication and how does OAuth2.0 work?

Sinch Conversation API uses OAuth2.0 client credentials authentication. Send a POST request to the auth endpoint (region-specific: US/EU/BR) with your Access Key ID and Secret as Basic Auth credentials, specifying grant_type=client_credentials. The API returns an access token valid for 1 hour (3600 seconds). Cache this token and reuse it for multiple API calls until expiry to avoid unnecessary authentication requests. Never use self-generated JWT tokens – Sinch manages token generation.

Which Node.js version should I use with Next.js 15?

Use Node.js v20 (Maintenance LTS) or v22 (Active LTS until October 2025) for production deployments with Next.js 15. Avoid Node.js v18, which reaches End-of-Life on April 30, 2025. Next.js 15.4+ deprecated v18 support, and Next.js 15.5 (October 2025 release) requires Node.js 18.18+ minimum but recommends v20 or v22 for security updates and long-term support. [Source: Node.js Release Schedule, Next.js 15 Documentation]

How do I handle Sinch API rate limits for bulk messaging?

Sinch Conversation API enforces a 500,000 message ingress queue and 800 requests/second project-level limit. Messages drain from the queue at 20 messages/second by default (configurable based on throughput). Implement retry logic with exponential backoff for 429 (rate limit) and 503 (service unavailable) responses. Use Promise.all() with batch sizes of 50-100 messages per batch, adding delays between batches. Monitor your queue depth through Sinch dashboard analytics.

How do I configure Sinch regional endpoints correctly?

Match your base URL to the region where you created your Sinch app: https://us.conversation.api.sinch.com (United States), https://eu.conversation.api.sinch.com (Europe), or https://br.conversation.api.sinch.com (Brazil). Using the wrong region returns 404 errors. Configure both the Conversation API base URL and the OAuth2.0 auth URL (https://{region}.auth.sinch.com/oauth2/token) to match your app's region. Store the region prefix in environment variables for flexibility.

What security considerations exist for bulk SMS systems?

Implement multiple security layers: (1) Store Sinch credentials in environment variables, never in code, (2) Use axios v1.12.2+ to address CVE-2025-58754 DoS vulnerability, (3) Validate and sanitize recipient phone numbers to prevent injection attacks, (4) Rate limit your API endpoints to prevent abuse, (5) Implement authentication on your Next.js API routes, (6) Log all message sends for audit trails, (7) Use HTTPS for all API communications, and (8) Rotate access keys periodically according to your security policy.

How do I implement retry logic for failed Sinch messages?

Build a retry mechanism with exponential backoff: catch errors from axios, check the HTTP status code, and retry on transient failures (429 rate limits, 503 service unavailable, network timeouts). Implement 3-5 retry attempts with increasing delays (1s, 2s, 4s, 8s). For permanent failures (400 bad request, 401 unauthorized), log the error and don't retry. Store failed messages in a database or queue for manual review. Use the Sinch webhook system to receive delivery receipts and handle final delivery failures.

Can I use Sinch Conversation API for WhatsApp and other channels?

Yes. The Sinch Conversation API supports omnichannel messaging across SMS, WhatsApp, RCS, Viber, Facebook Messenger, and more. Use the same authentication and message structure, but specify the appropriate channel in channel_priority_order and configure channel-specific identities in recipient.identified_by.channel_identities. For WhatsApp, you need a WhatsApp Business Account and approved message templates for non-session messages. The API automatically falls back to secondary channels if the primary channel fails.

What is the cost of sending bulk SMS through Sinch API?

Sinch SMS pricing varies by destination country and message volume. Contact Sinch sales for enterprise pricing tiers and volume discounts. Typical costs range from $0.01-$0.10 per SMS segment depending on the destination. Monitor your usage through the Sinch dashboard to track costs. Each SMS segment supports 160 characters for standard GSM-7 encoding or 70 characters for Unicode. Longer messages split into multiple segments, each billed separately.

How do I monitor and debug Sinch bulk messaging in production?

Implement comprehensive logging: log OAuth2.0 token refreshes, individual message send attempts with recipient details, API response codes, and error messages. Use the Sinch dashboard to monitor message delivery status, queue depth, and throughput metrics. Configure webhooks to receive real-time delivery receipts (DELIVERED, FAILED, READ status updates). Set up alerting for repeated authentication failures, rate limit hits, or elevated error rates. Use structured logging (JSON format) for easier parsing and analysis in production monitoring tools.