[tim-kos]

Storage requests now include their HTTP method and URL path in the signed params:

{ "auth": { "key": "…", "expires": "…", "method": "GET", "path": "/dam/assets" } }

The Transloadit API accepts these fields on Storage (/dam/*) requests and will require them there.

Changes

• getStoredAsset, listStoredAssets, moveStoredAsset and deleteStoredAsset set auth.method (upper case) and auth.path before signing.
• The path comes from the final request URL, so an endpoint with a base path signs the path the API actually receives.
• Other requests are signed exactly as before.
• Changeset: minor for @transloadit/node and transloadit, patch for @transloadit/mcp-server.

Release and deployment order

1. Wait until API2 #11020 is fully deployed to production. Older API2 servers reject these new fields as unknown parameters. Hold the SDK release until that deployment is complete.
2. Merge this PR and publish a release containing it. Then bump and deploy Content to that release; merging or publishing alone does not migrate deployed consumers.
3. Separately deploy Content #7272, which updates the hand-signed File Library search request. The SDK upgrade does not cover that request.
4. API2 #11023 must remain unmerged until the SDK consumers, search request, and Companion migration are deployed and verified in production. It rejects older, unbound signed DAM callers.

The complete rollout and verification gate is in API2 #11020.

Tests

• New unit tests:
  • Each of the four Storage methods signs its own method and path.
  • An endpoint with a base path signs the full path.
  • Other signed requests carry neither field.
• vitest run test/unit in packages/node: 1132 passed, 1 skipped. tsc:node, Biome and the changeset guard pass.

🤖 Generated with Claude Code