Advocate
Last updated
Last updated
The advocate and advocate-clerk service allows for the creation, updating and search of advocates and clerks in DRISTI. The APIs are designed to create a single source of truth for advocate-related data, ensuring that each advocate and their clerks are uniquely identified and consistently represented across various systems.
This registry and service plays a pivotal role in establishing a unified and authoritative source of data for advocates and their clerks. By assigning unique identifiers to each advocate and their clerks, the API ensures that every individual is distinctly recognised. With unique identifiers, all interactions involving an advocate, whether in court proceedings, document submissions, or case management, are accurately linked to their profile. This eliminates discrepancies that might arise from duplicate or mismatched records.
The Advocate and Clerk APIs are designed with interoperability in mind, allowing seamless integration with other systems within the judicial ecosystem. This integration capability is crucial for creating a cohesive digital environment where data can flow smoothly between different platforms.
Here’s how other systems can benefit:
Access to Up-to-Date Advocate Information: Systems that integrate with the Advocate API can access real-time, accurate data on advocates and their clerks. Whether it's a case management system, an e-filing platform, or a court scheduling tool, these systems can retrieve the latest information without the need for manual updates or separate databases.
Streamlined Workflows: By integrating with the Advocate API, other systems can automate various processes involving advocates, such as case assignments, document sharing, and notifications. This reduces administrative overhead and speeds up judicial workflows, benefiting both legal professionals and the courts.
Cross-System Data Synchronisation: The API ensures that all connected systems are synchronised, meaning that any changes made in one system (e.g., updating an advocate’s contact details) are automatically propagated to all other integrated systems. This harmonization minimizes the risk of errors and ensures that all stakeholders are working with the most current information.
Registration (/advocate/v1/_create): Registers a new advocate or clerk, requiring details like ID, tenant ID, and bar registration number.
Update (/advocate/v1/_update): Updates the advocate's information, requiring similar details as the create operation.
Status Search (/advocate/v1/_status/_search): Searches for the status of advocate registrations, optionally filtering by status or application number.
Application Search (/advocate/v1/applicationnumber/_search): Searches for an advocate by application number.
General Search (/advocate/v1/_search): Allows for a broader search of advocates, optionally filtering by bar registration number and status.
Similar actions can be carried out for the clerks through the following methods:
/clerk/v1/_create: Register a new advocate clerk
/clerk/v1/_update: Update Advocate clerk information
/clerk/v1/status/_search: Search for advocate clerks using the status of their registration
/clerk/v1/applicationnumber/_search: Search for clerks using the Application Number of their registration
/clerk/v1/_search: Search for registered advocate clerk
Business (Module)=user-registration
Business Service (Workflow) Name=user-registration-advocate
Business (Module)=user-registration
Business Service (Workflow) Name=user-registration-advocate-clerk
Below are the Kafka topics to which this service publishes data:
save-advocate-application
When a new advocate is registered in the system
Advocate create payload. Refer to API spec.
update-advocate-application
When advocate info or workflow status is updated in the system
Advocate update payload. Refer to API spec
save-advocate-clerk
When a new advocate clerk is registered in the system
AdvocateClerk create payload. Refer to API spec
update-advocate-clerk-application
When clerk data or workflow state is changed.
AdvocateClerk update payload. Refer to API spec.
For more functional/process details on the workflows, please refer to . Two separate workflows have been defined for the advocate and advocate clerk.
View the actual .
