Microsoft Dynamics NAV and Twilio integration

What moves between them

The main flow is from Dynamics NAV into Twilio. When a purchase invoice is posted, a sales order is created, or a payment is due, ml-connector reads the event from NAV, extracts the vendor or customer phone number, looks up the corresponding Twilio phone number, and sends an SMS alert to that number. Customer reminders, AP notifications, and shipment alerts all follow the same pattern: NAV event triggers, Twilio sends the message, and the status callback returns delivery confirmation. The reverse flow is minimal: Twilio webhook notifications for incoming SMS or inbound calls are logged into NAV if needed, but NAV does not send data back to Twilio beyond the initial alert request.

How ml-connector handles it

ml-connector uses OAuth 2.0 to authenticate against Dynamics NAV, refreshing the bearer token as needed, and accepts either the cloud Business Central online base URL or an on-premises NAV instance URL. On the Twilio side it authenticates with HTTP Basic Auth, using the Account SID and Auth Token stored encrypted. ml-connector maps customer and vendor phone numbers from NAV to Twilio phone numbers, so that when an invoice posts for a vendor with a stored phone number, the alert goes to the correct Twilio account phone. Because NAV webhooks expire after 3 days, ml-connector renews webhook subscriptions before expiry, or it can fall back to polling on a schedule. Twilio webhook callbacks are validated with HMAC-SHA1 using the Auth Token, and incoming message and call webhooks are logged into NAV audit tables for compliance. If a Twilio send fails due to an invalid phone number, a network error, or a rate limit, ml-connector retries with exponential backoff and logs the failure to NAV so the AP or AR team can investigate.

A real-world example

A mid-sized wholesale distributor uses Dynamics NAV for procurement, invoicing, and GL. The AP team receives dozens of new vendor invoices daily and spends time manually cross-referencing invoice numbers and due dates. With Twilio connected, each time a purchase invoice posts in NAV, an SMS automatically goes to the vendor's stored phone number confirming receipt, and a parallel alert goes to the AP supervisor with invoice total and due date. When a customer payment is overdue, an SMS is sent to the customer contact number on file. Errors like an invalid phone number or a Twilio rate limit are captured in NAV so the AR team can fix contact records before the next cycle. Manual invoice tracking is cut by 80 percent.

What you can do

• •Send SMS alerts to vendors when purchase invoices post in Dynamics NAV, with invoice number and due date.
• •Alert customers when sales orders ship, payments are due, or invoices are ready, with optional customized message content.
• •Map Dynamics NAV customer and vendor phone numbers to Twilio phone numbers, ensuring alerts reach the correct recipient.
• •Validate Twilio webhook signatures with HMAC-SHA1 and log all incoming messages and calls into NAV audit tables for compliance.
• •Renew Dynamics NAV webhook subscriptions before 3-day expiry and fall back to polling if webhooks are unavailable.

Questions

What events in Dynamics NAV trigger Twilio alerts?

When a purchase invoice or sales invoice is posted, a sales order is created, or a payment is due, ml-connector reads the event and sends an SMS to the customer or vendor phone number on file. You can configure which events trigger alerts and customize the message text per event type.

How does ml-connector handle Dynamics NAV's 3-day webhook expiry?

ml-connector renews NAV webhook subscriptions before the 3-day window closes, so alerts continue to flow without interruption. If a renewal fails, ml-connector falls back to polling NAV at a configurable interval so no events are missed.

What happens if a Twilio send fails or a phone number is invalid?

ml-connector logs the failure to NAV with the reason (invalid number, rate limit, network error) so the AP or AR team can review and correct customer or vendor phone records. Failed sends are retried with exponential backoff, and all attempts are audited for compliance.