passbolt/passbolt_api · error · Passbolt\Scim\Exception\ConflictException

The resource with id ` ` could not be created due to a…

Error message

The %s resource with id `%s` could not be created due to a uniqueness conflict

What it means

This ConflictException is thrown when a SCIM create (POST) payload includes an "id" field. SCIM ids are server-assigned, so a client supplying one during creation is treated as a uniqueness conflict in validateCreatePreconditions().

Solutions

Remove the "id" field from the POST payload (ids are server-generated)
Use PATCH /Users/{id} or PUT instead of POST when the resource already exists
If the user exists, look it up via GET /Users?filter=userName eq ... before creating

Example fix

// before
{"id":"4c2a...","userName":"jdoe@example.com","emails":[{"type":"work","value":"jdoe@example.com"}]}
// after
{"userName":"jdoe@example.com","emails":[{"type":"work","value":"jdoe@example.com"}]}

Defensive patterns

Strategy: validation

Validate before calling

if (isset($payload['id'])) {
    unset($payload['id']); // ids are server-assigned on POST
}
// or bail early:
if (!empty($payload['id'])) {
    throw new InvalidArgumentException('Do not send "id" on SCIM create.');
}

Try / catch

try {
    $scimUsers->create();
} catch (\Passbolt\Scim\Exception\ConflictException $e) {
    if ($e->getScimType() === 'uniqueness') {
        // look up existing resource and switch to PATCH/PUT
    }
}

Prevention

Never POST objects fetched from the server; strip id, meta, and schemas before create
Use GET /Users?filter=userName eq "..." to detect existing resources before POST
Configure the IdP to use standard create (no id in payload) — most IdPs do this by default

When it happens

Trigger: POST /scim/v2/Users with an "id" property in the JSON body — typically a client replaying a resource it fetched instead of stripping the server-generated id.

Common situations: IdP sync loops re-POSTing existing resources, custom scripts cloning a fetched user object and POSTing it back, or switching provisioning from PATCH to full-object POST without sanitizing the payload.

Understand the failure class

Background: "already exists" / EEXIST / FileAlreadyExistsException: what the 'file already exists' error means and how to fix it — this error's family across 37 libraries.

Related errors

AI-assisted analysis of passbolt/passbolt_api@31c1bbc10f (2026-09-17). Data as JSON: /api/errors/67c1c5250c903629. Report an issue: GitHub.

Appendix: source

Thrown at plugins/PassboltEe/Scim/src/Utility/Resource/UserScimResource.php:297

        return $this;
    }

    /**
     * Validate preconditions before attempting user creation.
     *
     * @throws \Passbolt\Scim\Exception\BadRequestException When "work" email is missing in the payload.
     * @throws \Passbolt\Scim\Exception\ConflictException When resource id is already present.
     */
    private function validateCreatePreconditions(): void
    {
        if (!$this->email) {
            throw new BadRequestException(
                sprintf('No email with type "work" was found in the %s payload.', $this->getType()),
                scimType: ScimException::SCIM_TYPE_INVALID_VALUE,
            );
        }
        if ($this->id) {
            throw new ConflictException(
                sprintf(
                    'The %s resource with id `%s` could not be created due to a uniqueness conflict',
                    $this->getType(),
                    $this->id
                ),
                scimType: ScimException::SCIM_TYPE_UNIQUENESS,
            );
        }
    }

    /**
     * Find an existing user by email with a FOR UPDATE lock, loading associations.
     *
     * @return \App\Model\Entity\User|null
     */
    private function findAndLockExistingUser(): ?User
    {
        // Atomic locking between the uniqueness check and user insertion.

View on GitHub (pinned to 31c1bbc10f)