Microsoft is changing a small but important part of the Partner Center growth margins API contract. From November 23, 2026, seatIncreaseMultiplier will support decimal values instead of being an integer. Partners with integrations that consume this field should check their data models, validation rules, and downstream processing before the change takes effect.
The announcement, published on November 6, is specifically aimed at partners integrating with the growth margins APIs. It is not a broader change to growth margin behavior: Microsoft says no other fields or behaviors are changing as part of this update. The practical task is to make sure an otherwise working integration does not reject—or silently alter—a fractional multiplier.
What is changing?
The seatIncreaseMultiplier field is moving from an integer to a decimal value to allow more precise seat-expansion configurations. That changes what consumers must be able to accept, even if their existing implementation has only encountered whole numbers.
Microsoft identifies three affected API surfaces:
- Get growth margins.
- Get growth margin by ID.
- The growth margin eligibility API, specifically the SeatExpansionGrowthMarginConstraintsNotMet error response.
That last item deserves particular attention. A review limited to successful responses can miss an incompatible model in an error-handling path. If your application extracts constraints from an eligibility failure to explain why a request did not qualify, it needs to preserve decimal values there too.
Why a data-type change can matter operationally
An integer-only consumer may fail to deserialize a fractional value. Other implementations may accept the response but convert the field to a whole number later, potentially losing information. Neither outcome requires a major API redesign: a restrictive schema, an integer database column, or an explicit conversion can be enough.
The risk is therefore broader than the code that makes the HTTP request. Check any layer that reads, stores, forwards, or displays this field, including generated API clients, internal service contracts, reporting pipelines, and partner-facing explanations of eligibility results.
For example, a hypothetical multiplier of 1.5 should not become 1 simply because an internal model still expects an integer. This is an illustrative test value, not a multiplier Microsoft has announced or a statement about the field’s permitted range.
Default behavior and scope: what not to assume
Microsoft has not announced a new default multiplier in this notice. Nor does the announcement say that every response will immediately contain a fractional value. The requirement is to support decimal values when they are returned after the effective date.
An integration that already preserves fractional numeric values throughout its processing may need no code change. That should still be confirmed through testing rather than inferred from the programming language alone: validation libraries, generated models, and storage schemas can impose stricter rules than the runtime’s general-purpose number type.
Conversely, this announcement does not by itself justify changing your eligibility calculations or commercial assumptions. Treat it as a compatibility update. For field semantics and related requirements, consult Microsoft’s growth margins documentation.
Partner next steps before November 23
1. Locate every consumer of the field
Search for seatIncreaseMultiplier across integration code, API schemas, test fixtures, persistence models, and reporting transformations. Include any shared library that handles growth margin eligibility errors. Assign an owner to each affected component so the update does not stop at the primary API client.
2. Remove integer-only assumptions
Update restrictive types or validation rules where necessary. Use a numeric representation appropriate to your platform and precision requirements, and avoid casts or formatting rules that discard the fractional part. If the value is passed between services, review both the producing and consuming contracts.
This is not a reason to indiscriminately accept arbitrary input. Preserve the existing validation rules that remain applicable while removing assumptions that this particular field must be a whole number.
3. Test successful and error responses
Use representative fixtures containing both whole-number and fractional values. Verify that values survive parsing, storage, serialization, and display without unintended rounding or truncation. Exercise the SeatExpansionGrowthMarginConstraintsNotMet response explicitly, including any logic that turns its details into a support message or user-facing explanation.
These are recommended compatibility tests, not additional requirements stated in Microsoft’s announcement. Their purpose is to expose dependencies that a simple request-and-response smoke test might miss.
4. Deploy and monitor the affected paths
Complete required changes before November 23, 2026. After the effective date, monitor deserialization failures, schema-validation errors, and unusual failures in eligibility-result handling. Where possible, make it easy to distinguish a genuine eligibility failure from an application error caused by interpreting the response incorrectly.
Bottom line
This is a narrow API change with a clear preparation task: ensure that seatIncreaseMultiplier can carry a fractional value end to end. Partners should review both growth margin retrieval endpoints and the relevant eligibility error response, then test any integer-only assumptions before November 23. Microsoft has scoped the update to this field’s data type; there is no announced change to other fields or behaviors.