WooCommerce Multisite: separate ERP credentials per site (Exact / AFAS)

WooCommerce Multisite is a sharp tool for multi-brand or multi-country storefronts on one WordPress network. It becomes a liability the moment someone stores a single Exact Online or AFAS token at the network level and assumes every shop can share it. Finance does not share administrations. Neither should your integration. This post is about WooCommerce Multisite separate ERP credentials: per-site secrets, per-site mapping, shared engineering — without leaking Customer A’s orders into Administration B.

HostHob designs that isolation for EU merchants. Broader ERP context: WordPress Exact & AFAS ERP integration · NL: WooCommerce Exact Online of AFAS koppeling · B2B pricing: WooCommerce B2B custom pricing & ERP sync.

Why network-wide credentials fail

• Wrong administration — Site NL writes into the BE Exact division because the token was “the company’s.”
• Permission blast radius — A compromised child theme on a low-traffic brand can reuse a network token with rights over every entity.
• Rate limits — One noisy site burns the shared API budget; quieter brands start failing checkouts or nightly syncs.
• Audit fiction — Controllers cannot see which storefront produced which ERP document when logs omit blog_id.
• Plugin assumption — Many Exact/AFAS plugins were written for single-site WooCommerce and store options without multisite awareness.

Multisite is not the enemy. Unscoped secrets are.

Reference architecture

1. Credential store per site — site options or a secrets vault indexed by blog_id; never a single wp-config constant for all shops unless it only points to the vault.
2. Connection profile — administration ID, environment (sandbox/prod), token expiry, last rotation.
3. Mapping profile — tax classes, shipping methods, payment codes, warehouse IDs per site.
4. Queue partition — jobs carry blog_id; workers switch_to_blog before reading orders; no cross-site batching by accident.
5. Observability — dashboards filter by site; alerts name the brand, not only “WooCommerce.”

For heavier networks we place Laravel (or another worker) beside WordPress as the ERP client — WordPress emits domain events; the worker holds tokens outside the web root. That mirrors the spine in our Laravel API partner portal and platform work in WordPress platform rebuild.

Exact Online vs AFAS vs Globe on Multisite

Exact Online: separate apps or divisions per legal entity; store refresh tokens per site; never reuse a webhook signing secret across brands without intent. AFAS Profit: different environments or connector identities per administration; Get/Update connectors may differ per entity even when “the ERP looks the same.” Exact Globe: often on-prem reachability differs per business unit — credentials plus network path must both be scoped. If Globe is in play, read our NL Globe note on Exact/AFAS koppeling context and treat Multisite as multiple integration contracts, not one.

Catalogue and customer sync pitfalls

Shared product catalogues across sites are tempting. ERP reality often disagrees: SKUs collide, VAT differs, and price books are entity-specific. We decide explicitly:

• Network catalogue with per-site price overlays from each ERP, or
• Separate catalogues per site with sync jobs that never assume global SKU uniqueness, or
• Hybrid: shared content, separate sellable SKUs.

Customer accounts raise GDPR questions: a user registered on Brand A must not silently receive Brand B’s order history because user tables are shared. Entitlements and ERP debiteur numbers belong in site-scoped meta.

Operational checklist for credentials

1. Inventory: each site → legal entity → ERP administration → token owner.
2. Rotation drill: revoke one site’s token; confirm others keep syncing.
3. Least privilege: order write without unnecessary HR or financial export scopes.
4. Sandbox matrix: every production administration has a test counterpart or a documented dry-run mode.
5. Incident runbook: disable sync for one site without network-wide maintenance mode.

Delivery shape with HostHob

Discovery maps brands to administrations and finds any plugin already storing network options. Build introduces per-site settings UI (or vault), migrates secrets, partitions queues, and adds smoke tests that intentionally use the wrong administration in staging to prove rejection. Cutover rotates tokens and turns off legacy network credentials. You own the repo and the secret store; we document how to onboard site N+1 without forking the integration.

Related reading: B2B pricing ERP sync · Exact & AFAS integration · API integration agency Europe.

Plugin and HPOS realities

High-Performance Order Storage changes where order data lives; Multisite multiplies that by blog_id. Integration code that assumes post meta on the root site will silently miss child-site orders. We test HPOS on/off matrices per site when clients are mid-migration. Checkout plugins that write custom order meta must be inventory’d so ERP mapping does not drop B2B fields that only exist on one brand.

Many Exact and AFAS plugins store a single options row. On Multisite that row may be network-activated by accident. Part of discovery is reading the plugin’s option keys and confirming whether it calls get_option versus get_site_option. If the plugin cannot be site-scoped, we replace its sync path with our worker while leaving the storefront plugins alone.

Webhooks and inbound ERP events

Outbound order sync is only half the story. Stock updates, invoice PDFs, or delivery dates inbound must route to the correct site. We stamp ERP documents with an external reference that encodes blog_id or brand code, then reject payloads that cannot be routed. Shared webhook endpoints without routing metadata are how Brand A’s stock overwrite hits Brand B’s SKU collision.

Security model for agencies and freelancers

Multisite networks often have freelancers with access to one theme. Network admins see everything. Credentials must not live in theme files committed to a repo multiple freelancers pull. We push secrets to environment stores or encrypted options with capability checks limited to a small ops role. Rotation must be possible without deploying PHP. When a freelancer offboards, you revoke site deploy keys and ERP tokens for the brands they touched — documented in the runbook, not tribal knowledge.

Migration from a single shared token

Common rescue pattern: production already posts all sites through one Exact app. We inventory open documents, stand up per-site apps in sandbox, dual-run logging (write still shared, but we assert what the correct administration would have been), then cut over site by site during low-traffic windows. Finance signs off on a reconciliation sample before the old token is revoked. Rushing this cutover is how you get duplicate invoices.

Testing strategy that finance trusts

Staging Multisite clones often share one ERP sandbox by accident — which teaches the wrong lesson. We prefer a matrix: Site A sandbox token → Administration A test, Site B → Administration B test, plus a negative test where Site A credentials are pointed at Administration B and must fail closed. Order fixtures include brand-specific tax and SKU cases. Reconciliation exports compare WooCommerce totals to ERP document totals per site for a sample day. If finance cannot read the diff report, the integration is not done.

Load tests matter when nightly catalogue syncs overlap across brands. Partitioned queues with per-site concurrency caps prevent one brand’s full reindex from starving another brand’s order push during peak.

Onboarding brand N+1

A healthy Multisite ERP design makes a new brand a configuration exercise: create credentials, map tax and shipping, seed catalogue rules, enable queue consumers, run UAT checklist. If adding a brand requires forking plugin code, the original abstraction failed. Our handover includes that checklist so your team (or we under a care plan) can repeat it without rediscovering credential scope the hard way.

Document the brand code early — a short stable string used in ERP references, logs, and webhook routing. Renaming marketing brands is fine; renaming the integration brand code after go-live is how orphaned documents appear in Exact or AFAS with no matching storefront. Keep that code in the runbook next to the token owner name.

When not to hire us

If you run one site, one administration, and a healthy connector, stay there. If Multisite was chosen only for cheap page cloning and you can split into separate installs cheaply, consider splitting — credentials isolation becomes natural. Hire us when multiple live storefronts share a network and ERP writes must remain entity-correct under real order volume — or when a previous partner hard-coded one token and finance already found a mis-posted order. Also hire us when B2B price books differ per brand and must stay aligned with ERP without copy-paste — see B2B custom pricing & ERP sync.

Related reading: Exact & AFAS integration · NL Exact/AFAS koppeling · API integration agency Europe · proof styles in platform rebuild and Laravel API portal.

Related: Exact & AFAS ERP · Exact / AFAS koppeling · B2B pricing sync · Platform rebuild case · API agency Europe