Legal AI is complicated.
Connecting it shouldn't be.

InfoTrack's Model Context Protocol connects AI agents directly to court filing and service of process — no manual data entry, no portal-hopping, no chasing updates.

Get Started View Examples

How It Works

The busywork disappears.

InfoTrack Intelligence powers your AI agent. It reads documents, fills forms, and submits filings — automatically. For eFiling and service of process.

✓

Connect Once

Add InfoTrack MCP to your AI client. Simple OAuth 2.0 setup takes minutes.

✓

AI Does The Work

Your agent calls our tools. We extract data, calculate fees, and handle submissions.

✓

You Stay In Control

Review summaries, confirm submissions, track progress — all through your AI assistant.

What You'll Need

Simple requirements

🔗

Server URL

The InfoTrack MCP endpoint: https://search.infotrack.com/services/mcp-us-server/mcp

🔑

Client Credentials

Generate a ClientId and ClientSecret from the InfoTrack Partners Portal in under 2 minutes.

🔐

OAuth 2.0

Your MCP client handles authentication automatically. No complex setup required.

Getting Started

Connect to InfoTrack MCP

Getting Your Client Credentials

Access the Partners Portal

Navigate to partners.infotrack.com and log in to your account.

Generate Client Credentials

Create a new application and generate your ClientId and ClientSecret. Keep these secure.

OAuth 2.0 Authentication

Your MCP client will handle the OAuth 2.0 Authorization Code flow automatically, authenticating via auth.infotrack.com.

🔐

OAuth 2.0 Details

The MCP client handles the Authorization Code flow automatically. Token endpoint: https://auth.infotrack.com/oauth/token with scope api.

Configure Your MCP Client

Add the following to your ~/.cursor/mcp.json file:

mcp.json

{
  "mcpServers": {
    "infotrack": {
      "type": "http",
      "url": "https://search.infotrack.com/services/mcp-us-server/mcp",
      "authorization": {
        "type": "oauth2",
        "clientId": "<your-client-id>",
        "clientSecret": "<your-client-secret>",
        "tokenUrl": "https://auth.infotrack.com/oauth/token",
        "scope": "api"
      }
    }
  }
}

Add to your VS Code MCP settings:

settings.json

{
  "servers": {
    "infotrack": {
      "type": "http",
      "url": "https://search.infotrack.com/services/mcp-us-server/mcp",
      "authorization": {
        "type": "oauth2",
        "clientId": "<your-client-id>",
        "clientSecret": "<your-client-secret>",
        "tokenUrl": "https://auth.infotrack.com/oauth/token",
        "scope": "api"
      }
    }
  }
}

Configure Claude Desktop with your InfoTrack MCP server:

claude_desktop_config.json

{
  "mcpServers": {
    "infotrack": {
      "type": "http",
      "url": "https://search.infotrack.com/services/mcp-us-server/mcp",
      "authorization": {
        "type": "oauth2",
        "clientId": "<your-client-id>",
        "clientSecret": "<your-client-secret>",
        "tokenUrl": "https://auth.infotrack.com/oauth/token",
        "scope": "api"
      }
    }
  }
}

For other MCP-compatible clients, use this standard OAuth 2.0 configuration:

config.json

{
  "servers": {
    "infotrack": {
      "type": "http",
      "url": "https://search.infotrack.com/services/mcp-us-server/mcp",
      "authorization": {
        "type": "oauth2",
        "clientId": "<your-client-id>",
        "clientSecret": "<your-client-secret>",
        "tokenUrl": "https://auth.infotrack.com/oauth/token",
        "scope": "api"
      }
    }
  }
}

The MCP client will automatically handle the Authorization Code flow, prompting for user consent when needed.

What's Included

Everything litigation teams need to move a case forward

From filing and service to tracking — handled in one connected workflow.

⚖️

File court documents with confidence

Select the documents you want to file — one or many. InfoTrack prepares them to meet court requirements and submits them on your behalf.

✓ Court-ready formatting handled automatically
✓ Key details pulled from your documents
✓ Submissions completed in minutes, not hours

📬

Request service without the back-and-forth

Order service of process directly from your documents. We coordinate delivery and keep you informed as it progresses.

✓ Submit service requests in a few clicks
✓ Track status without chasing vendors
✓ Proof of service delivered when complete

Court Filing Tools

Tool	Description
`start_filing`	Initiates a new court filing with PDF documents. Extracts case information and calculates filing fees.
`continue_filing`	Continues an existing filing workflow with updated information or confirmation.

Service of Process Tools

Tool	Description
`initiate_serve_intake`	Primary intake tool. Collects missing matter/state via elicitation, requires uploaded documents, and runs extraction.
`initiate_serve`	Non-elicitation clients: prompts for matter/state and uploaded documents before calling `initiate_serve_with_details`.
`initiate_serve_with_details`	Non-elicitation clients: starts serving with matter/state/uploaded documents and returns recipients/options.
`add_documents_to_serve`	Adds uploaded documents to an existing serve context without restarting extraction.
`adjust_recipient_documents`	Updates document assignments for specific recipients.
`add_recipient`	Adds a recipient when automated extraction misses them; address is optional.
`update_recipient_address`	Updates a recipient's address and refreshes available options (can use PlaceId from `get_address_suggestions`).
`get_address_suggestions`	Returns ranked address suggestions for validation.
`prepare_skip_trace`	Estimates skip trace fees for recipients missing a valid address and attaches selections to the serve context.
`remove_skip_trace`	Removes one or more recipients from skip trace selections (does not remove recipients).
`select_serve_options`	Selects SLA and agency per recipient and returns fee estimates (does not place orders).
`add_attorney`	Selects a firm attorney (elicitation clients only; repeatable for multiple attorneys, required for CA cases).
`select_firm_contacts`	Selects firm contacts, then selects notification recipients from the chosen subset (elicitation clients only; at least one contact required).
`present_orders_for_confirmation`	Presents structured confirmation and creates orders (elicitation clients only).
`confirm_orders`	Confirms selections and creates orders after explicit chat confirmation (non-elicitation clients only).
`get_serve_order_details`	Retrieves details for an existing serve order.
`send_job_message`	Sends a message related to an existing serve job (after order creation/submission).
`cancel_serve_order`	Cancels an active serve order.
`remove_recipient`	Removes a recipient from the serve context (cannot remove the last recipient).
`get_orders_needing_attention`	Lists serve orders that require user action (proof review, messages, or follow-ups).

See It In Action

From documents to done in seconds

Watch how your AI agent handles a complete court filing workflow — extraction, validation, fee calculation, and submission — all without leaving the conversation.

⚖️

Complete Court Filing Flow

👤

You

I want to start a filing.

✨

AI Agent

To start a new eFiling, I'll need at least one PDF to upload. Please attach them in the prompt and then we can start!

👤

You

📄 NuecesCountyStandingOrders_1.pdf
📄 Original_Petition_for_Divorce.pdf
📄 Process_Request_Form.pdf
📄 Notice_of_Hearing.pdf

✨

AI Agent

Starting filing — Calculating filing fees...

✓ Called StartFiling with 4 PDFs

✓ Extracted case information from documents

✓ Calculated filing fees

✨

AI Agent

Please review the following summary for your filing:

Case information

• State: TX
• Matter: Smith v. Smith
• Location: Nueces County - District Court
• Case category: Family - Marriage Relationship
• Case type: Divorce No Children

Filings (4)

Filing #1: Petition

• Description: Nueces County Standing Order Regarding Children, Property And Conduct Of The Parties
• Lead document: NuecesCountyStandingOrders_1.pdf
○ Security level: Does not contain sensitive data

Filing #2: Petition

• Description: Original Petition For Divorce
• Lead document: Original_Petition_for_Divorce.pdf
○ Security level: Does not contain sensitive data

Filing #3: Application

• Description: Nueces County Process Request Sheet
• Lead document: Process_Request_Form.pdf
○ Security level: Does not contain sensitive data

Filing #4: Application

• Description: Notice Of Hearing
• Lead document: Notice_of_Hearing.pdf
○ Security level: Does not contain sensitive data

Case parties (3)

• Jane Smith
Party type: Petitioner
• John Smith
Party type: Respondent
• Sarah Johnson
Party type: Attorney

Filing information

• Filing party: Jane Smith
• Filer type: Not Applicable
• Payment account: Waiver

Filing fee summary

• Total cost: $70.00

Do you want to proceed with this filing in TX?

👤

You

Yes, submit the filing

✨

AI Agent

Submitting your filing...

✓ Called ContinueFiling with confirmation

✓ Filing submitted to court

✓ Confirmation received

✨

AI Agent

Filing Submitted Successfully

Your court filing has been submitted to Nueces County District Court.

Matter: Smith v. Smith

Documents: 4 PDFs submitted

Status: Pending court acceptance

Total Cost: $70.00

For Integrators

Receive order updates by webhook

If you submit filings through the InfoTrack MCP tools, you can receive order updates for every filing your users place — delivered to one endpoint, for all of your users, via a webhook.

On this page

Create a mapping Pass the mappingId Receive order updates Verifying deliveries Data model Order statuses Envelopes & filings Example receiver

①

Create a mapping

POST a ClientReference and a RetailerReference, and receive a mappingId.

②

Pass the `mappingId`

Hand it to the MCP filing tools so each filing is tagged with your reference.

③

Receive updates

Correlate every order update back to your user/matter using the RetailerReference.

InfoTrack calls your endpoint on each material order update — asynchronously and at-least-once. Verify the HMAC signature, dedupe on OrderId, and apply updates in SequenceNumber order.

Prerequisites

Access token. You already authenticate to InfoTrack to call the MCP tools. The same Authorization: Bearer <ACCESS TOKEN> is used to create a mapping.

Webhook endpoint and reference prefix. To receive order updates you must give us an endpoint to POST to, and InfoTrack will assign you a reference prefix (e.g. Novo_). We register both during onboarding. Every RetailerReference you send (see Step 1) must begin with this prefix — that's what routes your updates to your endpoint.

🔒

Deliveries are HMAC-signed

Every delivery carries an HMAC signature you can verify to confirm it genuinely came from InfoTrack and that the body wasn't tampered with — see Verifying deliveries.

Step 1 — Create a mapping

POST a ClientReference and a RetailerReference to the secure/api/v1/mapping endpoint.

POST /secure/api/v1/mapping

POST /secure/api/v1/mapping HTTP/1.1
Host: testsearch.infotrack.com
Authorization: Bearer <ACCESS TOKEN>
Content-Type: application/json

{
    "ClientReference": "01232X - Novo",
    "RetailerReference": "Novo_a1b2c3d4"
}

ClientReference is a visible identifier for the matter — commonly the matter name. The MCP tools use it as the matter name for the filing when one isn't supplied.
RetailerReference is your correlation token. It is not shown to the user; it follows the order through its lifecycle and comes back to you on every order update so you can match it to your user's data. It is stored on the order exactly as you send it (no transformation), and must begin with the reference prefix InfoTrack assigned you — e.g. Novo_a1b2c3d4, where Novo_ is your prefix.

Response

200 OK

{
    "Token": "54a93e46-a103-41e9-8139-db67efa6ad7a",
    "MappingId": "6c82af0c-01c6-467d-ab38-861ba8a919f3",
    "Url": "https://testintegrated.infotrack.com/menu?tokenId=…&mappingId=6c82af0c-01c6-467d-ab38-861ba8a919f3&retailerReference=Novo_a1b2c3d4"
}

You only need the MappingId. (The Token and Url are for browser-based integrated sessions and aren't needed here.)

A mappingId is reusable and carries a single RetailerReference. Most integrators create one mapping per matter and reuse its mappingId for every filing in that matter, but per-filing works too — it's up to you. There is no rate limit on creating mappings.

Example

CreateMappingAsync.cs

private static async Task<string> CreateMappingAsync(Uri host, string clientReference, string retailerReference, string accessToken)
{
    var matterDetail = new
    {
        ClientReference = clientReference,
        RetailerReference = retailerReference
    };

    using var client = new HttpClient();
    var builder = new UriBuilder(host) { Path = "secure/api/v1/mapping" };

    using var req = new HttpRequestMessage(HttpMethod.Post, builder.Uri);
    req.Headers.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);
    req.Content = new StringContent(JsonSerializer.Serialize(matterDetail), Encoding.UTF8, "application/json");

    using var resp = (await client.SendAsync(req)).EnsureSuccessStatusCode();
    var json = await resp.Content.ReadAsStringAsync();
    return JsonSerializer.Deserialize<Mapping>(json).MappingId;
}

createMapping.js

const createMappingAsync = async (host, clientReference, retailerReference, accessToken) => {
    const url = new URL(host);
    url.pathname = 'secure/api/v1/mapping';

    const resp = await fetch(url.toString(), {
        method: 'POST',
        headers: {
            'Authorization': `Bearer ${accessToken}`,
            'Content-Type': 'application/json'
        },
        body: JSON.stringify({ ClientReference: clientReference, RetailerReference: retailerReference })
    });

    if (!resp.ok) {
        throw Error(`Error (${resp.status}) ${resp.statusText}`);
    }

    const mapping = await resp.json();
    return mapping.MappingId;
};

Step 2 — Pass the `mappingId` to the MCP filing tools

The InfoTrack MCP filing tools accept an optional mappingId parameter:

Start_filing
Continue_filing
Add_documents_to_filing
Initiate_serve_courtny_with_details

Pass the MappingId from Step 1. When a mappingId is supplied, the MCP server resolves the mapping and applies:

its RetailerReference to the resulting order — this is what enables and correlates your order updates, and
its ClientReference as the matter name (when one isn't otherwise provided).

⚠️

No mappingId, no update

If you don't pass a mappingId, the order is placed without your retailer reference and no order update will be dispatched to your webhook.

Step 3 — Receive order updates

Whenever a material order update occurs, we POST the full order to your registered endpoint as JSON. As is common with webhooks, you may receive duplicate updates and they can arrive out of order — treat delivery as at-least-once: dedupe on OrderId and apply updates in SequenceNumber order. If your endpoint is briefly unreachable we retry the delivery a few times before parking it for recovery.

To tie an update back to the user and matter that placed it, read the RetailerReference (your prefixed value, e.g. Novo_a1b2c3d4) and the OrderId.

Verifying deliveries

Every request carries an HMAC signature so you can confirm a delivery genuinely came from InfoTrack and that the body wasn't tampered with. Verify it before trusting the payload — especially the status.

We sign each delivery with a shared secret provided to you during onboarding, and send:

Delivery request header

X-InfoTrack-Signature: t=<unix-timestamp>,v1=<hex>

t — the Unix timestamp (seconds) when the request was signed.
v1 — the lowercase hex HMAC-SHA256 of "{t}.{rawBody}", where rawBody is the exact request body.

To verify:

Read t and v1 from the header.
Compute HMAC-SHA256(secret, "{t}.{rawBody}") over the raw body — before any JSON parsing or re-serialization.
Compare your result to v1 using a constant-time comparison.
Reject the request if it doesn't match, or if t is older than your tolerance (e.g. 5 minutes) — this guards against replay.

IsValidSignature.cs

bool IsValidSignature(string rawBody, string signatureHeader, string secret)
{
    var parts = signatureHeader.Split(',')
        .Select(p => p.Split('=', 2))
        .ToDictionary(p => p[0], p => p[1]);

    // Reject stale deliveries (replay protection)
    if (Math.Abs(DateTimeOffset.UtcNow.ToUnixTimeSeconds() - long.Parse(parts["t"])) > 300)
        return false;

    using var hmac = new HMACSHA256(Encoding.UTF8.GetBytes(secret));
    var computed = Convert.ToHexString(
        hmac.ComputeHash(Encoding.UTF8.GetBytes($"{parts["t"]}.{rawBody}"))).ToLowerInvariant();

    return CryptographicOperations.FixedTimeEquals(
        Encoding.UTF8.GetBytes(computed), Encoding.UTF8.GetBytes(parts["v1"]));
}

isValidSignature.js

const crypto = require('crypto');

function isValidSignature(rawBody, signatureHeader, secret) {
    const { t, v1 } = Object.fromEntries(signatureHeader.split(',').map(p => p.split('=')));

    // Reject stale deliveries (replay protection)
    if (Math.abs(Math.floor(Date.now() / 1000) - Number(t)) > 300) return false;

    const computed = crypto.createHmac('sha256', secret).update(`${t}.${rawBody}`).digest('hex');
    const a = Buffer.from(computed);
    const b = Buffer.from(v1);
    return a.length === b.length && crypto.timingSafeEqual(a, b);
}

Data model

Fees arrive as pre-formatted currency strings (not numbers) — each fee is exposed as three keys: the base amount (ex-GST), its …GST, and its …Total (inc GST). Dates arrive as ISO-8601 UTC strings.

OrderUpdate.cs

public class OrderUpdate
{
    public bool AvailableOnline { get; set; }
    public string BillingTypeName { get; set; }
    public string ClientReference { get; set; }
    public string Comments { get; set; }
    public string DateOrdered { get; set; }     // ISO-8601 UTC, e.g. "2026-07-01T14:03:22.0000000Z"
    public string DateCompleted { get; set; }   // ISO-8601 UTC; null until completed
    public string Description { get; set; }
    public int OrderId { get; set; }
    public string OrderedBy { get; set; }
    public int ParentOrderId { get; set; }
    public string Reference { get; set; }
    public string RetailerReference { get; set; }
    public string RetailerFee { get; set; }        // pre-formatted currency string, e.g. "10.00"
    public string RetailerFeeGST { get; set; }
    public string RetailerFeeTotal { get; set; }
    public string SupplierFee { get; set; }
    public string SupplierFeeGST { get; set; }
    public string SupplierFeeTotal { get; set; }
    public string TotalFee { get; set; }
    public string TotalFeeGST { get; set; }
    public string TotalFeeTotal { get; set; }      // total disbursement (inc GST)
    public string ServiceName { get; set; }
    public string Status { get; set; }
    public string DisplayStatus { get; set; }
    public string StatusMessage { get; set; }
    public string DownloadUrl { get; set; }        // merged single-PDF link for the order
    public string OnlineUrl { get; set; }          // link to view the order on the InfoTrack platform
    public string Email { get; set; }
    public string ServiceIdentifier { get; set; }
    public int ClientId { get; set; }
    public int LoginId { get; set; }
    public long SequenceNumber { get; set; }
    public IReadOnlyList<OrderFile> Files { get; set; }
}

OrderFile.cs

public class OrderFile
{
    public string Url { get; set; }        // direct storage link to the individual document
    public string Name { get; set; }       // best-effort; null when InfoTrack has no file name
    public string Extension { get; set; }  // best-effort; derived from Name; null when Name is null
}

Field reference

These are the fields relevant to a webhook consumer. Any field not listed here (e.g. SecureUrl, FileHash, IsBillable) is for InfoTrack internal use and can be ignored.

Field	Description
`OrderId`	InfoTrack's unique id for the order. Multiple updates arrive for the same order, so dedupe on `OrderId` before you insert/update, and use `SequenceNumber` to apply them in order.
`SequenceNumber`	A strictly-increasing value stamped on each update for an order. Keep the highest `SequenceNumber` you've applied per `OrderId` and ignore any update with a lower or equal value — this prevents a late-arriving stale update (e.g. a `Pending`) from overwriting a newer one (e.g. a `Complete`).
`ParentOrderId`	Relates this order to a parent order. `0` means it has no parent. See Orders, envelopes, and filings below.
`RetailerReference`	Your prefixed correlation token (the value you sent on the mapping, beginning with your InfoTrack-assigned prefix). Use it to tie the order back to your user and matter.
`ClientReference`	The matter reference you supplied on the mapping.
`Status`	The order's lifecycle status (e.g. `Saved`, `Pending`, `Complete`, `Error`) — where the order is in processing.
`DisplayStatus`	The outcome shown to users (e.g. `Accepted`, `Rejected`, `Partially Rejected` / `Partially Accepted`, `Return For Correction`, `Served`, `In Progress`). For court filings this is the court's verdict, and it is distinct from `Status`: a filing can be `Status: Complete` while `DisplayStatus` is `Accepted` or `Rejected`. Use `DisplayStatus` (not `Status`) to tell an accepted filing from a rejected one, and to surface the outcome to your users.
`StatusMessage`	Human-readable detail accompanying the current status.
`Description`	The best human-readable description of what was ordered/filed.
`ServiceName`	The order type name (e.g. `New Case Filing`, `Filing`).
`ServiceIdentifier`	Short machine identifier for the service (e.g. `ILNewCaseFiling`).
`Comments`	Order-related information from InfoTrack.
`DateOrdered`	When the order was placed (ISO-8601 UTC string).
`DateCompleted`	When the order reached a completed status (ISO-8601 UTC string; `null` until then).
`Reference`	Service/court reference for the order.
`OrderedBy`	Username of the InfoTrack user who placed the order.
`Email`	Email address of the user who placed the order.
`ClientId`	InfoTrack client id — useful for grouping updates by client.
`LoginId`	InfoTrack login id — useful for linking updates to a specific user.
`RetailerFee` / `SupplierFee` / `TotalFee*`	Fee breakdown as pre-formatted currency strings (e.g. `"10.00"`). Each is three keys: the base amount ex-GST (e.g. `RetailerFee`), its GST (`RetailerFeeGST`), and its inc-GST total (`RetailerFeeTotal`). `TotalFeeTotal` is the total disbursement.
`AvailableOnline`	Whether the order can be viewed on the InfoTrack website.
`BillingTypeName`	Billing/product type for the order.
`DownloadUrl`	Merged single-PDF link for the order's documents. Per-document links are on `Files[]`.
`OnlineUrl`	Link to view the order on the InfoTrack platform.
`Files`	Documents associated with the order, each with a `Url` (direct storage link to that document) plus best-effort `Name` and `Extension`. `Name`/`Extension` are `null` when InfoTrack has no file name for the document, so fall back to `Url` to tell documents apart. For filings this includes the court-stamped / returned documents once the court accepts. Populated only for statuses where documents are ready; otherwise an empty list.

Order status: `Status` (lifecycle) vs `DisplayStatus` (outcome)

Status tells you where the order is in processing; DisplayStatus tells you the outcome. For court filings the court's decision is in DisplayStatus, not Status — and an order placed through the MCP tools is marked Status: Complete even when the court rejects it or returns it for correction.

⚠️

Always read DisplayStatus for the result

Never treat Status: Complete as "accepted." A filing is Status: Complete whether the court accepted, rejected, or returned it — the verdict is in DisplayStatus.

Status values (Filing & Service of Process)

`Status`	Terminal?	Meaning
`Saved`	no	Draft saved, not yet submitted.
`To Be Requested`	no	Created, queued for processing.
`Queued`	no	Queued to be sent.
`Pending`	no	Submitted, awaiting an outcome (usually `DisplayStatus: In Progress`).
`Submitting` / `Submitted` / `Under Review`	no	In submission / under review.
`Complete`	yes	Terminal — the order finished, including filings the court rejected or returned for correction. Check `DisplayStatus` for the result.
`Error`	yes	Terminal — a technical failure (not a court rejection).
`Canceled`	yes	Terminal — the order was cancelled.

DisplayStatus values

Filing: In Progress, Accepted, Rejected, Partially Rejected / Partially Accepted, Return For Correction, Served, Failed, Processed (empty while Saved). The partial-outcome value depends on the court's filing manager — Partially Rejected (Tyler, JTI courts) or Partially Accepted (One Legal courts) — both mean some documents were accepted and some rejected; treat them the same. The ones to surface prominently — these are not success — are Rejected, Partially Rejected / Partially Accepted, Return For Correction, and Failed.
Service of Process: DisplayStatus carries the serve progress and outcome. In-progress values include Awaiting Agent Assignment, Awaiting First Attempt, Awaiting Proof of Service, Proof of Service Needs Review, and similar. The terminal outcomes are:
- Complete - Service — successfully served.
- Complete - Non-service — could not be served.
- Complete - Bad Address — could not be served (bad address).
- Cancelled — the order was cancelled.
Surface prominently: Complete - Non-service and Complete - Bad Address (the serve did not succeed). As with filing, read DisplayStatus for the outcome — the lifecycle Status will be Complete / Error / Canceled.

💡

Recommended handling

Treat a Status of Complete, Error, or Canceled as terminal, then branch on DisplayStatus. Filing: Accepted / Served = success; Rejected / Partially Rejected / Partially Accepted / Return For Correction / Failed = surface to the user; In Progress / empty = not yet decided. Service of Process: Complete - Service = served; Complete - Non-service / Complete - Bad Address = surface to the user; the Awaiting … / Proof … Needs Review states = still in progress.

Orders, envelopes, and filings

In InfoTrack, everything is an order, and a single court e-filing submission produces several related orders linked by ParentOrderId:

The order with no parent (ParentOrderId = 0) is the envelope-level order — the overall submission sent to the court.
Each child order (ParentOrderId = the envelope order's OrderId) is an individual filing within that envelope.

You'll receive updates for both the envelope and each of its filings; group them by ParentOrderId to reconstruct the submission. For example, a new-case submission with one document produces an envelope order (ServiceName: New Case Filing, ParentOrderId: 0) and a child filing order (ServiceName: Filing, ParentOrderId = the envelope's OrderId).

The filing tools (Start_filing / Continue_filing) return this envelope-level OrderId (as DraftOrderId / FiledOrderId), and only the envelope-level id. It matches the envelope order's OrderId on the webhook, so store it and correlate updates back to the filing you started; the individual filing(s) arrive on the webhook with their own OrderId and a ParentOrderId set to the envelope's id.

ℹ️

Court filing only

This envelope/filing structure applies to court filing only — it does not apply to process serving orders.

Example receiver

OrderUpdatesController.cs

[ApiController]
[Route("[controller]")]
public class OrderUpdatesController : ControllerBase
{
    private readonly IInfoTrackRepository _repo;
    private readonly ILogger _logger;

    public OrderUpdatesController(IInfoTrackRepository repo, ILogger<OrderUpdatesController> logger)
    {
        _repo = repo;
        _logger = logger;
    }

    [HttpPost]
    [Route("")]
    public IActionResult Create(OrderUpdate order)
    {
        if (order == null)
        {
            return BadRequest("Missing order update dto body");
        }

        // Correlate back to your user/matter using order.RetailerReference (your prefixed value).
        _logger.LogInformation("Received update for order {OrderId} ({RetailerReference})",
            order.OrderId, order.RetailerReference);

        _repo.AddOrder(order);
        return Ok();
    }
}

Summary

Step	What you send / receive	Key value
Create mapping	POST `ClientReference` + `RetailerReference`	returns `MappingId`
Place filing	call MCP filing tools with `mappingId`	order tagged with your prefixed `RetailerReference`
Order updates	full order POSTed to your webhook	correlate via `RetailerReference`

The busywork disappears.

Connect Once

AI Does The Work

You Stay In Control

Simple requirements

Server URL

Client Credentials

OAuth 2.0

Connect to InfoTrack MCP

Getting Your Client Credentials

Access the Partners Portal

Generate Client Credentials

OAuth 2.0 Authentication

Configure Your MCP Client

Everything litigation teams need to move a case forward

File court documents with confidence

Request service without the back-and-forth

Court Filing Tools

Service of Process Tools

From documents to done in seconds

Complete Court Filing Flow

Case information

Filings (4)

Case parties (3)

Filing information

Filing fee summary

Receive order updates by webhook

Create a mapping

Pass the mappingId

Receive updates

Prerequisites

Step 1 — Create a mapping

Step 2 — Pass the mappingId to the MCP filing tools

Step 3 — Receive order updates

Verifying deliveries

Data model

Field reference

Order status: Status (lifecycle) vs DisplayStatus (outcome)

Orders, envelopes, and filings

Example receiver

Summary

Pass the `mappingId`

Step 2 — Pass the `mappingId` to the MCP filing tools

Order status: `Status` (lifecycle) vs `DisplayStatus` (outcome)