Tyler Odyssey / Enterprise Justice (API)

This integration connects Tyler Technologies' Odyssey or Enterprise Justice to eCourtDate through the TranslationBridge External Service API. Every hour, eCourtDate reads upcoming hearings from Odyssey, with the case parties on each hearing's case and their phone numbers and email addresses, and keeps the agency's Events, Clients, and Contacts up to date so hearing reminders go out.

Item	Detail
Direction	Odyssey to eCourtDate. The optional outcome push also files a report on the Odyssey case.
Protocol	SOAP over HTTPS, authenticated with a WS-Security username and password.
Schedule	Every hour, run by eCourtDate. Nothing is scheduled in Odyssey.
Hearing window	Today through 30 days ahead (configurable).
Odyssey API messages	FindHearings, LoadCase, LoadParty, and LoadCourtSession. The outcome push also needs AddDocument and AddCaseEvent.
Configured in	The Integrations page of the eCourtDate Console.

How It Works

The integration runs as three processes:

Process	When	Direction	What it does
Sync	Every hour	Odyssey to eCourtDate	Imports upcoming hearings, the case parties on each case, and their phone numbers and email addresses. Creates and updates Events, Clients, and Contacts.
Reconcile	Every hour	Odyssey to eCourtDate	Updates Events whose hearing changed and closes Events whose hearing was removed from the docket.
Outcome push (optional)	Once a day	eCourtDate to Odyssey	Files an outcome report PDF on the Odyssey case and links it with a case event, of the type the court's outcome rules choose.

Sync

1. FindHearings runs for all configured NodeIDs and returns the hearings from today to the end of the hearing window. If a search matches more hearings than MAX RESULTS, eCourtDate splits the date range and searches each part again, so no hearing is left out.
2. Deleted hearings are included, so their Events get the status deleted. Cancelled hearings are left out by default, because Odyssey returns them with no mark that they are cancelled.
3. LoadCourtSession runs once per court session. The session type and description decide whether a hearing is virtual.
4. LoadCase runs once per case and keeps the current case parties whose connection type the integration imports: by default a defendant or respondent type (for example DEF, CODEF, or RESP), or the types listed under Parties. A case party that Odyssey removed from the case is not kept.
5. LoadParty runs once per kept case party to read their phone numbers and email addresses.
6. eCourtDate creates an Event for each new hearing and updates Events whose hearing changed. It adds each case party as a Client linked to the Event, and adds their phone numbers and email addresses as Contacts.
7. For each new or changed Event and Client, eCourtDate queues its flow messages and auto messages. See Flows and Auto Messages.

Reconcile

1. FindHearings runs again for the same NodeIDs and date range.
2. Each hearing is compared field by field with its Event (date, time, end time, status, type, code, description, case number, judge name, location notes, and virtual), and only changed fields are written.
3. Events this integration created whose hearing is no longer returned are closed (see Removed hearings). Events are never deleted.
4. If a FindHearings call fails, or Odyssey returns only part of a day, the run updates Events but closes none. A hearing that eCourtDate did not see is not a removed hearing.

Reconcile never creates Events and never changes Clients or Contacts; new hearings and case parties arrive with the next sync.

In both processes, a hearing that has not changed writes nothing and queues no messages, so running every hour does not send duplicate reminders. The outcome push is described in Optional: Outcome Push to Odyssey.

Step 1: Create an Enterprise Justice User

Create a dedicated Enterprise Justice User for eCourtDate. Every API call is made as this user. It exists only for API calls, so do not give it ordinary user rights or roles unless Tyler or the organization's security policy requires them.

Configuration path: Configure > System > Security > Users > Odyssey Users

Record three values:

Value	What it is
Username	Sent with the Password in the WS-Security header of every request.
Password	The Username's password.
UserID	Odyssey's internal numeric identifier for the user, sent inside every API transaction. It is a different value from the Username.

Step 2: Configure API Message Security

Authorize the Enterprise Justice User for each API message the integration sends. Menu names can vary by Odyssey or Enterprise Justice release.

Configuration path: Configure > Integrations > Codes > TranslationBridge > APIMessageSecurityConfigurations > System

Message	Required	Used for
FindHearings	Yes	Finding upcoming hearings on the configured nodes. The outcome push also uses it to find an Event's case when eCourtDate has no stored case reference for it.
LoadCase	Yes	Reading the case parties on each case.
LoadParty	Yes	Reading each case party's phone numbers and email addresses.
LoadCourtSession	Yes	Reading the session type and description, used to mark virtual hearings.
AddDocument	Outcome push only	Filing the outcome report PDF on the case.
AddCaseEvent	Outcome push only	Adding the case event that links to that document.

A message that is not authorized fails with an error from Odyssey, which appears in the sync report.

Step 3: Allow Network Access

eCourtDate's servers call the TranslationBridge External Service over HTTPS (port 443 unless the endpoint URL names another port). Requests send the HTTP header User-Agent: ecdapi, which identifies them in web server and firewall logs.

If the endpoint is behind a firewall, VPN, or IP allowlist, open a support ticket in the Console using the Help button in the bottom-right corner to get the IP addresses eCourtDate connects from, and allow them for both the Test and Production endpoints.

Step 4: Collect the Connection Values

Collect these values separately for the Odyssey Test and Production environments; each normally has its own endpoint, Enterprise Justice User, System Environment, and NodeIDs. The table lists them in the order the Console asks for them.

Value	Console field	Description
Server URL	API BASE ENDPOINT	The scheme and host of the TranslationBridge server, for example https://odyssey-test.example.gov.
Service path	API ENDPOINT PATH	The path of the service on that server. Leave blank for the standard path, /ExternalWebService/TranslationBridgeExternalService.asmx.
Username	API USERNAME	From Step 1.
Password	API PASSWORD	From Step 1.
UserID	API USER ID	From Step 1.
System Environment	SYSTEM ENVIRONMENT	The exact SystemEnvironment value that identifies the Odyssey environment receiving the request, for example ODYSSEYTEST. The Odyssey administrator provides it.
Search NodeIDs	API NODE IDS	The NodeID of every court node whose hearings should be imported, comma separated, for example 100, 200. Nodes are the only filter: every hearing on a listed node is imported, whatever its case type or hearing type. If left blank, eCourtDate searches every node the Enterprise Justice User can see, so list them.

Step 5: Configure the Integration in eCourtDate

Set up and test against the Odyssey Test environment and an eCourtDate staging agency first. See Staging and production. This step needs a Console user with super admin access to the agency.

1. In the Console, open Integrations and add a TylerOdyssey integration in the staging region.
2. Choose the staging agency as the Default Agency. Hearings sync into that one agency; another agency needs its own integration.
3. Enter the Test values from Step 4. Type the password into the Console form; never send it in a support ticket or email.
4. Enter at least one address in NOTIFY COMPLETE so run reports are emailed.
5. Save. The first sync runs at the next hourly run, and then every hour.

The other settings have defaults that suit most courts:

Console field	Default	What it does
EVENT DAYS FUTURE	30	How many days ahead, from today, to look for hearings.
MAX RESULTS	500	The most hearings one FindHearings call returns. When a search matches more, eCourtDate splits the date range into smaller searches, so no hearing is left out.
VIRTUAL SESSION TYPES	Blank	Odyssey session type codes that always mark a hearing as virtual. Keyword matching on the session type, session description, and hearing type runs as well.
EVENT FLOW	Automatic	The flow for a new hearing whose type matches no flow's Flow Reference. Automatic uses a flow whose types list the hearing type, then the agency's default flow. See How a hearing gets its flow.
EVENT LOCATION	Automatic	The location for a new Event whose Odyssey courtroom matches no location. eCourtDate first looks for a location whose reference or name is the courtroom code or description. Automatic uses the agency's default location.
EVENT PORTAL	Automatic	The portal for each new Event. Automatic uses the portal of the Event's flow, then the agency's default portal. A sync never changes the portal of an Event it already created.
INCLUDE CANCELLED HEARINGS	Excluded	Keep excluded. Odyssey returns a cancelled hearing with no mark that it is cancelled, so an included one syncs as scheduled and its reminders continue. When excluded, the hearing drops out of the results and the reconcile closes its Event.
INCLUDE DELETED HEARINGS	Included	Keep included. Odyssey marks a deleted hearing as deleted, so its Event gets the status deleted. A hearing deleted before its first sync is not created.

Parties

The Parties section of the integration chooses which case parties become Clients. Each row is an Odyssey connection type code and the client type its parties are created with. A case party is imported when one of its current connections on the case has a listed code. Codes are the court's Party Extended Connections codes, matched exactly, ignoring case; the Odyssey administrator can provide the list.

Party types	Who is imported	Client type of a new Client
None listed (the default)	Case parties whose connection type is a defendant or respondent code (DEF, CODEF, RESP, and the like) or contains Defendant or Respondent	defendant
One or more listed	Only case parties whose connection type is a listed code	The row's client type. A blank client type is defendant for a defendant or respondent code, otherwise the code in lower case.

A listed type replaces the default rather than adding to it, so a court that wants plaintiffs as well as defendants lists both, for example DEF, CODEF, and PLTF as plaintiff. Add defendant and respondent codes adds the default codes as rows. The client type is set when the Client is created; a sync never changes it, and a Client created before the list changed keeps its type.

Attorneys are not case parties in Odyssey, so no party type imports them.

Step 6: Validate, Then Go Live

After the first run, open the sync report emailed to the NOTIFY COMPLETE addresses. Its parameters show the endpoint, Site ID (the System Environment), nodes, date window, and party types. They also show the event flow, location, and portal that a hearing gets when nothing more specific matches. Below them are the counts and any errors. Then check in the staging agency that:

• The expected hearings are there, and only from the intended courts.
• Case numbers, dates, times, judges, and locations are correct. Courtrooms With No Location in the report lists the courtrooms that need a location.
• The expected Clients are linked to each Event, with the expected client types, and with their phone numbers and email addresses as Contacts.
• Every Event has the correct flow. A report event flow of None means that a hearing whose type matches no flow gets no flow, and its Clients get no flow messages.
• Virtual hearings are marked virtual.
• A hearing rescheduled in Odyssey Test shows the new date or time after the next hourly run.
• Statuses for closed hearings stop messages (see Hearing statuses).

Then set up flows and auto messages and review the generated messages. See Flows and Auto Messages and How to Create a Flow.

To go live, repeat Steps 1 through 5 with the Production values in a TylerOdyssey integration for the production agency. Copy flows, statuses, and templates from the staging agency; see How to copy settings from one agency to another.

What Is Imported

Odyssey data	eCourtDate record
Hearing	One Event for each hearing, matched on Odyssey's HearingID
Date, start time, and end time of the hearing's current setting	Event date, time, and end time
Hearing type	Event type
Setting result, or deleted flag	Event status
Case number	Event case number
Case style	Event description
Case category	Event code
Judge	Event judge name
Courtroom	Event location notes. A new Event also gets the location whose reference or name is the courtroom code or description.
Session type and description	Event virtual flag
Current case party with an imported connection type (by default a defendant or respondent; see Parties)	Client, matched on Odyssey's PartyID, linked to the Event
Case party phone numbers (home, work, cell, and fax)	Text Contacts
Case party email addresses	Email Contacts

Odyssey keeps each earlier setting of a rescheduled hearing. eCourtDate uses the hearing's current setting: the earliest setting from today on that has no result. If every setting from today on has a result, it uses the earliest of them.

A new Client gets the case party's first, middle, and last name (or the name of a business party), the client type for its connection type (defendant by default; see Parties), the status active, and English as its language, since Odyssey's preferred language is not imported. Clients get English message templates unless the language is changed in eCourtDate. Contacts are added with notifications on.

A Client that already has the same Odyssey PartyID is reused. Odyssey owns the Client's names: a name changed in Odyssey is changed on the Client at the next sync, and a blank name in Odyssey never clears a name. The status, type, and language are set only when the Client is created. A phone number or email address the Client already has is not added again, and Contacts are never removed: a number corrected in Odyssey is added alongside the old one, which stays active until it is changed in eCourtDate.

When Odyssey moves a hearing to another courtroom, eCourtDate chooses the Event's location again. Otherwise, a location set in eCourtDate stays.

Event description, judge name, and location notes are cut to 50 characters. Case parties with a connection type that is not imported are left out, as are case parties that Odyssey removed from the case. Case records, charges, fees, warrants, bonds, attorneys, and Odyssey case events are not imported.

Hearing statuses

An Event's status is the setting result Odyssey reports for the hearing, as Odyssey words it (for example Held, Continued, or FTA; the values are site-specific). A hearing Odyssey flags as deleted gets the status deleted, and a hearing with no result is scheduled. Whether a status sends messages is set per status in eCourtDate, so create a status for each Odyssey setting result that should stop reminders and turn messages off for it. A setting result used for missed-court messaging or reporting also needs a matching status. See How to manage statuses and How to disable messages based on status.

Removed hearings

A hearing can also disappear from Odyssey's results entirely. Each hour, eCourtDate closes the Events this integration created whose hearing is no longer returned, by setting their status to cancelled. For that to stop reminders, the agency needs a cancelled status with messages turned off.

Closing is limited so that an incomplete response from Odyssey cannot cancel a whole docket:

• Nothing is closed when Odyssey returns no hearings, a FindHearings call fails, or Odyssey returns only part of a day.
• Only Events dated from tomorrow to one day before the end of the hearing window are closed, so a hearing removed for today is not closed automatically.
• No Events are closed in a run that would close more than 30% of the open Events it tracks (once it tracks at least 10). The run's report shows the close was skipped.
• There is no limit on the number of Events one run closes, unless RECONCILE MAX sets one.
• A closed Event whose hearing reappears in Odyssey is reopened with its current status.

The Console's Reconcile Settings card changes these: RECONCILE STATUS (default cancelled), RECONCILE MAX (default blank, no limit), RECONCILE MIN TRACKED (default 10), and RECONCILE RATIO (default 0.30).

Closing an Event is a status change, so it can send an event_status auto message. See Flows and Auto Messages.

Flows and Auto Messages

The sync imports records. It does not write messages. Flows and auto messages decide which messages each Client gets. For how flows and auto messages work in all of eCourtDate, see Messaging Concepts.

	Flow	Auto message
Applies to	One Event. Each Event has one flow.	The agency. It applies to each record that meets its trigger.
Sends	A sequence of messages timed from the hearing, for example 7 days, 3 days, and 1 day before.	One message when its trigger occurs, for example when an Event is created.
When the hearing changes	The unsent messages are made again from the flow.	It is not sent again.

A flow can also have a message that sends when the Event is created. If the agency also has an event_created auto message, each Client gets both messages. Use one or the other.

How a hearing gets its flow

When the sync creates an Event, eCourtDate tries these steps in order. The first step that finds a flow decides the Event's flow.

1. Flow Reference: the flow whose Flow Reference is the Odyssey hearing type code, for example ARR. The code must match the whole reference.
2. EVENT FLOW: the flow set on the integration in the Console.
3. Flow types: a flow whose types list (types) contains the hearing type code. If Odyssey gives no hearing type, eCourtDate uses the case style, then the status. This step runs only when EVENT FLOW is Automatic.
4. Default flow: the agency's default flow.

These rules apply to every step:

• Payment, warrant, and case flows are never used.
• Deleted and archived flows are never used.
• When two flows match at the same step, eCourtDate uses the oldest flow.
• An Event with no flow gets no flow messages. A report event flow of None shows that this can occur.

To send each hearing type to its own flow, set the flow's Flow Reference to the hearing type code. A flow has one Flow Reference. To send several hearing types to one flow, list their codes in the flow's types list and keep EVENT FLOW on Automatic. The types list match finds the code anywhere in the list, so a short code such as PT also matches a list that contains PTC. Use the Flow Reference for an exact match.

When a hearing changes

• A sync never changes a flow that an Event already has. This is also true when the hearing type changes in Odyssey, or when a user changed the flow in eCourtDate. To change it, change the flow on the Event.
• An existing Event with no flow gets one at the next sync, with the steps in How a hearing gets its flow.
• After each new or changed Event, eCourtDate removes the Event's unsent flow messages and makes them again from its flow, for each linked Client. Messages already sent and auto messages do not change.
• A status, location, or Client status with messages turned off stops the Event's flow messages.
• A hearing that did not change writes nothing and queues nothing.

Auto messages from the sync

The sync queues an auto message only when the agency has an auto message with that trigger.

Trigger	When the sync uses it	Sent to
event_created	The sync creates an Event.	Each Client linked to the Event.
event_status	The sync creates an Event, and each time the Event's status changes. A reconcile close is a status change.	Each Client linked to the Event.
client_created	The sync creates a Client.	The Client.
client_status	The sync creates a Client, with the status active.	The Client.
client_updated	Odyssey changes a Client's name, or gives a Client a new phone number or email address.	The Client.

The sync does not use event_appeared, because Odyssey does not report appearances. It does not use client_group, because the sync sets no group.

The Enabled Trigger of an auto message works differently for each trigger:

• event_created: When Enabled Trigger is blank, the auto message sends for every new Event. When it names a status, the auto message sends only for a new Event with that status. For example, scheduled is the status of a hearing with no result.
• event_status and client_status: Enabled Trigger names the status that sends the auto message. An auto message with a blank Enabled Trigger never sends for these triggers.

These rules also apply:

• An Event auto message is sent once to each contact for each Event. A later sync does not send it again.
• A Client auto message is sent once to each contact. A second name change does not send a second client_updated message.
• Archived Clients get no auto messages from the sync.
• When Odyssey adds a case party to a case after its hearing synced, the new Client gets the Event's flow messages. The new Client gets no event_created auto message, because the Event is not new. The other Clients' messages do not change.
• One trigger sends up to 10 auto messages to a Client. Only auto messages whose filters match the Client and Event count toward the 10.

Sync Reports

Each NOTIFY COMPLETE address receives an email with a PDF report, titled "Odyssey Sync Report" with the agency name, after any run that created, updated, or closed Events, added Clients or Contacts, or hit an error. A run with nothing new sends no email.

The report lists the run's parameters, counts of hearings returned and Events created, updated, and closed, and each error with the Odyssey message that failed and the error text Odyssey returned. It lists case numbers, but no names, phone numbers, or email addresses.

Optional: Outcome Push to Odyssey

The outcome push is off by default. When enabled, it runs once a day: for each Event this integration created, once its messages have been sent and the settle window (4 hours, or longer if set) has passed so delivery results are in, eCourtDate files one "eCourtDate Outcome Report" PDF on the Odyssey case (AddDocument) and adds a case event that links to it (AddCaseEvent). The report states whether each Client was reached, lists each message with its delivery status, and includes any replies. Upcoming hearings are included, so the court usually sees before the hearing whether its Clients were reached. Each Event gets one report; an Event with no messages sent gets none.

The court decides how each report is filed. Outcome rules choose the case event type, document type, comment, and document name for each hearing, or say not to file a report. Hearings that no rule decides use the defaults.

To enable it:

1. Authorize the Enterprise Justice User for AddDocument and AddCaseEvent (Step 2).
2. Get the site-specific user codes from the Odyssey administrator: each case event type to use, and the document type.
3. In the Console, open the integration and find the Outcome Push Settings card.
4. Enter the codes that most hearings use in DEFAULT CASE EVENT TYPE and DEFAULT DOCUMENT TYPE.
5. Add outcome rules for the hearings that use other codes, or that get no report.
6. Use Test a hearing to check the result for some hearing types.
7. Set OUTCOME PUSH to Enabled, and save.
8. Confirm on the Odyssey Test environment that each report and its case event appear on the case. Then enable the push in Production.

The Console does not save settings that the outcome push cannot use. It names the problem, for example "Rule 2: enter the case event type to file the report as.", and keeps the values that were typed. Outcome push cannot be enabled until a default case event type is set, or a rule files the report.

While it is enabled, the NOTIFY COMPLETE addresses also receive a short outcome push summary after each daily run.

Outcome rules

Outcome rules let a court file each report under the case event type that matches the hearing. For example, a court can file a virtual non-jury trial as NOVNJT and an in-person non-jury trial as NNJT. A court can also choose not to file a report when no party was reached.

eCourtDate tries the rules from the top of the list. The first rule whose conditions are all true decides what happens to the report:

• File the report: the report is filed under the rule's Case event type. A rule can also set its own Document type, Comment, and Document name. A blank field uses the default.
• Do not file: no report is filed for the hearing in this run. The hearing is decided again in the next run, so a delivery result that arrives later can change the outcome.

A rule with no conditions applies to every hearing that gets to it. A hearing that no rule decides is filed under DEFAULT CASE EVENT TYPE and DEFAULT DOCUMENT TYPE. If no default case event type is set, the hearing gets no report, and the outcome push summary lists its hearing type and format under "Hearings with no case event type".

Each condition compares one field of the hearing:

Field	What it holds
Hearing type	The Odyssey hearing type code, for example DEBTCLMNJT.
Format	In person or Virtual, from the Event's virtual flag.
Outcome	Parties reached or Parties not reached, the result shown at the top of the report. The parties were reached when at least one message was confirmed delivered or opened.
Case category	The Odyssey case category.
Case number	The Odyssey case number.
Judge	The judge name.
Location	The location notes.
Hearing status	The Odyssey setting result, for example Held or Continued.

A condition uses one of these comparisons:

Comparison	True when
is one of	The field equals one of the values.
is not one of	The field equals none of the values, or the field is blank.
starts with	The field starts with one of the values.
does not start with	The field starts with none of the values, or the field is blank.

Separate values with commas, for example DEBTCLMNJT, SMCLMNJT, EVICTNJT. Comparisons ignore uppercase and lowercase. A value must match the whole field, so HEAR does not match HEARWOGARN.

To add a rule:

1. Select Add rule. The rule is added at the bottom of the list.
2. Enter a Name that describes the rule.
3. In When it applies, select File the report or Do not file.
4. Select Add condition for each condition, then select the field, the comparison, and the values.
5. For a rule that files the report, enter the Case event type.
6. Move the rule to its position with the move buttons. A rule that must apply first, such as a Do not file rule, goes at the top.
7. Save the integration.

A rule can have up to 10 conditions, and a condition up to 100 values. An integration can have up to 100 rules. Case event types and document types cannot contain spaces.

Example

These example rules use sample codes. Each court has its own codes.

Rule	Conditions	When it applies	Case event type
1. Parties not reached	Outcome is one of Parties not reached	Do not file
2. Virtual non-jury trials	Hearing type is one of DEBTCLMNJT, SMCLMNJT, EVICTNJT, and Format is one of Virtual	File the report	NOVNJT
3. Non-jury trials	Hearing type is one of DEBTCLMNJT, SMCLMNJT, EVICTNJT	File the report	NNJT
4. Misdemeanor special hearings	Hearing type is one of SH, and Case number starts with JP01-25-M	File the report	LTTR

With DEFAULT CASE EVENT TYPE set to NTHEAR, the rules give these results:

Hearing	Result
DEBTCLMNJT, virtual, parties reached	Filed as NOVNJT by rule 2.
DEBTCLMNJT, in person, parties reached	Filed as NNJT by rule 3.
EVICTNJT, any format, parties not reached	Not filed, by rule 1.
SH, parties reached, on case JP01-25-M00028829	Filed as LTTR by rule 4.
PH, in person, parties reached	Filed as NTHEAR, the default.

Import a code list

A court that keeps its codes in a spreadsheet can make the rules from it. The Import a code list box takes one row for each hearing type, with three values:

1. The hearing type code.
2. The case event type for in-person hearings.
3. The case event type for virtual hearings (optional).

Separate the values with tabs or commas. Three columns copied from a spreadsheet are separated by tabs. A header row is skipped. For example:

Hearing type	In-person code	Virtual code
DEBTCLMJT	NTJT
DEBTCLMNJT	NNJT	NOVNJT
SMCLMNJT	NNJT	NOVNJT
PH	NTHEAR	NOVHR

To import the rows:

1. Enter DEFAULT CASE EVENT TYPE first.
2. Paste the rows into ROWS.
3. Select Add rules from rows.
4. Read the result, then review the new rules.
5. Add any other rules, for example a Do not file rule, and move them to their positions.
6. Save the integration.

The import makes one rule for each code. Hearing types with the same code share a rule. The rules for virtual codes come before the rules for in-person codes. A virtual hearing whose hearing type has no virtual code is filed under its in-person code. A hearing type whose in-person code is the default case event type needs no rule, because the default already files it.

The new rules are added below the rules already in the list. If a row has a problem, the import adds no rules and names each row to correct, for example "Line 4: codes cannot contain spaces."

Test a hearing

Test a hearing shows what the settings on the screen do with one hearing, before they are saved. Enter the hearing type, format, outcome, and the other fields, then select Test hearing. The result shows:

• The case event type and document type, and the rule that chose them, or the reason that no report is filed.
• The comment and the document name, with sample values for the counts of parties.

Comments and document names

DEFAULT COMMENT is the text on the case event. DEFAULT DOCUMENT NAME is the name of the PDF in Odyssey. A rule can set its own comment and document name. Both can use these tags:

Tag	Becomes
{hearing_date}	The hearing date, for example 10/14/2026.
{hearing_date_iso}	The hearing date, for example 2026-10-14.
{hearing_time}	The hearing time, for example 9:00 AM.
{hearing_type}	The Odyssey hearing type code.
{case_number}	The case number.
{outcome}	Parties reached, or Parties not reached.
{parties_reached}	The number of parties reached.
{parties_total}	The number of parties on the hearing.
{filed_date}	The date the report is filed, for example 10/6/2026.
{event_id}	The first 8 characters of the eCourtDate Event ID.

When these fields are blank, the comment is eCourtDate Outcome Report for the {hearing_date} hearing and the document name is eCourtDate-Outcome-{case_number}-{hearing_date_iso}-{event_id}.

In a document name, spaces and symbols become hyphens, and .pdf is added. A blank case number becomes case, and a blank date becomes undated. A comment can have up to 500 characters, and a document name up to 150.

Timing and report contents

Console field	Default	What it does
WAIT AFTER FIRST MESSAGE (HOURS)	4	How long the first message must be out before the report is filed, so that carriers can report delivery. From 4 to 168 hours.
LOOKBACK (DAYS)	10	How many days after the hearing date a hearing can still get its report. From 1 to 30 days.
MESSAGE TEXT	Included	When Left out, the report does not show the subject and text of the messages. The delivery details of each message stay in the report.
CLIENT REPLIES	Included	When Left out, the report does not show the text of replies. It shows the number of replies received.

Outcome push summary

After each daily run, the summary shows the counts of reports filed and not filed. Tables show:

• Reports filed: each rule, its case event type, and the number of hearings it filed. "Default" is the hearings filed with the defaults.
• Not filed by a rule: each Do not file rule and the number of hearings it stopped.
• Hearings with no case event type: each hearing type and format that no rule decided while no default case event type was set. Add a rule for these hearing types, or set a default.

The summary shows hearing types and counts. It does not show case numbers or names.

Troubleshooting

Start with the most recent sync report: it names the Odyssey message that failed and quotes Odyssey's error.

No sync report arrives. Check that NOTIFY COMPLETE holds a valid address. A run with nothing new sends no report.

Every request fails with an authentication error. Check API USERNAME and API PASSWORD, and that the password has not changed or expired in Odyssey. After a password change in Odyssey, update API PASSWORD straight away; requests fail until they match.

FindHearings fails, or fails for some nodes. Check first that the user is authorized for FindHearings in API Message Security, the most common cause. Then check SYSTEM ENVIRONMENT, API USER ID (the numeric UserID, not the Username), and that each NodeID in API NODE IDS is valid and visible to the user.

Hearings arrive but Clients or Contacts are missing. Check that the user is authorized for LoadCase and LoadParty. Only case parties with an imported connection type become Clients: defendants and respondents by default, or the types listed under Parties, which replace the default. The sync report's Party Types parameter shows the list the run used. A case party with no phone number or email address in Odyssey gets no Contacts.

Only some hearings arrive. Check API NODE IDS and EVENT DAYS FUTURE. Check that INCLUDE CANCELLED HEARINGS is excluded only when that is the intent. A search that Odyssey cut short is listed as a FindHearings error in the sync report.

Events exist but no messages are sent. Check that the Event has a flow, and that the flow has messages. Then check that the Clients have Contacts, and that the Event's status and location allow messages. See Flows and Auto Messages.

A hearing gets the wrong flow. Check the steps in How a hearing gets its flow. A flow whose Flow Reference is the hearing type code comes first, also before EVENT FLOW. A sync never changes the flow of an existing Event, so change it on the Event.

An auto message is not sent for a new hearing. Check that the auto message's trigger is event_created or event_status, and that its filters match the Client. For event_status, Enabled Trigger must name the Event's status. A Client that Odyssey adds to an existing hearing gets no event_created auto message.

Reminders continue for a cancelled hearing. Check that the Event's status (the Odyssey setting result, or cancelled for a removed hearing) has messages turned off. A hearing removed for today is not closed automatically.

The report says the close was skipped. More Events would have closed than the limits allow, which usually means Odyssey returned an incomplete list, for example after a change to API NODE IDS. Nothing was closed. Confirm the node list, and change the Reconcile Settings only if the closures are genuine.

An outcome report is not filed for a hearing. Use Test a hearing with the hearing's values. A Do not file rule can apply, or no rule and no default case event type applies. Hearings with no case event type are listed in the outcome push summary.

Odyssey rejects the case event type. The outcome push summary shows the error from AddCaseEvent. Get the correct code from the Odyssey administrator, then change the rule or the default. The PDF stored before the error stays in Odyssey, and the next run links it to the new case event. Odyssey does not get a second copy.

The outcome push summary says the settings need attention. No reports were filed. Open the integration in the Console and save it. The Console names each problem to correct.

eCourtDate cannot reach the endpoint. Confirm API BASE ENDPOINT and that eCourtDate's IP addresses are allowed (Step 3). A request with no response in 30 seconds fails and is retried on the next hourly run.

Related

• Tyler Odyssey / Enterprise Justice (SFTP): The report-based alternative, delivered nightly by SFTP.
• Console: Where integrations are configured.