Which direction does data move between QAD and Twilio?

The main flow is QAD into Twilio. Supplier invoices, purchase orders, and goods receipts that need attention are sent as SMS or voice alerts, and the delivery status callbacks and any inbound replies flow back through Twilio webhooks to update the matching QAD record. Twilio holds no financial data, so ml-connector never reads ledger records from Twilio.

How does ml-connector verify that webhooks really come from Twilio?

Twilio signs every webhook with an X-Twilio-Signature header that is an HMAC-SHA1 of the full request URL plus the sorted POST parameters, keyed with the account Auth Token. ml-connector recomputes that signature and rejects any request that does not match. Because Twilio does not guarantee exactly-once delivery, each callback is processed on a queue and deduplicated by the message or call SID.

Does QAD push events to Twilio, or does ml-connector poll?

QAD cloud has no webhook system for connectors, so ml-connector polls QAD invoices, purchase orders, and receipts on the schedule you set rather than relying on a push. It accepts the full QAD instance URL per customer because QAD publishes no shared base address. The three-way match also means a goods receipt must post in QAD before an invoice can clear, which the polling order respects.

QADTwilio

QAD and Twilio integration

QAD runs manufacturing, procurement, and finance. Twilio runs programmable messaging and voice. Connecting the two turns QAD events that need a person into a text message or phone call sent through Twilio. Supplier invoices waiting on a three-way match, purchase orders pending approval, and goods receipts trigger an SMS or voice alert, and the delivery status and any reply are recorded against the matching QAD record. ml-connector handles the very different APIs on each side and polls QAD on a schedule you control.

How QAD works

QAD Adaptive ERP exposes suppliers, purchase orders, supplier invoices, GL accounts, cost centers, items, and goods receipts through REST business document APIs, documented in Swagger inside each customer instance. The cloud product authenticates with a JWT session or OAuth2 bearer token against a tenant-specific URL, so there is no shared hostname. Older on-premise sites run QAD Enterprise Edition with the QXtend SOAP framework instead. QAD has no public webhook system for cloud connectors, so finance records are read by polling.

How Twilio works

Twilio exposes messages, calls, phone numbers, messaging services, and verification flows through its REST APIs, with resource paths such as Accounts/{Sid}/Messages under base URLs like https://api.twilio.com/2010-04-01. Every call uses HTTP Basic auth, and Twilio recommends an API Key SID and secret over the raw Account SID and Auth Token for production. Request bodies are form-encoded, not JSON, and all phone numbers must be in E.164 format. Twilio is a communications platform, not a finance system, so it has no invoices, purchase orders, or GL accounts. It pushes message and call status events to an HTTPS endpoint, and each webhook carries an X-Twilio-Signature header signed with the account Auth Token.

What moves between them

The main flow runs from QAD into Twilio. ml-connector reads QAD supplier invoices, purchase orders, and goods receipts on a schedule and sends each one that needs attention as a Twilio SMS or, for higher-stakes items, a voice call to the responsible person. Delivery and response data flows the other direction through Twilio webhooks: message and call status callbacks and inbound SMS replies are captured and tied back to the originating QAD record. Supplier and contact phone numbers are read from QAD to address the messages. Twilio holds no financial records, so ml-connector never reads ledger data from Twilio.

How ml-connector handles it

ml-connector stores both credential sets encrypted and sends the Twilio API Key SID and secret as HTTP Basic auth on every REST call, while accepting the full QAD tenant URL per customer since QAD publishes no shared base address. Because QAD cloud is pull-only, it polls QAD invoices, purchase orders, and receipts on the schedule you set rather than waiting for a push, and the three-way match means a receipt must post in QAD before an invoice can clear. Outbound requests are sent as application/x-www-form-urlencoded rather than JSON, and every destination number is normalized to E.164 before sending. Inbound Twilio webhooks are validated by recomputing the X-Twilio-Signature, an HMAC-SHA1 over the request URL and sorted POST parameters keyed with the Auth Token, and any request that fails the check is rejected. Because Twilio does not guarantee exactly-once delivery, each callback is processed on a queue and deduplicated by message or call SID, and a BullMQ jobId on the send side prevents duplicate alerts for the same QAD record. Concurrency limits return HTTP 429, so ml-connector backs off with jitter and retries. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized contract manufacturer runs QAD Adaptive ERP for procurement and accounts payable across a single plant with around three hundred staff. Before the integration, when a supplier invoice was stuck on a missing receipt or a buyer needed to approve a rush purchase order, the AP team left voicemails and sent emails that often went unread until the invoice had already aged past its due date. With QAD and Twilio connected, each invoice or purchase order that needs a decision sends an SMS to the right buyer or plant manager with the supplier, amount, and what is blocking it, and a reply or a follow-up call confirms the action. Twilio reports the delivery status back to the QAD record, urgent items get seen the same day, and the chase by email and voicemail is gone.

What you can do

Send Twilio SMS or voice alerts when QAD supplier invoices, purchase orders, and goods receipts need attention.
Record Twilio delivery status callbacks and inbound replies against the matching QAD record.
Validate every inbound Twilio webhook by recomputing the X-Twilio-Signature with the account Auth Token.
Authenticate Twilio with an API Key over HTTP Basic auth and QAD with its tenant-specific session, both stored encrypted.
Poll QAD on a schedule you control, with retries and a full audit trail on every record.

Questions

Which direction does data move between QAD and Twilio?: The main flow is QAD into Twilio. Supplier invoices, purchase orders, and goods receipts that need attention are sent as SMS or voice alerts, and the delivery status callbacks and any inbound replies flow back through Twilio webhooks to update the matching QAD record. Twilio holds no financial data, so ml-connector never reads ledger records from Twilio.
How does ml-connector verify that webhooks really come from Twilio?: Twilio signs every webhook with an X-Twilio-Signature header that is an HMAC-SHA1 of the full request URL plus the sorted POST parameters, keyed with the account Auth Token. ml-connector recomputes that signature and rejects any request that does not match. Because Twilio does not guarantee exactly-once delivery, each callback is processed on a queue and deduplicated by the message or call SID.
Does QAD push events to Twilio, or does ml-connector poll?: QAD cloud has no webhook system for connectors, so ml-connector polls QAD invoices, purchase orders, and receipts on the schedule you set rather than relying on a push. It accepts the full QAD instance URL per customer because QAD publishes no shared base address. The three-way match also means a goods receipt must post in QAD before an invoice can clear, which the polling order respects.

Connect QAD and Twilio

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

Get started