This set of APIs manages the full lifecycle of a “Party” resource. Each API plays a specific role, and together they provide a standard create–read–update pattern.

1. Create Party API

POST /party

This endpoint is responsible for creating a new party in the system.

Operation:

• The authenticated client sends party details in the request body.
• The server validates and stores the new party.
• A unique party id is generated and returned in the response.

Required fields:

{
  "caseId": "string",
  "partyType": "string",
  "primaryEntity": true
}

If the payload has primaryEntity set to true, then the previous primary party in the case will have its primaryEntity field set to false.

Typical Response (201 Created):

{
  "id": "uuid string",
  "createdDate": "UTC time"
  ...
}

Purpose:

• Initialize a fresh party record.
• Retrieve the ID required for further operations (retrieval, updates).

2. Retrieve Party API

GET /party/:id

This endpoint is used to fetch an existing party by its ID.

Operation:

• Client sends a GET request with the id returned from the create step.
• The server validates the ID and returns the party details.

Typical Response (200 OK):

{
  "id": "uuid string",
  "createdDate": "UTC time"
  ...
}

Purpose:

• View existing party information.
• Confirm data that was created or previously updated.

3. Update Party API

PUT /party/:id or PATCH /party/:id

These endpoints allow modifying an existing party.

• PUT: replaces the entire party record with the new payload.
• PATCH: applies a partial update, only modifying provided fields.

Operation:

• Client sends updated fields with the correct id.
• Server applies the update and returns the updated record or status.

Typical Response (200 OK):

{
  "id": "12345",
  "createdDate": "UTC time",
  ...
}

Purpose:

• Modify or correct party information.
• Progress the party through its lifecycle.

How They Work Together

1. Create a party using POST /party.
2. Server returns an id.
3. Use this ID to either:
   1. Retrieve the party (GET /party/:id)
   2. Update the party (PUT/PATCH /party/:id)

This flow ensures all party operations are securely tied to an authenticated session, and that each party is managed consistently using its unique identifier.