Release Notes 6/29/26 - 7/19/26

Add OrderID to Get Invoice endpoint

• The "Get Invoice" endpoint has been updated to include the external order ID (externalOrderId) of the order the invoice is matched to
• The value will be null if the invoice is not matched to an order
• Note that this is the external order ID, not the order number. An Order number may still appear under the referenceNumbers section if there is one on the Invoice. Also, even if there's a matched Order, the Invoice itself may not have an Order number listed in referenceNumbers

Enhanced Matching - BOL Number to BOL Number

• Navix's matching hierarchy previously had four steps:

  Priority	Invoice Reference	Matched Against Order Field
  1st	External Order ID	Order's ExternalId
  2nd	Order Number	Order's OrderNumber
  3rd	BOL Number	Order's OrderNumber
  4th	Shipment Number	Order's ShipmentNumber reference

• The issue: for tenants who book freight on behalf of their customers, the carrier never receives the broker's internal order number — they only know the customer's BOL Number. In these cases, the invoice arrives carrying a BOL Number reference that doesn't match the Order Number, and there's no Shipment Number to fall back on (steps 2–3 fail). The invoice lands in Unmatched and requires manual intervention
• The solution: a 5th priority step has been added to the matching hierarchy — if all four existing steps fail to find a match, Navix will attempt to match the invoice's BOL Number against the Order's BOL Number reference:
  

  Priority	Invoice Reference	Matched Against Order Field
  1st	External Order ID	Order's ExternalId
  2nd	Order Number	Order's OrderNumber
  3rd	BOL Number	Order's OrderNumber
  4th	Shipment Number	Order's ShipmentNumber reference
  5th	BOL Number	Order's BOL Number reference

Orderless Invoice Support: Customers and Vendors

• Tenants need to be able to create customers and vendors via API, and manage business rule configuration, assignments, and settings from their TMS
• Our Create Order endpoint automatically creates vendors and customers on the fly. However, tenants using orderless invoices need a mechanism for creating customers and vendors via API that doesn't require an order
• The ability to create and update vendors and customers via API has been added
• It's also now possible to store metadata on customers and vendors. This metadata can be injected into the Flex Rule engine when running business rules:
  • invoice.customer.metadata
  • invoice.vendor.metadata
  • order.customer.metadata
  • order.vendors[].metadata

Order Number Pattern Drift Detection - Emails

• Internal alerting has been established to trigger when a tenant's incoming orders no longer match the pattern currently configured in Tenant Settings
• This alerting helps the Navix team identify pattern changes and update the setting more quickly, resulting in a smoother transition for the tenant and a reduction in mismatch exceptions

Stop duplicate documents appearing on Sunnybrook shipments when an approved invoice is reprocessed

• When an invoice is approved in Navix, its documents (carrier invoice, POD, supporting paperwork) are pushed to the carrier's shipment in Sunnybrook. Previously, whenever that delivery was automatically reprocessed after a temporary hiccup, the documents that already went through would get sent again — leaving duplicate paperwork on the Sunnybrook shipment
• Approved-invoice document delivery to Sunnybrook is now duplicate-safe across automatic retries and reasonable manual replays
• POD approval is applied once, not flipped back and forth on retries
• If the safeguard's supporting storage is briefly unavailable, Navix still delivers documents (never drops them) — accepting that rare duplicates during an outage are better than missing paperwork

INVOICE_ORDER_MATCHED Webhook

• A new webhook has been created that triggers when an invoice and order match, regardless of the circumstances of the match (e.g., order first vs. invoice first)
• A corresponding webhook has also been created for when an order and invoice are unmatched
• The immediate use case: tenants need to attach TMS documents associated with an order to the matched invoice, but this can't be done at invoice creation time because the order number isn't yet known. The webhook lets them attach those documents once the match occurs
• The webhook has a slim payload consisting of the invoice UUID and the order external ID, consistent with what's exposed in other webhooks

Turvo — Throttle outbound calls to stay within per-tenant rate limit

• Turvo allows each tenant a fixed number of requests per second. Previously, Navix had no self-limit, so a burst of approvals could overwhelm that allowance and cause Turvo to reject all requests for that tenant — including login attempts
• All outbound Turvo requests (login and data) are now paced per tenant to stay within Turvo's allowance, queuing brief bursts instead of firing them all at once

Turvo — Cache the login token for its true lifetime, per tenant

• Every Turvo login token is valid for hours, but Navix was discarding it after ~55 minutes and, under stress, re-requesting it on every single operation — a large contributor to tripping Turvo's rate limit
• Each tenant's token is now honored for its full stated lifetime, with a new token fetched only when it truly expires or is rejected
• Simultaneous approvals for the same tenant now share one login instead of each triggering its own
  
  
  

Turvo — Guarantee the failure flag reaches the user, and retry safely when it can't

• When a sync partially or fully fails, Navix's safeguard is to place a failure flag on the Turvo shipment so the tenant's team knows to check it. Previously, if placing that flag also failed, Navix would still mark the work as "done" — making the failure invisible to everyone
• This update guarantees an approval is only considered finished once the user has actually been notified; if notification can't be delivered, Navix retries until it can
• Retries are made safe so they don't create duplicate charges or documents
• Specifically, the failure flag is now treated as the point at which "the user has been informed" — the approval only finishes when either the sync succeeded or the failure flag was successfully placed. If the flag can't be placed, the approval retries later instead of silently finishing
  
  
  

New IDP Classification Analyzer Promoted

• A new Classification Analyzer was deployed to Production on Wednesday, 7/15
• The new analyzer focuses on improving performance against the following misclassification trends reported by tenants:
  • Carrier Invoices misclassified as Commercial Invoices
  • Statement Invoices misclassified as Carrier Invoices
  • Multiple different Document Types being misclassified as Other Receipt
    
    
    

Customer GET/PUT Endpoint Mismatch

• The "Get a customer" endpoint was returning a field called name, but the corresponding PUT endpoint instead used description
• The PUT endpoint has been updated to use name, so it now matches the GET endpoint and aligns with the vendor GET/PUT behavior

Turvo Integration | Truncate item descriptions

• When the Turvo integration sends an order to Navix, ingestion would fail if the "description" on the "items" was more than 255 characters
• Item descriptions exceeding 255 characters will now be truncated to 255 characters instead of failing ingestion

• No reporting updates to share at this time