What kind of notifications can ml-connector send from Sage 300 to Twilio?

ml-connector polls Sage 300 invoice batches and sends SMS to suppliers confirming invoice receipt, SMS to customers confirming invoices and payment terms, and voice calls to internal teams flagging GL reconciliation issues. Any transaction pulled from Sage 300 can trigger a notification; the mapping from transaction type to message template and recipient phone number is configurable.

Does Sage 300's lack of webhooks limit real-time sync with Twilio?

Yes. Because Sage 300 has no webhooks, ml-connector polls on a schedule you define, so notifications are not instantaneous but delayed by the poll interval. For example, a poll every 15 minutes means supplier notifications arrive 0 to 15 minutes after the invoice is created. If you need near-real-time alerts, a shorter poll cycle can be set, but it increases Sage 300 API load.

How does ml-connector handle Sage 300's uppercase credential requirement and Twilio's different auth format?

ml-connector stores both credential sets encrypted. When calling Sage 300, it converts the username and password to uppercase before encoding them into the Basic Auth header. For Twilio, it uses the Account SID and Auth Token directly in the Basic Auth header without case conversion, since Twilio accepts credentials as-is. Both conversions happen transparently before each request.

Sage 300Twilio

Sage 300 and Twilio integration

Sage 300 runs accounts payable, accounts receivable, general ledger, and inventory for mid-market businesses, but it does not notify external parties about transactions. Twilio provides SMS, voice, and email notifications at scale. Connecting them lets you send supplier invoices and payment reminders, customer payment confirmations, and reconciliation alerts without manual outreach. ml-connector handles the credential differences and bridges the sync.

How Sage 300 works

Sage 300 is a self-hosted on-premise ERP running on Windows IIS with a SQL Server backend. It exposes AP invoices, AR invoices, GL journals, PO receipts, and inventory transactions through REST APIs with OData filters for date/time range queries and pagination. Authentication uses HTTP Basic Auth with uppercase credentials sent on every request. There are no webhooks, so all data retrieval is pull-based polling. The API user must be created in Administrative Services with Web API security privileges; the built-in Admin user does not have API access. IIS must be configured with Anonymous Authentication enabled and Windows Authentication disabled.

How Twilio works

Twilio is a cloud communications platform that sends SMS, MMS, voice calls, and email through REST APIs authenticated with Account SID and Auth Token or API Key credentials. It supports real-time status callbacks via webhooks for message delivery, call completion, and verification events, using HMAC-SHA1 signature validation. Request bodies use form-encoded format, not JSON. Webhook timeout is unspecified but expects a 200 OK response. Webhook delivery is at-least-once, not exactly-once, so handlers must be idempotent. Twilio is a communications system, not an ERP, so it has no finance objects like invoices, GL accounts, or purchase orders.

What moves between them

ml-connector polls Sage 300 for newly created AP invoices, AR invoices, and GL journal batches on a cadence you define. For each new transaction, it extracts key details such as vendor name, invoice amount, AR customer contact, and GL account, then sends SMS or voice notifications through Twilio to the relevant contacts. The flow is read-only on Sage 300; ml-connector does not write transactions back into the ERP. Status callbacks from Twilio are received via webhook to track message delivery and call completion, providing an audit trail of which notifications were sent and confirmed.

How ml-connector handles it

ml-connector stores Sage 300 credentials encrypted and converts them to uppercase before each request, since Sage 300 requires uppercase usernames and passwords. It polls Sage 300's APInvoiceBatches, ARInvoiceBatches, and GLJournalBatches endpoints using OData $filter to query transactions by DocumentDate, ordering by creation date and paginating through large result sets. For each transaction, ml-connector looks up the vendor or customer phone number from Sage 300 master data or your own contact database, formats the transaction summary, and sends it via Twilio SMS or voice call. Twilio webhooks return message and call status, which ml-connector logs to an audit table. If a Twilio request fails due to rate limits or network timeouts, ml-connector retries with exponential backoff. Sage 300's IIS AppPool can timeout with large polling volumes, so ml-connector implements request batching and delays to stay within typical IIS thresholds.

A real-world example

A mid-sized wholesale distributor runs Sage 300 for AP, AR, and inventory across three regional warehouses. Every day they process dozens of AP invoices from suppliers and AR invoices to customers, but there is no automated way to notify suppliers of receipt, customers of invoicing, or internal teams when GL reconciliation requires attention. The finance team sends manual emails and calls, which delays notification and sometimes gets missed. With Sage 300 and Twilio connected, each new AP invoice triggers an SMS to the supplier confirming receipt and expected payment date, AR invoices send SMS reminders to customers, and GL reconciliation alerts trigger voice calls to the accounting team. Notifications reach contacts in minutes instead of hours, and the manual outreach step is eliminated.

What you can do

Poll Sage 300 AP and AR invoice batches on a schedule and send SMS notifications to suppliers and customers with key transaction details.
Trigger voice calls through Twilio to notify internal teams when GL reconciliation batches exceed variance thresholds.
Map Sage 300 vendor and customer records to phone numbers and send personalized transaction confirmations without manual lookup.
Encrypt Sage 300 credentials, convert usernames to uppercase as required, and handle IIS configuration constraints.
Track Twilio message and call status via webhooks to build an audit trail of every notification sent and its delivery outcome.

Questions

What kind of notifications can ml-connector send from Sage 300 to Twilio?: ml-connector polls Sage 300 invoice batches and sends SMS to suppliers confirming invoice receipt, SMS to customers confirming invoices and payment terms, and voice calls to internal teams flagging GL reconciliation issues. Any transaction pulled from Sage 300 can trigger a notification; the mapping from transaction type to message template and recipient phone number is configurable.
Does Sage 300's lack of webhooks limit real-time sync with Twilio?: Yes. Because Sage 300 has no webhooks, ml-connector polls on a schedule you define, so notifications are not instantaneous but delayed by the poll interval. For example, a poll every 15 minutes means supplier notifications arrive 0 to 15 minutes after the invoice is created. If you need near-real-time alerts, a shorter poll cycle can be set, but it increases Sage 300 API load.
How does ml-connector handle Sage 300's uppercase credential requirement and Twilio's different auth format?: ml-connector stores both credential sets encrypted. When calling Sage 300, it converts the username and password to uppercase before encoding them into the Basic Auth header. For Twilio, it uses the Account SID and Auth Token directly in the Basic Auth header without case conversion, since Twilio accepts credentials as-is. Both conversions happen transparently before each request.

Connect Sage 300 and Twilio

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started