I’m migrating a design manager serverless function (ahead of the CVE-2026-111497 Node.js runtime sunset) to a developer-project app-function-endpoint, platform version 2026.09. The function is a write operation, so I declared config.endpoint.methods: [“PATCH”, “POST”].
PATCH requests to the deployed endpoint (https:///hs/serverless/) consistently return 403 Request Forbidden (plain text, no JSON body) — but GET, POST, and OPTIONS to the exact same endpoint all work correctly.
What I’ve ruled out:
- Not my function code - a POST with the identical payload reaches the function fine and returns its own real error response.
- Not app-installation state - tested both before and after installing the app on the account; PATCH was blocked identically both times.
- Not a client/bot-detection issue - reproduced identically via curl and a real browser (same-origin request, matching Origin/Referer, real session cookies).
- Not a config/schema problem - hs project validate passes with 0 errors, and HubSpot’s own serverless-functions-in-projects reference docs list GET, POST, PUT, PATCH, DELETE as equally supported, with no caveat about PATCH.
The interesting part: an OPTIONS request to the same endpoint returns 200 with Allow: HEAD,DELETE,POST,GET,OPTIONS,PATCH,PUT - so the routing layer itself registers PATCH as valid for this endpoint. The OPTIONS response also includes HubSpot’s own routing headers (x-hs-cfworker-meta, x-hubspot-correlation-id), confirming it reached HubSpot’s serverless routing worker. But the actual PATCH request’s 403 response is missing every one of those headers, meaning it’s rejected before reaching the same layer that just told me PATCH was supported.
So: OPTIONS says PATCH is allowed, POST/GET prove the function and routing both work, but PATCH itself is blocked at the edge. Anyone else running into this, or know if there’s a known restriction on write methods for public app-function-endpoints right now? Already filed a support ticket, posting here too in case others have hit the same thing.