web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

News and Announcements icon
Community site session details

Community site session details

Session Id :
Power Platform Community / Forums / Power Pages / Power Pages Web API: P...
Power Pages
Answered

Power Pages Web API: PATCH by GUID returns 500 (9004010A) on Contact-scope table

(1) ShareShare
ReportReport
Posted on by 23
I'm creating a single-page application site in Power Pages and I have a custom Dataverse table (mytable) with a Contact-scope table permission (contactrelationship set to a lookup field pointing back to the current portal user) that is only partially working. The table permission has read: true, write: true, create: true.

What works

  • GET /_api/mytable?$select=...&$filter=...
    • Collection GET with OData filter works correctly and respects Contact-scope (only returns the current user's records)
  • POST /_api/mytable
    • Creating a new record with cd_Applicant@odata.bind: /contacts(...) works (204)

What fails

  • PATCH /_api/mytable(guid)
    • Always returns 500 / 9004010A, regardless of body content
  • This is consistent with a known issue where GET /_api/mytable(guid) (direct by primary key) also returns 500 for Contact-scope tables

I have verified

  • The CSRF token (__RequestVerificationToken) is valid
    • A 401 test with an invalid token confirms the token mechanism works
  • The Webapi/<table>/fields site setting has every field in the PATCH body explicitly listed (not *)
  • Content-Type: application/json and OData-Version: 4.0 headers are present
  • The record being PATCHed was created by the current portal user in the same session, so the Contact relationship is set correctly
  • Reducing the PATCH body to a single simple field ({"status_field": 0}) still returns the same error
Is PATCH by primary key simply not supported for Contact-scope tables in Power Pages Web API, the same way GET by primary key is not supported? If so, what is the recommended pattern for updating an existing Contact-scope record from a portal SPA/Code Site?
I have the same question (0)
  • Suggested answer
    Ajlan Profile Picture
    237 on at
    Hey,

    Yes, this is a known limitation. PATCH /_api/mytable(guid) has the same issue as GET by primary key for Contact-scope tables, the permission join that validates record ownership simply doesn't run for direct-PK requests, hence the 9004010A error. It's not your CSRF token, headers, or site settings.
    The fix is to use $filter instead of addressing the record by GUID in the URL:
    PATCH /_api/mytable?$filter=mytable_id eq <your-guid>
  • bspangler Profile Picture
    23 on at
    @Ajlan thanks for confirming this is a known limitation! Unfortunately, when I tried the PATCH via $filter, I got the following error: failed (405): {"error":{"code":"9004010D","message":"Common Data Service error occurred.","cdscode":"","innererror":{"code":"","message":"The requested resource does not support http method 'PATCH'."}}}
  • Verified answer
    rezarizvii Profile Picture
    352 on at
    Hi, hope you're doing well.
     
    For Contact-scoped permissions, the Web API doesn’t reliably support single-record operations by primary key. That’s why both:
    • GET /_api/mytable(guid)
    • PATCH /_api/mytable(guid)
    blow up with 500 / 9004010A, even though collection queries respect the scope just fine.
     
    If this reply helped you in any way, please give it a Like 💜 and in case it resolved your issue, please mark it as the Verified Answer ✅.
  • Suggested answer
    11manish Profile Picture
    2,286 on at
    PATCH by primary key is not reliably supported for Contact-scope tables in Power Pages Web API, similar to GET by ID.
     
    The recommended approach is to either use a filter-based PATCH request or move updates to a server-side mechanism like Power Automate or a custom API for
     
    secure and consistent behavior.
  • bspangler Profile Picture
    23 on at
    @rezarizvii and @11manish are correct: this does not seem to be supported. DELETE also seems to fail, so it appears only POST is supported. This is pretty disappointing from the Microsoft end.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Introducing the 2026 Season 1 community Super Users

Congratulations to our 2026 Super Users!

Kudos to our 2025 Community Spotlight Honorees

Congratulations to our 2025 community superstars!

Congratulations to the April Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > Power Pages

#1
Valantis Profile Picture

Valantis 65

#2
11manish Profile Picture

11manish 55

#3
Vish WR Profile Picture

Vish WR 29

Last 30 days Overall leaderboard