Visma and Mailchimp integration

What moves between them

Customers flow from Visma.net into Mailchimp. When a new customer is created in Visma or an existing customer is modified (address, contact person, billing status), ml-connector polls Visma for changes, maps the customer record to Mailchimp member attributes (email, first name, last name, company, address fields), and upserts the member into the designated Mailchimp list. The sync runs on a recurring schedule (typically daily or per business cycle); it is pull-only from Visma and write-only to Mailchimp, with no reverse flow.

How ml-connector handles it

ml-connector stores the Visma OAuth credentials (client ID, secret, tenant ID, company ID) encrypted and the Mailchimp API key encrypted, then polls Visma's customer list on a schedule using lastModifiedDateTime to fetch only changed records since the last run. On each poll, it extracts the Visma customer fields (CustomerName, EmailAddress, BillingPostalAddress, BillingCity, BillingCountry, ContactPerson) and maps them to Mailchimp member properties (EMAIL, FNAME, LNAME, ADDRESS, CITY, COUNTRY). It extracts the data center prefix from the stored Mailchimp API key (the segment after the final hyphen) to route the call to the correct Mailchimp endpoint. Each record is upserted into the target Mailchimp list using the customer email as the match key; new members are added and existing members are updated. If the Visma OAuth token expires (refresh tokens are not issued to service apps, only new tokens on expiry), ml-connector obtains a fresh token on the next poll. All records are logged with timestamps and a full audit trail so any failed record can be replayed or investigated.

A real-world example

A Nordic mid-market B2B wholesaler uses Visma.net for order management and billing, and Mailchimp for monthly product newsletters and promotional campaigns. Before the integration, the marketing team manually exported the customer list from Visma each month, cleaned it in a spreadsheet, and re-uploaded it to Mailchimp, a process that typically took a day and risked duplicate sends to new customers who had not yet appeared in the previous month's export. With Visma and Mailchimp connected, each new customer is automatically added to the correct Mailchimp audience within hours, customer address changes flow into Mailchimp for updated billing segments, and terminated customers can be tagged or suppressed. The marketing team no longer owns the customer list maintenance; they focus on campaign content and audience segmentation.

What you can do

• •Sync Visma customer records into Mailchimp lists, mapping customer email, name, and address fields to member attributes.
• •Automatically add new Visma customers to Mailchimp audiences and update existing members when customer data changes.
• •Extract and route to the correct Mailchimp data center using the API key's embedded data center prefix.
• •Poll Visma.net for customer changes on a schedule, using lastModifiedDateTime to fetch only modified records since the last sync.
• •Track every customer sync with full audit trail and timestamps so failed records can be investigated and replayed.

Questions

Which direction does data flow between Visma and Mailchimp?

Customer records flow one direction only, from Visma into Mailchimp. ml-connector reads Visma customers and upserts them into the target Mailchimp list. Mailchimp list member changes (subscribes, unsubscribes, profile edits) remain in Mailchimp and are not written back to Visma.

How does ml-connector handle Visma OAuth token refresh?

Visma does not issue refresh tokens to service applications; instead, ml-connector obtains a new access token on the next poll after the current token expires. ml-connector stores the client credentials (ID, secret, tenant ID, company ID) encrypted and re-authenticates silently when needed, so there is no manual token renewal step.

Why does the integration poll Visma instead of using webhooks?

Visma webhooks are delivered once with no automatic retry, and webhook events must be explicitly enabled per entity in company settings. Polling via lastModifiedDateTime is more reliable and does not depend on company-level configuration changes, making it a better fit for production integrations.