JSON Models and Field Mapping for Legal Publications to ERP and CRM Systems
A practical guide to JSON payloads, field mapping, deduplication, deadlines, documents, and audit trails for Salesforce, TOTVS, and Google Calendar.
Explore a practical integration framework
In this article9 sections
- Why JSON models matter when integrating legal publications
- The minimum data model for a legal publication API
- How to map fields and prevent duplicate processes
- How to implement a legal publication webhook step by step
- Ten JSON payloads for Salesforce, TOTVS, and calendar workflows
- How to handle timestamps, chain of custody, and calendars
- Mapping legal publication data to Salesforce and TOTVS
- Where Pocket Jurídico fits in the integration workflow
- Common integration mistakes and governance controls
Why JSON models matter when integrating legal publications
JSON models and field mapping for legal publications determine whether a notice becomes useful work or another record that someone must clean manually. A publication may contain a case number, court, party, movement, document, deadline, and responsible team, but ERP and CRM systems usually store those elements in different objects and formats.
The operational risk is easy to underestimate. If one court publication creates three CRM activities, two duplicated cases, and a calendar entry without a time zone, the legal team may spend more time correcting the integration than reviewing the notice itself.
A sound integration treats every publication as a business event with a stable identity, clear relationships, and traceable source data. The payload should answer five questions: what happened, which case does it concern, when was it received, what action is required, and how can the original evidence be verified?
This approach is particularly important for Brazilian legal departments and law firms monitoring high volumes across courts and official journals. Publications can arrive before their formal publication dates, while the same case can generate updates in multiple instances. A field model must preserve both the event timeline and the process history instead of flattening everything into a single text field.
The RFC 3339 specification provides a useful foundation for timestamp formatting because it makes offsets explicit. In practice, that means storing a value such as 2026-10-22T14:30:00-03:00 instead of relying on an ambiguous local time.
The minimum data model for a legal publication API
The minimum payload should include an event identifier, process identifier, publication identifier, event type, source, timestamps, and a link to the original record. These fields form the integration envelope. Case details, parties, lawyers, courts, and extracted deadlines belong inside structured business objects rather than being embedded only in a summary.
A practical base model can use the following field groups: identity, process, publication, movement, action, documents, and provenance. Identity prevents duplication, process connects the event to the correct matter, publication preserves the official notice, and provenance records how the data was collected or transformed.
For Salesforce, a common mapping is Process to a custom Matter object, Publication to a custom Legal_Publication__c object, Movement to an Activity or custom Movement__c object, and Deadline to a Task or custom Legal_Deadline__c object. The exact object names vary by org, so the integration should use a configurable mapping layer rather than hardcoding labels into the source system.
For TOTVS environments, the same concepts may map to process, legal matter, activity, commitment, attachment, or custom integration entities, depending on the product and module in use. The important principle is semantic consistency: a court case number should never be mapped to a free-text comment simply because that field is convenient.
A useful minimum field inventory is: pocket_event_id, process_key, case_number, court, instance, publication_date, captured_at, event_type, title, content, source_url, document_ids, deadline_ids, confidence, and custody_hash. Fields that are not available should be null or omitted according to the receiving API contract, never replaced with invented values.
How to map fields and prevent duplicate processes
- ✓Use a stable process key built from the normalized case number, court, and instance. If a case number is unavailable, use a controlled fallback based on the Pocket Jurídico cover identifier and source metadata, then flag the record for review.
- ✓Use the Pocket Jurídico event identifier as the immutable external ID for the publication event. A CRM upsert should match this value before creating a new activity, task, or publication record.
- ✓Create a second deduplication key from the process cover identifier and a normalized content hash. This combination helps identify repeated captures of the same notice while preserving genuinely different movements on the same case.
- ✓Separate process identity from event identity. One process can have hundreds of publications, and one publication can contain multiple extracted deadlines or documents.
- ✓Normalize case numbers before comparison by removing punctuation, spaces, and inconsistent formatting, while retaining the original value for display and audit purposes.
- ✓Do not use the publication title alone as a unique key. Titles such as Notice, Order, or Hearing can repeat across the same case and across different courts.
- ✓Store the source timestamp, ingestion timestamp, transformation timestamp, and destination timestamp separately. This makes delays visible and supports later investigation.
- ✓Treat LLM-generated summaries and deadlines as derived data. Preserve the original publication, extraction model, prompt version, confidence, and reviewer status alongside the derived result.
- ✓Make webhook handlers idempotent. If the same event arrives five times, the destination should acknowledge it five times but create or update only one business record.
- ✓Use dead-letter handling for rejected payloads. Retain the original request, validation error, retry count, and resolution status instead of silently dropping the event.
How to implement a legal publication webhook step by step
- 1
Define the canonical event contract
Agree on one source model before mapping it to Salesforce, TOTVS, or an internal platform. Define required fields, permitted event types, null behavior, date formats, maximum text lengths, and whether each object is created, updated, or upserted.
- 2
Establish identity and ownership rules
Choose the process key, publication key, and document key before sending production data. Decide which system owns each field, such as case number in the legal platform, account owner in the CRM, and calendar status in the scheduling system.
- 3
Build a transformation layer
Convert the canonical JSON into destination-specific shapes. This layer can translate a deadline into a Salesforce Task, a TOTVS commitment, or a Google Calendar event without changing the original legal event.
- 4
Secure and validate the request
Use HTTPS, an authentication token or OAuth flow, request identifiers, timestamp checks, and an HMAC signature where supported. Validate schema, required fields, allowed enumerations, and maximum payload size before writing to the destination.
- 5
Upsert the process before the event
Resolve the process using the normalized process key and cover identifier. If no match exists, create a pending process record or route the event to a review queue rather than creating an unverified duplicate.
- 6
Upsert the publication and related objects
Use the publication event ID as the external key. Create related movements, deadlines, documents, and comments with their own keys, preserving parent-child relationships and returning destination IDs to the integration log.
- 7
Test difficult cases
Test repeated webhooks, the same case across multiple instances, multiple deadlines in one notice, attachments larger than destination limits, missing party data, daylight-saving changes, and temporary destination outages.
- 8
Monitor operational quality
Track delivery latency, acceptance rate, duplicate rate, failed field mappings, unresolved process matches, and deadline creation errors. A useful first target is to review every rejected event within one business day and every unlinked deadline before its due date.
Ten JSON payloads for Salesforce, TOTVS, and calendar workflows
The following compact payloads illustrate a canonical model that can be transformed for Salesforce or TOTVS. The names ending in __c represent common Salesforce custom fields, while TOTVS mappings should be configured against the specific legal or ERP module in use. The examples use fictitious values and should be adapted to the receiving API schema.
- New publication event:
{
"event_type": "publication.created",
"pocket_event_id": "pj_evt_01J9PUB001",
"process": { "process_key": "00123456720268190001", "case_number": "0012345-67.2026.8.19.0001", "court": "TJRJ", "instance": "first" },
"publication": { "publication_id": "pj_pub_01J9PUB001", "publication_date": "2026-10-22", "title": "Notice of procedural movement", "content": "Official publication text", "source_url": "https://example.invalid/source" },
"captured_at": "2026-10-21T18:42:11-03:00",
"salesforce": { "object": "Legal_Publication__c", "external_id_field": "Pocket_Event_Id__c", "status__c": "New" },
"totvs": { "entity": "legal_publication", "external_id": "pj_pub_01J9PUB001" }
}
- Movement update:
{
"event_type": "movement.created",
"pocket_event_id": "pj_evt_01J9MOV002",
"process_key": "00123456720268190001",
"movement": { "movement_id": "pj_mov_01J9MOV002", "code": "ORDER_ISSUED", "description": "The court issued an order", "occurred_at": "2026-10-22T10:15:00-03:00" },
"parent_publication_id": "pj_pub_01J9PUB001",
"salesforce": { "object": "Movement__c", "external_id_field": "Pocket_Movement_Id__c" },
"totvs": { "entity": "legal_movement", "external_id": "pj_mov_01J9MOV002" }
}
- Deadline extracted by an LLM:
{
"event_type": "deadline.extracted",
"pocket_event_id": "pj_evt_01J9DL003",
"process_key": "00123456720268190001",
"deadline": { "deadline_id": "pj_dead_01J9DL003", "type": "response", "due_date": "2026-11-03", "business_days": 10, "timezone": "America/Sao_Paulo", "status": "pending", "confidence": 0.94 },
"extraction": { "provider": "approved_llm", "model": "configured-model", "prompt_version": "deadline-v3", "source_span": "The defendant shall respond within 10 business days", "human_review": "pending" },
"salesforce": { "object": "Task", "subject": "Review response deadline", "external_id_field": "Pocket_Deadline_Id__c" },
"totvs": { "entity": "legal_commitment", "external_id": "pj_dead_01J9DL003" }
}
- Multiple deadlines in one publication:
{
"event_type": "deadlines.extracted",
"pocket_event_id": "pj_evt_01J9DL004",
"process_key": "00123456720268190001",
"deadlines": [
{ "deadline_id": "pj_dead_01J9DL004A", "type": "response", "due_date": "2026-11-03", "business_days": 10 },
{ "deadline_id": "pj_dead_01J9DL004B", "type": "document_submission", "due_date": "2026-11-10", "business_days": 15 }
],
"parent_publication_id": "pj_pub_01J9PUB001",
"mapping_rule": "create_one_child_task_per_deadline"
}
- Document attachment:
{
"event_type": "document.attached",
"pocket_event_id": "pj_evt_01J9DOC005",
"process_key": "00123456720268190001",
"document": { "document_id": "pj_doc_01J9DOC005", "name": "court-order.pdf", "mime_type": "application/pdf", "size_bytes": 483921, "download_url": "https://api.example.invalid/documents/pj_doc_01J9DOC005", "sha256": "fictitious-example-hash" },
"parent_publication_id": "pj_pub_01J9PUB001",
"salesforce": { "object": "ContentVersion", "external_id_field": "Pocket_Document_Id__c" },
"totvs": { "entity": "legal_attachment", "external_id": "pj_doc_01J9DOC005" }
}
- Case cover and process synchronization:
{
"event_type": "process.synchronized",
"pocket_event_id": "pj_evt_01J9PROC006",
"process": { "process_key": "00123456720268190001", "cover_id": "pj_cover_01J9PROC006", "case_number": "0012345-67.2026.8.19.0001", "parties": [{ "name": "Example Company", "role": "claimant" }], "lawyers": [{ "name": "Example Law Firm", "role": "external_counsel" }], "instances": ["first"] },
"salesforce": { "object": "Matter__c", "external_id_field": "Process_Key__c" },
"totvs": { "entity": "legal_process", "external_id": "00123456720268190001" }
}
- LLM summary attached to the same event:
{
"event_type": "publication.enriched",
"pocket_event_id": "pj_evt_01J9AI007",
"publication_id": "pj_pub_01J9PUB001",
"summary": { "text": "The court ordered the party to respond within 10 business days.", "language": "en", "provider": "approved_llm", "model": "configured-model", "confidence": 0.92, "generated_at": "2026-10-22T14:02:00-03:00" },
"deadline_ids": ["pj_dead_01J9DL003"],
"salesforce": { "summary_field": "AI_Summary__c", "confidence_field": "AI_Confidence__c" },
"totvs": { "summary_field": "integration_summary" }
}
- Collaborative comment:
{
"event_type": "comment.created",
"pocket_event_id": "pj_evt_01J9COM008",
"process_key": "00123456720268190001",
"comment": { "comment_id": "pj_com_01J9COM008", "author_id": "user_482", "text": "Please confirm the response strategy with the business owner.", "created_at": "2026-10-22T15:20:00-03:00", "mentions": ["user_221"] },
"parent_publication_id": "pj_pub_01J9PUB001",
"salesforce": { "object": "CaseComment", "external_id_field": "Pocket_Comment_Id__c" },
"totvs": { "entity": "legal_comment", "external_id": "pj_com_01J9COM008" }
}
- Google Calendar or Outlook scheduling request:
{
"event_type": "deadline.calendar_requested",
"pocket_event_id": "pj_evt_01J9CAL009",
"deadline_id": "pj_dead_01J9DL003",
"calendar": { "summary": "Response deadline: case 0012345-67.2026.8.19.0001", "description": "Source: legal publication. Review the original notice before filing.", "start": "2026-11-03T09:00:00-03:00", "end": "2026-11-03T09:30:00-03:00", "timezone": "America/Sao_Paulo", "reminders": [1440, 120] },
"deduplication_key": "pj_dead_01J9DL003:calendar:2026-11-03",
"google_calendar": { "operation": "events.insert" },
"outlook": { "operation": "create_event" }
}
- Chain-of-custody audit event:
{
"event_type": "audit.custody_recorded",
"pocket_event_id": "pj_evt_01J9AUD010",
"object_type": "publication",
"object_id": "pj_pub_01J9PUB001",
"custody": { "source_hash": "sha256-source-example", "payload_hash": "sha256-payload-example", "previous_hash": "sha256-previous-example", "captured_at": "2026-10-21T18:42:11-03:00", "processed_at": "2026-10-22T14:05:12-03:00", "actor": "system", "schema_version": "1.2" },
"salesforce": { "object": "Integration_Audit__c", "external_id_field": "Pocket_Event_Id__c" },
"totvs": { "entity": "integration_audit", "external_id": "pj_evt_01J9AUD010" }
}
These payloads are deliberately separate because each object has a different lifecycle. A deadline can be corrected without rewriting the publication, and a comment can be added without generating another process. That separation reduces retrabalho and makes retries safer.
How to handle timestamps, chain of custody, and calendars
Legal integrations should distinguish at least four times: when the event occurred at the court or journal, when the source was captured, when the system transformed it, and when the destination accepted it. Store all four when available, using ISO 8601 or RFC 3339 values with an explicit offset and a separate IANA time zone such as America/Sao_Paulo.
A deadline is not simply a date copied from a model response. It may depend on business days, court rules, suspension periods, publication timing, and the interpretation of the source text. The payload should therefore include the extracted due date, the stated period, the source sentence, confidence, extraction version, and review status.
For chain of custody, calculate a cryptographic hash for the original document or text, the normalized payload, and any later transformation that materially changes the content. Store the hash, previous hash, actor, timestamp, schema version, and event ID in an append-only audit record. A hash does not prove that a source was truthful, but it can show whether the stored content changed after capture.
Calendar integrations should create a predictable, idempotent event. Use the deadline ID as the external reference, set the correct Brazilian time zone, include a link back to the publication, and create reminders that fit the team’s workflow. Google Calendar’s official events.insert documentation explains the event creation fields and operation used in the example above.
Avoid treating a calendar entry as the system of record. Google Calendar or Outlook should help people act on a deadline, while the legal platform remains the authoritative location for the publication, document, extracted reasoning, and audit history. If a deadline changes, update the calendar event through its stored destination ID instead of creating a second appointment.
Mapping legal publication data to Salesforce and TOTVS
Salesforce integrations usually benefit from external ID fields and upsert operations. A custom Matter__c can represent the process, Legal_Publication__c can represent the source event, Legal_Deadline__c can represent an extracted obligation, and ContentVersion can hold documents where the org’s storage and security policies permit it. The Salesforce REST API documentation is the appropriate starting point for confirming authentication, resources, and request behavior.
A useful Salesforce mapping table might look like this: process_key to Process_Key__c, case_number to Case_Number__c, court to Court__c, publication_date to Publication_Date__c, captured_at to Captured_At__c, source_url to Source_URL__c, pocket_event_id to Pocket_Event_Id__c, and custody_hash to Custody_Hash__c. Keep source text in a long-text field and avoid using the summary as a substitute for the original.
TOTVS requires more careful discovery because the available entities and fields depend on the product, version, module, and customer configuration. Map the canonical process key to the system’s external reference, the publication to a legal event or custom entity, the deadline to a commitment or activity, and the document to the supported attachment mechanism.
The integration should keep a mapping registry outside the payload. That registry can define destination field, data type, transformation, required status, maximum length, and fallback behavior. For example, a long publication may need a full document link in Salesforce or TOTVS while a shortened preview is stored in a restricted text field.
Authentication headers should never be mixed with business data. A typical request can use Authorization: Bearer token, Content-Type: application/json, X-Request-ID for tracing, and X-Signature for an HMAC verification scheme agreed by both parties. Rotate secrets, restrict scopes, and redact tokens from logs.
Where Pocket Jurídico fits in the integration workflow
- ✓Pocket Jurídico monitors more than 490 journals and courts, capturing publications and procedural movements so teams can feed their operational systems without repeating manual court checks.
- ✓When a new publication arrives, the platform can identify and validate the process across instances, capture the cover, history, movements, and documents, and provide a broader process context for downstream mapping.
- ✓Publications can arrive before their formal publication dates, giving legal teams more time to assess extracted deadlines and decide whether a CRM task, ERP commitment, or calendar event should be created.
- ✓AI connections such as ChatGPT, Claude, and Gemini can support summaries, deadline extraction, and questions inside the publication workflow. Derived AI data should still carry confidence, model, version, and human review fields.
- ✓Teams can use the API, email exports, spreadsheets, calendar connections, or MCP-based AI connectors according to their technical maturity. A phased rollout often begins with publication delivery and later adds deadlines, documents, comments, and enrichment.
- ✓Comments and alerts keep the discussion beside the publication instead of scattering decisions across email threads and parallel spreadsheets. When comments are synchronized, use a separate comment ID and preserve the original author and timestamp.
- ✓The cost model is based on the volume of monitored names and terms, which can help organizations plan integration scope according to monitoring demand rather than the number of destination records.
Common integration mistakes and governance controls
The most damaging mistake is creating a process record whenever a webhook arrives. A webhook describes an event, not necessarily a new case. Resolve the normalized process key first, then upsert the publication and its children.
Another frequent error is sending only a summary to the ERP or CRM. Summaries improve triage, but they are derived interpretations. Keep the original content, document reference, source timestamp, hash, and extraction metadata so a lawyer can verify what the system received.
Do not calculate legal deadlines solely from a calendar date without preserving the source basis. If the system cannot confidently determine whether the period is counted in business days or calendar days, set the status to review and notify the responsible team instead of presenting an uncertain date as final.
Privacy governance must cover parties, lawyers, documents, comments, and AI processing. Apply least-privilege access, retention rules, encryption, audit logging, and tenant separation. The Brazilian General Data Protection Law should be considered alongside contractual duties, professional secrecy, and the organization’s internal security policies.
Finally, measure integration quality with operational metrics. Track duplicate process creation, duplicate publication rate, unmatched process rate, failed document uploads, deadline synchronization latency, and the percentage of AI extractions reviewed. These measures show whether the integration is reducing work or merely moving it to a different queue.
Frequently Asked Questions
What minimum fields should be sent from legal publication monitoring to an ERP or CRM?▼
At minimum, send a stable event ID, process key, case number, court, instance, event type, publication date, capture timestamp, original content or document link, and source URL. Add a hash, destination mapping status, and parent-child identifiers when auditability matters. If a deadline is extracted, include its own ID, due date, counting method, time zone, source text, confidence, and review status.
How can I prevent duplicate processes when synchronizing publications with Salesforce or TOTVS?▼
Separate process identity from publication identity. Normalize the case number and combine it with court and instance to create a process key, then use the Pocket Jurídico cover identifier and event ID as external keys for upserts. Add a content hash as a secondary control, but do not use the publication title alone because identical titles can occur across many events.
How should multiple deadlines be represented in a JSON payload?▼
Represent deadlines as an array of child objects, with one unique deadline ID for each obligation. Each object should include type, due date, business-day or calendar-day basis, time zone, source text, confidence, and review status. In Salesforce, each item can become a related task or custom deadline record, while in TOTVS it can map to the configured commitment or activity entity.
How should timestamps and time zones be handled in legal integration payloads?▼
Use RFC 3339 or ISO 8601 timestamps with an explicit offset, such as 2026-10-22T14:30:00-03:00, and store the IANA time zone separately when the destination supports it. Keep event, capture, processing, and destination acceptance times distinct. Calendar events should use America/Sao_Paulo when appropriate and should never rely on an unspecified server time zone.
What is a chain of custody in a legal publication API payload?▼
A chain of custody is a chronological record showing how source content was captured, stored, transformed, and delivered. Useful fields include source and payload hashes, previous hash, event ID, actor, timestamps, schema version, and document metadata. It helps demonstrate that the stored record was not silently changed, although it does not independently prove the truthfulness of the original source.
Can an AI summary and extracted deadline be sent in the same event?▼
Yes, provided the original publication remains the primary source and the AI output is clearly marked as derived data. Include the provider, model or configuration, prompt version, generation time, confidence, source span, and human review status. The summary and deadline can reference the same publication ID while retaining separate IDs for later correction or approval.
Should Google Calendar be the system of record for legal deadlines?▼
Usually, no. Calendar tools are useful for reminders, ownership, and daily planning, but the legal publication platform or matter system should retain the original notice, documents, extraction rationale, and audit history. Store the destination calendar event ID so a corrected deadline can update the existing event instead of creating a duplicate.
How do Salesforce and TOTVS differ when receiving legal publication data?▼
Salesforce commonly uses configurable objects, external ID fields, and REST upserts, while TOTVS mappings depend heavily on the product, version, module, and customer configuration. The safest design uses one canonical legal event model and a separate transformation registry for each destination. This prevents destination-specific labels from changing the meaning of the original publication.