Integration lifecycle
- Define the business event and minimum data required.
- Create least-privilege credentials for WBAMS.
- Store secrets in protected settings, never CMS code.
- Test success, denial, expiry, replay, delay, and provider outage.
- Log identifiers and outcomes without logging secrets or sensitive payloads.
- Assign an owner and a rotation/revocation process.
OAuth and sign-in
Register exact redirect URIs, use HTTPS, verify state and nonce, request minimal scopes, and provide a local recovery sign-in path. Test both new-user and linked-account behavior.
Sign-In Integrations
Configure a supported provider under Control area → Sign-In Integrations. Enter its client identifier and secret, choose Save & Activate, and wait for WBAMS to validate the provider before considering the integration available. Provider secrets remain protected settings and must not be copied into CMS pages, screenshots, browser logs, or support messages.
WBAMS 1.1.1 corrects the activate and deactivate controls so their requests carry the required CSRF token. A successful change must update the visible status and remain active or inactive after a full-page reload. A provider rejection should produce a visible validation response; it must not silently fail, expose the secret, or remove the administrator's local recovery sign-in route.
Use disposable provider credentials on staging. Activate, reload, exercise the provider redirect and callback, deactivate, and reload again. Also test an intentionally invalid client value, an expired secret, a denied callback, and a provider outage while confirming that control-area and private logs contain no credential values.
Modules and extensions
Review vendor, version, permissions, callbacks, database changes, scheduled work, and documentation URL before enabling an extension. Stage updates and preserve extension-specific configuration in backups.
Extension manifests and control-area help actions should use https://docs.wbams.com/…. HTTP documentation links should be upgraded to HTTPS.
Mailchimp
The Mailchimp addon keeps your Mailchimp audience in step with WBAMS and turns on Mailchimp’s e-commerce features, so its automations can act on what a customer actually bought. Enable it under Extensions → Addons, then open it from the same page.
- Paste an API integration key. In Mailchimp, go to Account → Extras → API keys and create a key for WBAMS rather than reusing an existing one — a key made for this purpose can be revoked later without breaking anything else. Paste it into API Integration Key and choose Validate API Key. The key ends in a datacenter suffix such as
-us01; paste it whole. - Choose the audience. Pick an existing list under Primary Subscription List, or choose Create new list and give it a name, a default from address and a default from name. A new list is the cleaner choice: the e-commerce connection is configured against whichever list you pick, and pointing it at a list already used for something else mixes two sets of subscribers.
- Let the e-commerce connection finish. The addon establishes it on save. When it reports E-commerce Connection Complete, every future signup and transaction is synchronized as it happens.
Customers who already existed when you connected the addon are not sent to Mailchimp. Bring them over once, by hand, as below.
Importing your existing customers
- Open Tools → Mass Data Export and export the client list as CSV.
- In Mailchimp, open the audience the addon is connected to and choose Add contacts → Import contacts → Upload a file.
- Map the email column to Email Address and the name columns to First Name and Last Name. Leave the rest unmapped unless you have merge fields waiting for them.
- Import them as Subscribed only where you hold consent to email them. Where you do not, import as Unsubscribed or leave them out; WBAMS records marketing consent per client on the client’s profile, and Marketing consent explains where.
Do this once. After the import, the addon keeps the audience current on its own.