Skip to content

Regenerate PHP SDK: restore method names, 14.1.0 parameter order, and form field names - #629

Merged
camden11 merged 3 commits into
masterfrom
cphalen/php-sdk-friendly-operation-names
Oct 9, 2026
Merged

camden11 merged 3 commits into
masterfrom
cphalen/php-sdk-friendly-operation-names

Conversation

@camden11

@camden11 camden11 commented Oct 8, 2026 •

Copy link
Copy Markdown
Contributor

Why

Since 14.1.0, upstream spec changes broke the SDK in two ways:

  1. Path-style method names (crmV3Owners(), settingsUsersV3(), marketingV3Forms_0()…) replaced names that were getPage/create/etc. in earlier releases.

  2. Silently reordered parameters. The specs now list parameters alphabetically, so 115 methods take positional arguments in a different order than 14.1.0. That includes getPage/getById on every CRM object. Existing calls keep running but send values to the wrong parameters: crm owners getPage(null, null, 1) filtered by email=1, and users getPage(5) sent after=5.

  3. Files upload is broken. Multipart form fields are sent under their PHP variable names (folder_path, file_name, …) instead of the wire names (folderPath, fileName, …). The API ignores them, so every upload fails with 400 "Either folderId or folderPath is required". Imports AdvancedApi has the same problem (import_request vs importRequest). 14.1.0 was fine because FilesApi had been hand-fixed (184f63f9), and the Sep 9 regen overwrote it.

None of these problems is in any tagged release (latest is 14.1.0); they're only on dev-master.

What

Regenerated with HubSpotEngineering/api-clients#381, which restores the names, the 14.1.0 parameter order, and the form field names.

Endpoint 14.1.0 / v12.2.0 dev-master before This PR
GET /crm/v3/owners getPage($email, $after, $limit, $archived) crmV3Owners($after, $archived, $email, $limit) getPage($email, $after, $limit, $archived)
GET /settings/users/v3 getPage($limit, $after) settingsUsersV3($after, $limit) getPage($limit, $after)
GET /crm/v3/objects/contacts getPage($limit, $after, $properties, …) getPage($after, $archived, $associations, $limit, …) getPage($limit, $after, $properties, …)
  • Parameters added upstream since 14.1.0 go after the existing ones.
  • Imports GET /crm/v3/imports is now getImportsPage. Upstream removed its before parameter, so old getPage(after, before, limit) calls fail loudly instead of passing before as limit.
  • Files and Imports form fields use their wire names again, generated rather than hand-fixed, so the next regen keeps them.

Verification

  • Comparing every same-name method with 14.1.0: 608 match, with 0 positional mismatches. Pipelines replace only had its body parameter renamed in place.
  • No endpoints were removed and no parameter sets changed, apart from the Imports rename. No class has duplicate methods, and no path-style names remain.
  • No hand-written code (lib/, tests, README) calls the old names.
  • All 24 multipart/form keys match their spec property names; Files and Imports match 14.1.0.
  • php -l clean. phpspec 139/139 and phpunit pass locally.
  • Left out: unrelated upstream model drift from the same regen (a new tab_app_card_id field on a CRM cards model, and Marketing/Transactional docblocks). The next regen will pick it up.

🤖 Generated with Claude Code

camden11 and others added 2 commits October 8, 2026 12:04
The previous regen shipped ~70 methods with path-derived names
(`crmV3Owners()`, `settingsUsersV3()`, `marketingV3Forms_0()`, ...)
because the upstream specs dropped the name part of their operationIds.
Most of those methods were `getPage`/`create`/etc. in earlier releases.

Regenerated with api-clients' operationId overrides ("Override
operationIds that generate path-style PHP method names"). Only method
names change: same endpoints, same parameters. The one exception is
Cms\UrlRedirects BasicApi, which also picks up four url-mappings
endpoints added upstream since the last regen.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Since 14.1.0 the upstream specs list parameters alphabetically, so
regens silently reordered positional arguments on 115 methods,
including getPage/getById on every CRM object. Existing calls kept
running but sent values to the wrong parameters: crm owners
getPage(null, null, 1) filtered by email=1, and users getPage(5) sent
after=5.

Regenerated with api-clients' 14.1.0 parameter-order transform. Every
changed method keeps the same parameters, now in 14.1.0 order. Imports
getPage is renamed to getImportsPage because upstream removed its
`before` parameter, so old calls fail loudly instead of passing `before`
as `limit`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@camden11 camden11 changed the title Regenerate PHP SDK: restore friendly method names Regenerate PHP SDK: restore friendly method names and 14.1.0 parameter order Oct 8, 2026
Since the Sep 9 codegen, Files upload/replace sent form fields under
their PHP variable names (folder_path, file_name, folder_id,
charset_hunch). The API ignores those, so every upload failed with 400
"Either folderId or folderPath is required". Imports AdvancedApi had the
same problem (import_request instead of importRequest). 14.1.0 was fine
because FilesApi had been hand-fixed (184f63f), and that regen
overwrote it.

Regenerated with api-clients' PHP template override, which keys form
data by the spec's property name. All form keys in the SDK now match
their spec, and the Files and Imports keys match 14.1.0 again.

The same regen also drops Cms\UrlRedirects' four url-mappings
endpoints, which upstream has removed from the spec again since the
previous regen.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@camden11 camden11 changed the title Regenerate PHP SDK: restore friendly method names and 14.1.0 parameter order Regenerate PHP SDK: restore method names, 14.1.0 parameter order, and form field names Oct 8, 2026
@camden11
camden11 merged commit 9297590 into master Oct 9, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants