{"id":2944,"date":"2026-09-04T11:11:22","date_gmt":"2026-09-04T05:41:22","guid":{"rendered":"https:\/\/www.smsgatewaycenter.com\/blog\/?p=2944"},"modified":"2026-09-04T11:11:24","modified_gmt":"2026-09-04T05:41:24","slug":"campaign-splitting-one-send-several-transactions","status":"publish","type":"post","link":"https:\/\/www.smsgatewaycenter.com\/blog\/campaign-splitting-one-send-several-transactions\/","title":{"rendered":"Campaign Splitting: What Happens When One Send Becomes Several Transactions"},"content":{"rendered":"\n

A split SMS campaign turns one send into several transactions, each with its own identifier. Here is what the campaign, transaction and message levels actually mean, which SMSGatewayCenter endpoint resolves each one, and how to aggregate and reconcile a campaign without double counting or reporting a false delivery rate.<\/p>\n\n\n\n

\"Diagram<\/a>
One campaign, several transactions, many messages. Splitting changes the shape of your identifiers, not just the timing of your sends.<\/figcaption><\/figure>\n\n\n\n

Table of Contents<\/h2>\n\n\n\n
    \n
  1. The Short Answer<\/a><\/li>\n\n\n\n
  2. TL;DR<\/a><\/li>\n\n\n\n
  3. What a Split Campaign Actually Is<\/a><\/li>\n\n\n\n
  4. The Three Levels of Identity<\/a><\/li>\n\n\n\n
  5. What the API Can and Cannot Do With a Split<\/a><\/li>\n\n\n\n
  6. Reading a Campaign<\/a><\/li>\n\n\n\n
  7. The Send Response Is a Union, Not a Shape<\/a><\/li>\n\n\n\n
  8. The Group Send Blind Spot<\/a><\/li>\n\n\n\n
  9. Updating and Deleting a Split Campaign<\/a><\/li>\n\n\n\n
  10. Three Spellings of One Concept<\/a><\/li>\n\n\n\n
  11. Aggregating a Split Campaign Correctly<\/a><\/li>\n\n\n\n
  12. Which Report Resolves Which Level<\/a><\/li>\n\n\n\n
  13. Schema Changes You Need<\/a><\/li>\n\n\n\n
  14. The Reconciliation Playbook<\/a><\/li>\n\n\n\n
  15. Billing and Cost Under a Split<\/a><\/li>\n\n\n\n
  16. Decision Matrix<\/a><\/li>\n\n\n\n
  17. Build Order<\/a><\/li>\n\n\n\n
  18. Ten Mistakes<\/a><\/li>\n\n\n\n
  19. Pre-Launch Checklist<\/a><\/li>\n\n\n\n
  20. What This Article Deliberately Does Not Claim<\/a><\/li>\n\n\n\n
  21. FAQs<\/a><\/li>\n<\/ol>\n\n\n\n

    The Short Answer<\/h2>\n\n\n\n

    When you enable split campaigns, one logical send stops being one transaction and becomes several, each with its own transaction identifier, each firing at a different time, and only the first of which your code ever observes synchronously. The identifier that ties them together is campaignid<\/code>, and it is the only key that addresses the campaign as a whole. If your database has one row per send and one status column keyed on the transaction identifier you received at submit time, that model is wrong the moment splitting is switched on, because the value you stored describes one batch out of several and the rest of the campaign will never call you back.<\/p>\n\n\n\n

    The practical consequence is not a crash. It is silence. Your integration keeps working, your first batch reports normally, and your delivery rate looks catastrophic for hours because the denominator you are dividing by is the campaign total while the numerator only covers the batches that have actually fired. Nothing errors. The numbers are just wrong, and they correct themselves later in a way that hides the bug.<\/p>\n\n\n\n

    TL;DR<\/h2>\n\n\n\n