Wave Accounting and Twilio integration

What moves between them

Wave accounting events flow into ml-connector and trigger outbound Twilio communications. When an invoice is marked paid in Wave, ml-connector reads the customer phone number and invoice amount, then sends a confirmation SMS via Twilio to the customer. When an invoice reaches its due date in Wave, ml-connector sends a reminder SMS to the customer and an alert voice call to the accounting team's phone number. Payment received events from Wave trigger customer thank-you messages via Twilio. New customers created in Wave can trigger a welcome SMS. The direction is Wave into Twilio only; Twilio does not write back to Wave.

How ml-connector handles it

ml-connector maintains OAuth 2.0 credentials for Wave and HTTP Basic Auth credentials for Twilio, both encrypted at rest. It subscribes to Wave webhooks and validates each webhook signature using HMAC-SHA256 before processing the event. When an invoice or payment event arrives from Wave, ml-connector looks up the customer phone number in Wave's customer records (via GraphQL query), constructs the message body using Wave invoice and customer data, and sends it to Twilio via the SMS or voice API. For voice calls, ml-connector uses Twilio's call initiation endpoint to ring the accounting team. Twilio's 429 rate limit responses trigger exponential backoff and retry, and every sent message is logged with its Wave source event and Twilio message SID for audit and replay. Wave's 2-hour access token is refreshed before expiry using the offline_access scope. Phone number validation uses Twilio's Lookups API to confirm a customer number is dialable before attempting to send an SMS or initiate a call, reducing failed messages and downstream errors.

A real-world example

A small business providing professional services invoices customers through Wave Accounting and wants to improve payment collection and cash flow visibility. Before the integration, the accounting team manually checked Wave for new invoices each day and sent reminder emails to customers, and customers had no automated notification when an invoice was marked paid. With Wave and Twilio connected, each new invoice automatically sends an SMS to the customer on creation, each overdue invoice triggers a reminder call to the accounting team, and each payment received sends a thank-you text to the customer. The accounting team no longer spends time on manual notifications, customers see immediate SMS confirmations after paying, and the manual email step is eliminated.

What you can do

• •Send SMS and voice notifications to customers when invoices are created, marked paid, or become overdue in Wave Accounting.
• •Authenticate Wave with OAuth 2.0 and Twilio with HTTP Basic Auth, managing token refresh and credential encryption.
• •Validate Wave webhook signatures using HMAC-SHA256 and Twilio webhook signatures using HMAC-SHA1.
• •Look up customer phone numbers in Wave and verify dialability with Twilio's Lookups API before sending messages.
• •Log all sent messages with their Wave source event and Twilio message SID for audit trail and message replay on failure.

Questions

Which direction does data move between Wave Accounting and Twilio?

Data flows from Wave Accounting into Twilio only. Wave accounting events (invoice created, invoice paid, payment received) trigger outbound SMS and voice notifications to customers and team members via Twilio. Twilio does not write back into Wave; it sends messages only.

How does ml-connector handle Wave's OAuth 2.0 tokens and Twilio's HTTP Basic Auth?

ml-connector stores both credential sets encrypted and maintains them separately. Wave access tokens expire in 2 hours and are refreshed using the refresh token with offline_access scope before expiry. Twilio credentials (Account SID and Auth Token or API Key) are presented on every request as HTTP Basic Auth. Both credential types are validated at startup and rotated when the user provides new credentials.

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

Before sending any message, ml-connector validates the phone number using Twilio's Lookups API to confirm it is dialable. If validation fails, the message is logged as undeliverable and not sent. If Twilio returns a 429 rate limit or 5xx error, ml-connector backs off and retries up to 3 times with exponential jitter, and logs the final state in the audit trail so the user can replay or investigate.