Which direction does data move between QAD and Slack?

The main flow is QAD into Slack. Supplier invoices, purchase orders, and goods receipts that need attention are posted into Slack channels, and the approve or reject responses flow back through the Slack Events API to update the matching QAD record. Slack holds no financial data, so ml-connector never reads ledger records from Slack.

How does ml-connector verify that events really come from Slack?

Slack signs every event request with a header that is an HMAC-SHA256 of the request timestamp and the raw body, keyed with the app signing secret. ml-connector recomputes that digest and compares it in constant time, and it rejects any request whose timestamp is more than five minutes old. The endpoint also acknowledges within Slack's three-second window and processes the event on a queue, using the event_id to drop retried deliveries.

Does QAD push events to Slack, 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.

QADSlack

QAD and Slack integration

QAD runs manufacturing, procurement, and finance. Slack runs team communication. Connecting the two moves QAD events that need a human decision into the channels where your team already works. New supplier invoices waiting on a three-way match, purchase orders pending approval, and goods receipts post into Slack as messages, and the approve or reject responses flow back to update 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 Slack works

Slack exposes users, conversations, messages, and files through the Slack Web API, a REST surface where every method is a dot-namespaced action such as chat.postMessage and conversations.list against the single base URL https://slack.com/api. Calls authenticate with a bot token using a Bearer header, and the token does not expire but is revoked if the app is uninstalled. Slack is a communication platform, not a finance system, so it has no native invoices, purchase orders, or GL accounts. Its Events API pushes workspace activity, such as messages and reactions, to a verified HTTPS endpoint, and each event is signed with the app signing secret.

What moves between them

The main flow runs from QAD into Slack. ml-connector reads QAD supplier invoices, purchase orders, and goods receipts on a schedule and posts each one into the right Slack channel as a message, using interactive blocks so an approver can respond. Decisions flow the other direction through the Slack Events API: when a user approves or rejects, ml-connector captures the event and updates the matching QAD record or advances it through the next step. User reference data is read from Slack so the people acting in a channel can be tied to QAD approvers. Slack holds no financial records, so ml-connector never reads ledger data from Slack.

How ml-connector handles it

ml-connector stores both credential sets encrypted and sends the Slack bot token as a Bearer header on every Web API 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. Inbound Slack events are verified with the signing secret by computing an HMAC-SHA256 over the timestamp and raw body and comparing in constant time, and the timestamp is rejected if it is more than five minutes old. The endpoint acknowledges each event within the three-second window and processes it on a queue, using the Slack event_id to deduplicate retried deliveries. Slack messages are sent with a plain text fallback alongside the block layout, and posting respects the one message per second per channel limit. Slack users are mapped to QAD approvers, so a reply updates the correct record. 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, the AP team emailed buyers and plant managers whenever a supplier invoice was stuck waiting on a purchase order match or a missing receipt, then waited on scattered email threads for sign-off while invoices aged past their due dates. With QAD and Slack connected, each invoice that needs a decision posts into a dedicated approvals channel with the supplier, amount, and match status, and the buyer approves or asks a question right there. The response updates the QAD record, invoices clear faster, and the email back-and-forth is gone.

What you can do

Post QAD supplier invoices, purchase orders, and goods receipts into Slack channels as interactive messages.
Capture approve and reject responses from Slack Events and update the matching QAD record.
Verify every inbound Slack event with the signing secret using a constant-time HMAC-SHA256 compare.
Authenticate Slack with its bot token 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 Slack?: The main flow is QAD into Slack. Supplier invoices, purchase orders, and goods receipts that need attention are posted into Slack channels, and the approve or reject responses flow back through the Slack Events API to update the matching QAD record. Slack holds no financial data, so ml-connector never reads ledger records from Slack.
How does ml-connector verify that events really come from Slack?: Slack signs every event request with a header that is an HMAC-SHA256 of the request timestamp and the raw body, keyed with the app signing secret. ml-connector recomputes that digest and compares it in constant time, and it rejects any request whose timestamp is more than five minutes old. The endpoint also acknowledges within Slack's three-second window and processes the event on a queue, using the event_id to drop retried deliveries.
Does QAD push events to Slack, 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 Slack

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

Get started