Ellipse Gradient for Header

Narvar Integration Guide

Connect Narvar with commerce, ERP, fulfillment, carrier, and customer-service systems through REST APIs, selected callbacks, and orchestrated synchronization workflows.

Narvar integration options at a glance

Narvar integrations primarily use REST APIs to exchange orders, shipments, packages, tracking events, returns, and notification-related information. Selected Narvar products or tenants may also provide outbound callbacks or event notifications, although coverage, payloads, signing, and retry behavior must be confirmed. Enterprise implementations may use approved scheduled data feeds or managed file transfers, but exact formats and availability require tenant confirmation. Authentication is account-specific and may use an API key, bearer token, client credentials, or another provisioned method. Martini can consume Narvar APIs, expose REST endpoints, orchestrate workflows, transform payloads, and implement scheduled reconciliation with validation, checkpoints, retries, and idempotency controls.

Integration pointSupported by Narvar?Common use casesHow Martini supports it
REST APIsYesSubmit Orders, Shipments, Packages, and related fulfillment data; retrieve shipment, tracking, and return-related information.Martini can consume Narvar REST endpoints from workflows and expose REST APIs for upstream commerce, ERP, warehouse, or carrier systems.
Webhooks and outbound callbacksLimitedReceive selected post-purchase events such as shipment updates, delivery exceptions, or delivery confirmation when enabled for the tenant.Martini can expose a REST endpoint, validate requests, acknowledge quickly, deduplicate events, and process the work asynchronously. Event coverage and signing must be confirmed with Narvar.
File and managed transfer integrationLimitedExchange scheduled order, fulfillment, or return feeds in enterprise implementations where Narvar has approved a file or managed-transfer arrangement.Martini can ingest, validate, transform, and route approved files, but exact formats, SFTP availability, and feed catalogs must be confirmed.
Bulk, batch, and asynchronous APIsNot confirmedLarge-volume order or shipment submission may require batch or asynchronous processing, but a generally available Narvar bulk API was not verified.Martini can implement scheduled incremental processing, throttling, checkpoints, and retries when no bulk endpoint is available.
AuthenticationLimitedNarvar requires account-specific credentials provisioned during partner or tenant onboarding.Martini stores credentials in secrets and can apply the confirmed API key, bearer token, client-credential, or other account-specific configuration without embedding secrets in workflows.
GraphQL APIsNot confirmedNo current official Narvar GraphQL documentation was verified.Martini can consume GraphQL APIs generally, but Narvar REST APIs or approved feeds should be used unless Narvar confirms GraphQL access for the tenant.
SOAP APIsNot confirmedNo current official Narvar SOAP documentation was verified.Martini can consume SOAP services generally, but no Narvar SOAP integration should be assumed.
Database and analytics accessNoNo public Narvar database-access mechanism was verified.Martini should use Narvar APIs or approved export mechanisms rather than direct database access.

How Narvar exposes data and business events

Narvar REST APIs

Narvar REST APIs are the primary documented mechanism for exchanging post-purchase data. Depending on the product and tenant, they can support order, shipment, package, tracking, return, customer, fulfillment, and notification-related scenarios.

Martini implementation pattern

Martini implementation pattern: A workflow receives data from an upstream system or starts from a schedule, validates required fields, calls the appropriate Narvar REST endpoint, transforms the response, and persists correlation identifiers and synchronization state. Authentication and endpoint details are confirmed during Narvar onboarding.

Implementation sequence

Receive an order, fulfillment, or reconciliation input
Validate identifiers, carrier values, addresses, and required timestamps
Transform the source payload into the Narvar REST schema
Call the applicable Narvar endpoint with environment-specific credentials
Persist the response, correlation identifiers, and synchronization status
Retry transient failures and route validation failures for resolution

Narvar callbacks and event notifications

Narvar may provide outbound callbacks or event notifications for selected post-purchase events. Availability, event coverage, payload completeness, signatures, and retry behavior are product- and tenant-dependent.

Martini implementation pattern

Martini implementation pattern: Martini exposes a controlled REST endpoint for eligible Narvar callbacks, authenticates or validates the configured signature or shared secret, acknowledges quickly, and sends longer processing to a workflow. A scheduled reconciliation path covers missed or unsupported events.

Implementation sequence

Receive the Narvar callback at a Martini REST endpoint
Validate authorization, signature, event structure, and required identifiers
Acknowledge the request according to the confirmed delivery contract
Deduplicate the event using its event or business identifier
Retrieve the current object when the callback contains only an identifier
Map the event to customer, operational, or commerce systems

Narvar scheduled reconciliation

When callbacks are unavailable or incomplete, implementations can use available Narvar read APIs and scheduled workflows to reconcile recent Orders, Shipments, Tracking events, or Returns. Pagination and checkpoint behavior must be confirmed for the tenant.

Martini implementation pattern

Martini implementation pattern: A scheduler starts a workflow that reads a bounded time or cursor window, processes pages with controlled concurrency, compares Narvar state with source systems, and stores a durable checkpoint. The workflow can replay failed items without reprocessing successful submissions.

Implementation sequence

Start the reconciliation workflow on a configured schedule
Load the last durable timestamp, cursor, or business checkpoint
Retrieve the next page or bounded set of Narvar objects
Map and compare Narvar state with the source-of-truth system
Write changed statuses and persist the new checkpoint
Record failures for targeted retry and operational review

Narvar file or managed feeds

Some enterprise implementations may exchange scheduled data feeds or managed files with Narvar, but current public documentation did not confirm exact formats, SFTP support, or a standard feed catalog.

Martini implementation pattern

Martini implementation pattern: Where Narvar approves a file-based interface, Martini retrieves or receives files, validates naming and content, transforms rows or documents into Narvar or internal models, and preserves per-record results. File integration must be designed from the tenant-specific feed specification.

Implementation sequence

Confirm the approved Narvar feed, transport, format, and schedule
Receive or retrieve the managed file in Martini
Validate file structure, encoding, headers, and required fields
Transform each order, shipment, package, or return row
Submit or route the validated data to the required endpoint
Archive processing results and isolate rejected records

Common Narvar integration patterns

Pattern 1: Send orders and shipments to Narvar

When to use this pattern

Use this pattern when a commerce, ERP, warehouse, or order-management system must provide Narvar with order and fulfillment information for post-purchase visibility and notifications.

Integration direction
Shopify
Martini
Narvar
Example Mapping
Narvar FieldCanonical FieldTarget Field
orderNumberorder.externalIdOrder number
fulfillment.trackingNumberpackage.trackingNumberPackage tracking number
fulfillment.carrierpackage.carrierCodeCarrier
fulfillment.shippedAtshipment.shippedAtShipment shipped timestamp
Martini implementation pattern

Martini receives an order or fulfillment event, validates customer, address, carrier, tracking, and package data, transforms it into the Narvar Orders, Shipments, and Packages model, and submits the applicable REST request. A submission ledger, correlation identifiers, and retry policy prevent duplicate processing after timeouts or partial failures.

Martini capabilities used
  • workflows
  • API consumption
  • REST API exposure
  • data mapping
  • business rules
  • error handling

Pattern 2: Route Narvar tracking events to service systems

When to use this pattern

Use this pattern when delivery status, exceptions, or return updates must reach Salesforce, ServiceNow, Zendesk, or another operational system. Callback availability should be confirmed; polling can provide a reconciliation alternative.

Integration direction
Narvar
Martini
Salesforce
Example Mapping
Narvar FieldCanonical FieldTarget Field
trackingEvent.statusdelivery.statusCase or customer status
trackingEvent.eventTimestampdelivery.eventTimeEvent timestamp
package.trackingNumbershipment.trackingNumberTracking number
trackingEvent.exceptionCodedelivery.exceptionCodeException reason
Martini implementation pattern

Martini receives an eligible Narvar callback or retrieves current status on a schedule, validates and deduplicates the event, compares event timestamps and status precedence, enriches it with order context, and updates the target system. Unknown, out-of-order, and unmatched events are retained for reconciliation rather than silently discarded.

Martini capabilities used
  • REST API exposure
  • workflows
  • event processing
  • data mapping
  • business rules
  • error handling

Pattern 3: Synchronize Narvar returns with an ERP

When to use this pattern

Use this pattern when return requests, return shipments, or return status in Narvar must update NetSuite, SAP S/4HANA, Microsoft Dynamics 365, or a commerce platform for approval, receipt, refund, or exchange processing.

Integration direction
Narvar
Martini
NetSuite
Example Mapping
Narvar FieldCanonical FieldTarget Field
return.returnIdreturn.externalIdReturn authorization number
return.orderNumberorder.externalIdSales order number
return.statusreturn.lifecycleStatusReturn status
return.receivedAtreturn.receivedTimestampReceipt date
Martini implementation pattern

A Martini workflow retrieves or receives Narvar return information, matches it to an order and shipment, applies configured rules for valid transitions, transforms the status and identifiers, and updates the ERP. It records rejected transitions, missing matches, and downstream failures separately so eligible returns can be replayed without duplicating successful updates.

Martini capabilities used
  • API consumption
  • scheduled workflows
  • data mapping
  • business rules
  • validation
  • error handling

Pattern 4: Reconcile Narvar post-purchase data

When to use this pattern

Use this pattern to recover from missed callbacks, detect incomplete submissions, reconcile delivery exceptions, and reprocess records that previously failed validation.

Integration direction
Narvar
Martini
Manhattan Active Order Management
Example Mapping
Narvar FieldCanonical FieldTarget Field
shipment.updatedAtsync.changedAtLast synchronized timestamp
shipment.statusshipment.lifecycleStatusFulfillment status
package.trackingNumberpackage.externalKeyPackage key
return.statusreturn.lifecycleStatusReturn status
Martini implementation pattern

A scheduled Martini workflow reads the available Narvar status range or cursor, processes pages with controlled concurrency, compares results with the source system, and writes only changed states. Durable checkpoints, throttling, per-object results, and targeted retries make the process restartable and suitable for late-arriving tracking events.

Martini capabilities used
  • scheduler triggers
  • workflows
  • API consumption
  • data mapping
  • checkpoint management
  • retry handling

Applications commonly integrated with Narvar

Narvar can be integrated with surrounding commerce, ERP, order-management, and customer-service applications to coordinate post-purchase data. The exact direction and object coverage depend on the Narvar product, tenant configuration, and APIs or feeds enabled for the adjacent application.

Application Scenario Direction Martini Pattern
Shopify Send orders and fulfillment information to Narvar for shipment visibility and customer notifications, and return relevant status to commerce processes where supported. Shopify → Martini → Narvar Martini exposes or consumes the required Shopify APIs, validates order and fulfillment data, maps it to Narvar Orders, Shipments, and Packages, and submits it through Narvar REST APIs. A reconciliation workflow handles timeouts and missed updates.
Salesforce Provide service teams with delivery status, tracking events, exceptions, and return information alongside customer and order context. Narvar → Martini → Salesforce Martini receives supported Narvar callbacks or polls status, normalizes Tracking events and Returns, applies status and customer-matching rules, and updates Salesforce while recording duplicate and failed events for replay.
NetSuite Synchronize orders, fulfillments, tracking numbers, and return status between an ERP and Narvar. NetSuite → Martini → Narvar A Martini workflow retrieves or receives NetSuite fulfillment data, maps carrier and package fields to Narvar, submits the applicable REST requests, and persists external identifiers and response status for retry-safe processing.
SAP S/4HANA Exchange fulfillment, shipment, delivery, and return information between a large-scale ERP and Narvar. SAP S/4HANA → Martini → Narvar Martini orchestrates API or approved feed exchange, validates carrier and delivery values, transforms SAP structures into Narvar payloads, and routes validation, authentication, and transient failures separately.
Microsoft Dynamics 365 Synchronize sales orders, fulfillment status, shipment tracking, and customer updates with Narvar post-purchase processes. Microsoft Dynamics 365 → Martini → Narvar Martini receives Dynamics 365 changes or retrieves them on a schedule, maps order and shipment identifiers, calls Narvar REST APIs, and uses checkpoints and a submission ledger to prevent duplicate processing.
ServiceNow Surface delivery exceptions and return-related issues for service operations and case management. Narvar → Martini → ServiceNow Martini consumes eligible Narvar events or reconciliation results, enriches them with order and package context, applies case-creation rules, and writes actionable exceptions to ServiceNow with correlation identifiers.
Zendesk Give support agents access to shipment, delivery-exception, and return status during customer interactions. Narvar → Martini → Zendesk Martini normalizes Narvar shipment and return updates, matches them to customer or order identifiers, and updates Zendesk through its available APIs while isolating malformed or unmatched events for review.
Manhattan Active Order Management Exchange order fulfillment, shipment, package, and delivery information with a distributed order-management platform. Manhattan Active Order Management → Martini → Narvar Martini coordinates order-management events or scheduled retrieval with Narvar REST calls, applies carrier and package mappings, and uses durable checkpoints, retries, and reconciliation for late or missing tracking updates.

How to build a Narvar integration in Martini

Objective

Confirm the Narvar tenant, product APIs or approved feeds, authentication method, scopes, environments, and rate limits before building mappings.

Instructions in Martini

  • Obtain the tenant-specific Narvar API or feed specification
  • Store credentials in Martini secrets and keep them environment-specific
  • Confirm required headers, token flows, scopes, and rotation procedures
  • Test authentication separately from business validation

Objective

Select the event, API, file, or schedule that starts the synchronization based on the Narvar capability confirmed for the tenant.

Instructions in Martini

  • Use a Martini REST API for upstream order or fulfillment input
  • Receive eligible Narvar callbacks through a protected Martini endpoint
  • Use a scheduler for polling, reconciliation, or approved file feeds
  • Define the checkpoint and replay boundary

Objective

Acquire Orders, Shipments, Packages, Tracking events, or Returns while preserving source identifiers and raw response context.

Instructions in Martini

  • Validate request structure and required identifiers
  • Retrieve current Narvar data when a callback contains only an identifier
  • Handle pagination or bounded retrieval windows where available
  • Persist correlation IDs, timestamps, and source references

Objective

Coordinate validation, enrichment, Narvar calls, downstream writes, and response handling as a restartable Martini workflow.

Instructions in Martini

  • Separate authentication, validation, rate-limit, and server failures
  • Apply controlled concurrency and throttling
  • Use conditional routing for object type and status
  • Keep long-running callback work asynchronous where appropriate

Objective

Convert source-specific order, fulfillment, carrier, package, tracking, and return structures into the Narvar or downstream model.

Instructions in Martini

  • Map stable business identifiers and preserve external references
  • Normalize carrier codes, timestamps, time zones, and status values
  • Validate address, tracking, item, quantity, and package data
  • Use explicit mappings so schema changes are visible

Objective

Enforce lifecycle, deduplication, matching, and status-precedence rules before writing data to Narvar or adjacent systems.

Instructions in Martini

  • Use order, shipment, package, tracking, and return identifiers for matching
  • Compare event timestamps and status precedence
  • Use an idempotency key where Narvar supports one
  • Route unmatched, out-of-order, and invalid transitions for review

Common Narvar data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
OrdersSubmit customer purchases to Narvar for post-purchase processing and connect fulfillment activity to the original purchase.Shopify, NetSuite, SAP S/4HANA, Microsoft Dynamics 365, Manhattan Active Order ManagementMartini validates order, customer, address, and item fields, maps the source model to the Narvar schema, and stores correlation and submission status.
ShipmentsRepresent fulfillment or delivery movements associated with an order.NetSuite, SAP S/4HANA, Microsoft Dynamics 365, Manhattan Active Order ManagementMartini transforms fulfillment data, applies carrier and identifier rules, submits or retrieves shipment information, and retries transient failures safely.
PackagesRepresent individual parcels within a shipment, usually with a carrier tracking number.Shopify, ERP platforms, order-management platforms, SalesforceMartini validates package and tracking identifiers, maps carrier-specific values, and preserves package-level response and error details.
Tracking eventsCapture lifecycle states such as shipped, in transit, out for delivery, delivered, and exception.Salesforce, ServiceNow, Zendesk, data warehouses, commerce platformsMartini receives eligible callbacks or polls status, compares event timestamps and status precedence, deduplicates events, and routes normalized updates.
ReturnsRepresent return requests, return shipments, and return status information.Shopify, NetSuite, SAP S/4HANA, Microsoft Dynamics 365, SalesforceMartini matches returns to orders and shipments, applies approval or refund rules, maps status values, and records failed or unmatched updates.
NotificationsRepresent delivery-related messages or communication events sent to customers, where exposed by the Narvar implementation.Salesforce, Zendesk, commerce platforms, operational reporting systemsMartini treats notification data as product-dependent, maps available communication events, and avoids assuming a separate notification API unless documented for the tenant.

Authentication and security considerations

Tenant-specific authentication

Narvar credentials are provisioned during partner or tenant onboarding, but the exact public authentication scheme is not conclusively verified. Confirm whether the tenant uses an API key, bearer token, client credentials, or another account-specific method.

Secure credential handling

  • Store Narvar credentials in Martini secrets rather than workflow definitions or mappings.
  • Keep credentials and scopes environment-specific.
  • Confirm token or key rotation, permitted resources, and expiration behavior.
  • Separate authentication failures from validation, rate-limit, and server failures.

Callback protection

If Narvar callbacks are enabled, confirm signature or shared-secret requirements, validate authorization before processing, acknowledge requests according to the delivery contract, and avoid logging credentials or unnecessary customer information.

Operational considerations for Narvar integrations

Throughput and pagination

Confirm Narvar tenant limits, page sizes, pagination behavior, payload limits, and any retry headers. Use controlled concurrency, exponential backoff, and respect Retry-After when provided.

Idempotency and ordering

Use stable order, shipment, package, tracking, and return identifiers. Tracking events can arrive late, out of order, or more than once, so compare event timestamps and status precedence instead of assuming the latest received event is the latest business state.

Checkpoints and reconciliation

Polling workflows should use durable timestamps, cursors, or business checkpoints. Reconciliation provides recovery for missed callbacks, incomplete submissions, and unknown outcomes after network timeouts.

Schema and data quality

Validate carrier codes, tracking numbers, identifiers, addresses, quantities, timestamps, time zones, and return references. Use explicit mappings and monitor new or unknown fields as Narvar products and carrier integrations evolve.

Observability and testing

Record correlation identifiers, source IDs, HTTP status, error payloads, workflow execution IDs, retry counts, processing timestamps, and final synchronization state. Test representative shipment, delivery-exception, and return payloads in a non-production environment.

Why use Martini instead of scripts or point-to-point integrations?

Coordinate the complete integration

Scripts and point-to-point interfaces often leave authentication, transformation, retries, reconciliation, and operational visibility scattered across implementations. Martini brings those concerns into workflows and APIs that can be maintained as reusable integration assets.

Handle Narvar-specific variability

Narvar object schemas, callback coverage, authentication, and feed options may vary by product and tenant. Martini can isolate those differences behind explicit mappings, validation rules, environment configuration, and controlled workflows.

Support multiple operating modes

The same integration approach can combine API-led order and shipment submission, selected callback handling, scheduled polling, reconciliation, and approved file processing without requiring direct database access or an assumed connector.

Improve reliability and supportability

  • Apply retry, throttling, idempotency, and checkpoint logic consistently.
  • Separate transient, authentication, validation, and business failures.
  • Preserve correlation identifiers and per-record outcomes for investigation.
  • Expose controlled APIs for surrounding commerce, ERP, warehouse, and service systems.

Frequently asked questions

How can Narvar be integrated with enterprise systems?

Narvar is primarily integrated through REST APIs for Orders, Shipments, Packages, Tracking events, Returns, and related post-purchase data. Selected products or tenants may support outbound callbacks or event notifications, while approved scheduled feeds may also be available. The exact endpoints, schemas, authentication, and event coverage must be confirmed with Narvar.

Can Martini integrate with Narvar?

Yes. Martini can consume Narvar REST APIs, expose REST APIs for commerce, ERP, warehouse, or carrier systems, receive Narvar callbacks when enabled for the tenant, and orchestrate mapping, validation, retries, idempotency, and reconciliation workflows.

Do I need a connector to integrate Narvar with Martini?

No. A dedicated Narvar connector is not required. Martini can use Narvar's confirmed native REST APIs, selected callbacks, approved files or feeds, and account-specific authentication mechanisms through workflows and APIs.

Is there any extra Lonti cost to integrate Narvar with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Narvar. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Narvar, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.

Which Narvar integration methods should be used first?

REST APIs are the recommended starting point for current integrations. Selected callbacks may support event-driven processing, but their coverage, payloads, security, and retry behavior must be confirmed. Approved file or managed-transfer feeds can be considered when documented for the tenant. Narvar GraphQL, SOAP, and direct database access should not be assumed.

Are Narvar webhooks or event notifications available?

Narvar may provide outbound notifications or callbacks for selected post-purchase events, but public research does not establish universal coverage. Confirm supported events, delivery method, payload completeness, signatures, retries, and duplicate behavior. Martini can expose a receiving API and provide scheduled reconciliation when callbacks are unavailable.

How does synchronization between Narvar and other systems work?

Synchronization can be real time through supported callbacks and API-led workflows, or scheduled through polling, reconciliation, and approved feeds. Martini uses stable identifiers, pagination or bounded windows, durable checkpoints, explicit mappings, and status comparisons to handle late-arriving tracking events and missed notifications.

How are mapping, retries, and duplicate events handled?

Martini maps Narvar-specific Orders, Shipments, Packages, Tracking events, Returns, and Notifications to canonical and target models. Workflows can validate carrier and identifier data, apply business rules, use stable external keys or supported idempotency mechanisms, retry transient failures with backoff, and retain unknown outcomes or duplicates for reconciliation.

Related Martini documentation

API Workflows

Data Processing

Security Operations

Connect Narvar with your enterprise systems

Use Martini to build a maintainable Narvar integration across APIs, callbacks, scheduled synchronization, mappings, validation, and operational workflows.

EXPLORE MARTINI
BOOK A DEMO