Legacy Knowledge Base
Published Jun. 30, 2025

Discrepancy in Batch Behavior: headless-commerce-admin-account vs. headless-admin-user

Written By

Sorin Pop

How To articles are not official guidelines or officially supported documentation. They are community-contributed content and may not always reflect the latest updates to Liferay DXP. We welcome your feedback to improve How To articles!

While we make every effort to ensure this Knowledge Base is accurate, it may not always reflect the most recent updates or official guidelines.We appreciate your understanding and encourage you to reach out with any feedback or concerns.

Legacy Article

You are viewing an article from our legacy "FastTrack" publication program, made available for informational purposes. Articles in this program were published without a requirement for independent editing or verification and are provided"as is" without guarantee.

Before using any information from this article, independently verify its suitability for your situation and project.

Issue

  • We’ve encountered a discrepancy in how batch operations work for Accounts between the headless-commerce-admin-account API (now deprecated) and the newer headless-admin-user API.

    • Previous Behavior (headless-commerce-admin-account)
      We used the POST /v1.0/accounts/batch endpoint to upsert multiple Accounts at once. If an Account already existed (matched by its ID), it was updated; otherwise, it was created. Effectively, we only needed a single endpoint call for both create and update operations.

    • Current Behavior (headless-admin-user)
      We’re now using the headless-admin-user API for Accounts, but it appears the upsert behavior has changed. Instead of one endpoint handling both creation and updates, there are separate POST (create) and PUT (update) endpoints. This means we have to check whether each Account exists before deciding which endpoint to use, significantly changing our import processes.

    It also seems that other batch endpoints in headless-commerce-admin-* continue to behave like upserts and do not offer a separate PUT endpoint. We’d like to confirm:

    1. Is this change in behavior (separating create and update) intentional or could it be a bug?
    2. If it is intentional, can you clarify why the old Commerce endpoints still provide upsert-like functionality, while the new headless-admin-user endpoints require separate POST and PUT calls?

Environment

  • 7.4

Resolution

    • headless-commerce-admin-account ---> this is a deprecated API where the POST method works wrongly as upsert (if it doesn’t exists it creates it, otherwise it updates it). This is a wrong behavior as the POST should work just to create resources and not to update them.
    • headless-admin-user ---> the API used to manage users / accounts … here the POST method has the correct behavior (just create resources) but you can have the same approach using the PUT verb (It should be o/headless-admin-user/v1.0/accounts/by-external-reference-code/${ERC})
    But because you’re using the batch endpoint /v1.0/accounts/batch you can use something like this (this is just an example with the min data needed)
     
     
    { "items": [ {          "externalReferenceCode": "account1ERC",          "name": "account1",          "status": 0,          "type": "business",        },{          "externalReferenceCode": "account2ERC",          "name": "account2",          "status": 0,          "type": "business"        } ] }
    and calling the endpoint v1.0/accounts/batch?createStrategy=UPSERT (so adding the createStrategy=UPSERT) I think you get what you need -  if the account with the ERC provided exists it updates it otherwise it creates it
    So basically it’s the createStrategy parameter that should do the trick with the headless-admin-user APIs.

 

Did this article resolve your issue ?

Legacy Knowledge Base