Protected customer attributes
SoftwareSilo modules can declare business-related customer and customer-address attributes as server-managed. The shared Extension Manager package (version 1.0.3 and later) then blocks customer- and guest-initiated API writes to those attributes, while admin and integration tokens keep Magento's normal behavior.
What is blocked
The protection hooks Magento's native API input handling and covers the standard customer paths:
| API | Covered calls |
|---|---|
| REST | Account creation, customer repository saves, customer address repository saves |
| SOAP | The same account, customer and address service calls |
| GraphQL | Customer and address create/update mutations |
| Async and bulk REST | Customer- and guest-triggered queued updates |
Setting, changing or clearing a protected attribute with a customer or guest token is rejected with Magento's input-validation error before any data is saved. Resubmitting an unchanged value during an update stays allowed, so read-then-write round trips keep working.
For asynchronous and bulk REST requests made with customer-level tokens the rules are stricter: protected attributes must be left out of the payload entirely, including nested customer-address attributes, or Magento rejects the request before it is queued.
Native storefront and admin forms are not intercepted — each attribute-owning module controls which fields its forms expose. Internal repository and account-management writes from module code also stay writable.
What this means for integrations
- Use an admin or integration token when a job legitimately writes a protected attribute; customer tokens and guest calls fail validation.
- In bulk or async customer-level payloads, omit protected attributes entirely.
- Custom API services or GraphQL mutations that bypass the native input paths are not covered — they must validate untrusted input themselves before mutating customer data.
The guard covers scalar attributes (text, numbers, selects, serialized settings). File and image attributes are outside its contract, and a declaration does not grant ACL permissions by itself.
Protected attributes by module
Each module registers its own codes as arguments on MageB2B\ExtensionManager\Plugin\Customer\RestrictCustomAttributesPlugin in its etc/di.xml. The current SoftwareSilo declarations are:
| Package | Protected attributes |
|---|---|
mageb2b/customer-id |
customer_id |
mageb2b/customer-tfa |
tfa_enabled |
mageb2b/sublogin |
can_create_sublogins, max_number_sublogins, sublogin_optional_email, sublogin_sales_report_config; address attribute sublogin_id |
mageb2b/sublogin-budget |
budgets, can_manage_budgets |
mageb2b/sublogin-role |
can_manage_role |
mageb2b/staff |
primary_staff_id, inherit_restrict_sublogins |
mageb2b/pricesystem-advancedconfig |
priceselect, verified, price_formula, discountable |
mageb2b/pricesystem-productcustomermatrix |
procustmatrix_customer_group |
Only the declared attributes are guarded — installing a listed module does not protect unrelated customer attributes.