Ellipse Gradient for Header

NewStore Integration Guide

Integrate NewStore retail commerce, order management, inventory, fulfillment, and customer data with enterprise systems through REST APIs, selected event notifications, and OAuth 2.0 authentication.

NewStore integration options at a glance

NewStore’s primary integration mechanism is its documented REST API surface for commerce and retail operations, including Orders, Products, Customers, Locations, Inventory, and fulfillment orders. Selected operational events can support webhook-style or callback-driven workflows, although event coverage and delivery behavior must be confirmed for each API and tenant. OAuth 2.0 bearer access tokens, tenant-specific endpoints, scopes, and client permissions govern access. Bulk or asynchronous operations may be available for selected processes, but no universal bulk API was confirmed. Martini can consume NewStore APIs, receive supported notifications, schedule incremental synchronization, transform payloads, expose callback endpoints, and orchestrate downstream processing.

Integration pointSupported by NewStore?Common use casesHow Martini supports it
REST APIsYesNewStore documents REST APIs for reading and updating Orders, Products, Customers, Locations, Inventory, and fulfillment-related data.Martini can consume NewStore REST endpoints from workflows, transform responses, apply business rules, and expose APIs for downstream or callback-driven processes.
Webhooks / outbound callbacksLimitedNewStore supports event-driven patterns for selected operational events, but coverage, delivery semantics, authentication, and ordering must be confirmed per event and tenant.Martini can expose a REST endpoint or consume webhook-style notifications, validate requests, deduplicate events, and retrieve the current NewStore resource before processing.
Bulk / async / batch APIsLimitedBulk or asynchronous operations may exist for selected catalog, inventory, order, or export processes; no universal bulk API was confirmed.Martini can process paginated results in bounded batches, schedule incremental reads, maintain checkpoints, and apply rate-aware retry logic.
AuthenticationYesNewStore API access generally uses OAuth 2.0 bearer access tokens with tenant- and environment-specific clients, scopes, audiences, and endpoints.Martini can store client secrets and environment-specific settings securely, obtain or use access tokens, and apply API authentication within workflows.
File import/exportNot confirmedFile-based processes may exist for selected retail or catalog functions, but a general NewStore file or attachment API was not confirmed.If a documented NewStore file exchange is provisioned, Martini can retrieve, validate, transform, and deliver files using supported formats and transport methods.
Database / analytics accessNot confirmedDirect access to NewStore-managed production databases was not verified; supported APIs and documented exports should be preferred.Martini can use NewStore APIs or documented exports and can write normalized data to an approved downstream database when required.
GraphQL APIsNot confirmedNo current official NewStore GraphQL API was verified in the available research.Martini can consume GraphQL generally, but a NewStore GraphQL integration should not be designed unless the tenant documentation confirms an endpoint.
SOAP APIsNot confirmedNo current NewStore SOAP API was confirmed; REST and event-based mechanisms are the recommended planning basis.Martini supports SOAP consumption generally, but no NewStore SOAP flow should be assumed without tenant-specific documentation.

How NewStore exposes data and business events

NewStore REST APIs

NewStore documents REST APIs for commerce and retail operations. The relevant resources can include Orders, Products, Customers, Locations, Inventory, and fulfillment orders, with exact fields and endpoints varying by API product and tenant.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates with the environment-specific OAuth 2.0 configuration, calls the required NewStore endpoint, follows its documented pagination, validates the response, maps the resource into a canonical model, and writes it to the target system. It stores identifiers and checkpoints for safe retry and reconciliation.

Implementation sequence

Authenticate with the tenant-specific OAuth 2.0 configuration
Retrieve the documented NewStore resource
Follow the endpoint pagination model
Validate and normalize the response
Map fields to the target model
Apply business and state-transition rulesول?

NewStore webhook-style events

NewStore supports event-driven integration for selected operational events. Event coverage, subscription configuration, authentication, retry behavior, ordering, and duplication semantics must be confirmed for the required event and tenant.

Martini implementation pattern

Martini implementation pattern: expose a controlled REST endpoint for the supported callback or consume the configured notification, authenticate and validate the request, deduplicate it, and retrieve the current NewStore object when the notification is not complete. A workflow then routes the result to downstream systems.

Implementation sequence

Receive the NewStore event notification
Authenticate and validate the request
Check the event or source correlation key
Retrieve the current NewStore resource when required
Map the event and resource data
Invoke downstream processing and persist the outcome

NewStore batch synchronization

Selected NewStore processes may support bulk, asynchronous, or export-oriented operations, but a universal bulk API was not confirmed. Large synchronizations should therefore be designed around documented pagination, scheduled reads, or provisioned batch endpoints.

Martini implementation pattern

Martini implementation pattern: a scheduler starts bounded batches, uses a documented update field or checkpoint where available, controls concurrency, transforms each page, and records progress. Partial failures remain visible for replay rather than being treated as a successful whole-batch completion.

Implementation sequence

Start the scheduled synchronization
Load the saved checkpoint or overlap window
Retrieve a bounded NewStore page or batch
Transform and validate each item
Write results using idempotent operations
Persist progress and route failures for replay

Common NewStore integration patterns

Pattern 1: Synchronize NewStore orders with an ERP

When to use this pattern

Use this pattern when NewStore is the retail order capture platform and SAP S/4HANA, NetSuite, or Microsoft Dynamics 365 owns downstream financial or enterprise order processing. It supports scheduled incremental retrieval and optional status updates in the opposite direction.

Integration direction
NewStore
Martini
SAP S/4HANA
Example Mapping
NewStore FieldCanonical FieldTarget Field
order_idorder.externalIdExternal order ID
statusorder.lifecycleStatusSales order status
line_itemsorder.linesSales order lines
fulfillment_stateorder.fulfillmentStatusFulfillment status
Martini implementation pattern

A scheduled Martini workflow retrieves changed Orders using the documented pagination and watermark approach, maps line items and lifecycle states, validates required customer and location references, and performs an idempotent ERP upsert. It stores the ERP identifier and uses retry policies for transient failures while routing business-state conflicts to reconciliation.

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

Pattern 2: Synchronize inventory availability by location

When to use this pattern

Use this pattern when NewStore provides the inventory view that must be published to Shopify or another commerce channel, or when an external source must update NewStore inventory. The design should explicitly define the source of truth and quantity semantics.

Integration direction
NewStore
Martini
Shopify
Example Mapping
NewStore FieldCanonical FieldTarget Field
product_idinventory.productIdVariant or product identifier
location_idinventory.locationIdLocation identifier
available_quantityinventory.availableToSellAvailable quantity
updated_atinventory.sourceUpdatedAtInventory update timestamp
Martini implementation pattern

Martini retrieves Inventory by product and Location, distinguishes documented availability quantities, prevents stale writes with timestamp or version checks, and publishes normalized updates to the channel. Rate-aware batching, overlap windows, and idempotent updates reduce missed or duplicated inventory changes.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • mapping and transformation
  • conditional routing
  • rate-aware processing
  • retry handling

Pattern 3: Orchestrate fulfillment and shipment updates

When to use this pattern

Use this pattern when NewStore fulfillment orders must be coordinated with a warehouse, carrier, or delivery platform and shipment, pickup, or delivery status must return to NewStore. It is appropriate for bidirectional operational flows.

Integration direction
NewStore
Martini
Warehouse or carrier API
Example Mapping
NewStore FieldCanonical FieldTarget Field
fulfillment_order_idfulfillment.externalIdFulfillment reference
fulfillment_statusfulfillment.lifecycleStatusWarehouse or carrier status
shipment_referencefulfillment.shipmentIdShipment identifier
location_idfulfillment.locationIdFulfillment location
Martini implementation pattern

A Martini workflow receives a supported NewStore notification or polls fulfillment orders, calls the warehouse or carrier API, validates state transitions, and writes shipment or pickup updates back to NewStore. Correlation keys, safe retries, and a reconciliation path handle duplicate notifications, partial fulfillment, and downstream outages.

Martini capabilities used
  • event-driven workflows
  • API orchestration
  • state validation
  • data mapping
  • correlation
  • error handling

Pattern 4: Synchronize customers and order history with engagement systems

When to use this pattern

Use this pattern when NewStore customer and commerce activity must be made available to Salesforce or Klaviyo for service, segmentation, or lifecycle messaging. Privacy, consent, and data minimization should be applied before transmission.

Integration direction
NewStore
Martini
Salesforce
Example Mapping
NewStore FieldCanonical FieldTarget Field
customer_idcustomer.externalIdContact or customer external ID
emailcustomer.emailEmail address
orderscustomer.orderHistoryOrder history
consentcustomer.communicationConsentMarketing consent
Martini implementation pattern

Martini retrieves or receives Customers and related Orders, filters fields according to consent and purpose, maps the data to the engagement platform, and records delivery identifiers. Validation failures and provider throttling are separated from privacy or business-rule rejections so each can be handled appropriately.

Martini capabilities used
  • API consumption
  • workflow orchestration
  • data minimization
  • mapping and transformation
  • business rules
  • monitoring

Applications commonly integrated with NewStore

NewStore can be integrated with adjacent enterprise applications to coordinate retail orders, inventory, fulfillment, customer engagement, payments, and tax processing. The appropriate direction depends on the system of record and the NewStore API capabilities provisioned for the tenant.

Application Scenario Direction Martini Pattern
SAP S/4HANA Synchronize orders, products, inventory, pricing, financial status, and fulfillment information with the enterprise back office. NewStore → Martini → SAP S/4HANA Martini retrieves NewStore resources on a schedule or after supported events, maps them to SAP business objects, applies status and validation rules, and retries safe transient failures. Selected SAP updates can be routed back to NewStore.
NetSuite Transfer orders, customer data, products, inventory, fulfillment, and financial status between NewStore and the ERP. NewStore → Martini → NetSuite A Martini workflow uses REST pagination and watermarks to retrieve changed NewStore objects, performs idempotent upserts in NetSuite, stores cross-system identifiers, and routes rejected transactions to reconciliation.
Salesforce Synchronize customer profiles, order history, service context, and engagement data. NewStore → Martini → Salesforce Martini receives or retrieves NewStore Customers and Orders, applies consent and data-minimization rules, transforms the payload into Salesforce fields, and optionally sends approved customer updates back to NewStore.
Microsoft Dynamics 365 Coordinate retail orders, inventory, customer information, and ERP processes. NewStore → Martini → Microsoft Dynamics 365 Martini orchestrates bidirectional API calls, validates order and inventory state transitions, maps identifiers and quantities, and uses correlation keys to prevent duplicate writes.
Shopify Coordinate catalog, inventory, and order information when Shopify is one of several commerce channels. NewStore → Martini → Shopify Martini synchronizes Products, Inventory, and selected Orders according to the agreed system of record, normalizes channel-specific fields, and uses scheduled checkpoints or supported event notifications for incremental updates.
Adyen Exchange payment authorization, capture, refund, and payment-status information in a retail transaction flow. NewStore → Martini → Adyen Martini routes payment-related requests and responses between the relevant NewStore process and Adyen APIs, preserves correlation identifiers, applies safe retry rules, and avoids logging sensitive payment data.
Avalara Calculate tax and synchronize tax decisions or transaction data for NewStore orders. NewStore → Martini → Avalara A workflow sends the required order, location, and customer context to Avalara, validates the response, maps tax results into the NewStore process, and sends validation or service failures to an exception path.
Klaviyo Send customer, order, and product-event data for segmentation and lifecycle messaging. NewStore → Martini → Klaviyo Martini filters NewStore Customers, Orders, and Products according to consent and data-minimization rules, transforms them into Klaviyo event or profile payloads, and retries only safely repeatable deliveries.

How to build a NewStore integration in Martini

Objective

Establish secure, environment-specific access to the NewStore API product required by the integration.

Instructions in Martini

  • Confirm the NewStore base URL, tenant, API product, OAuth 2.0 grant, audience, scopes, and client permissions.
  • Store client secrets, tokens, and environment-specific values in protected Martini configuration or secrets management.
  • Test access against the relevant sandbox or production resource without hard-coding credentials.

Objective

Select a trigger that matches the required latency and the NewStore capability confirmed for the tenant.

Instructions in Martini

  • Use a NewStore webhook-style notification for a supported event when event coverage and delivery behavior are confirmed.
  • Use a Martini scheduler for incremental REST reads when event coverage is unavailable or incomplete.
  • Define the watermark, overlap window, or checkpoint strategy before processing begins.

Objective

Receive the event payload or retrieve the current NewStore resource using the documented endpoint behavior.

Instructions in Martini

  • Validate incoming callback authentication or event metadata.
  • Retrieve the authoritative Order, Product, Customer, Location, Inventory, or fulfillment order when a notification is incomplete.
  • Follow the endpoint’s documented pagination and avoid assuming a common pagination format across APIs.

Objective

Coordinate NewStore calls, target-system calls, business rules, and checkpoint persistence in a maintainable Martini workflow.

Instructions in Martini

  • Separate request handling, transformation, target writes, and reconciliation into clear workflow stages.
  • Use correlation identifiers and preserve NewStore source identifiers throughout the flow.
  • Bound concurrency for high-volume inventory or order processing.

Objective

Transform NewStore payloads into canonical and target-system models while accommodating tenant-specific schemas.

Instructions in Martini

  • Map actual NewStore object fields to the target contract.
  • Validate required fields, enumerations, quantities, timestamps, and state transitions.
  • Keep mappings tolerant of additive fields and version them when downstream contracts change.

Objective

Apply operational, privacy, inventory, fulfillment, and idempotency rules before committing downstream changes.

Instructions in Martini

  • Define the source of truth for products, inventory, orders, customer data, and fulfillment state.
  • Use consent and data-minimization rules for customer information.
  • Reject or route invalid state transitions and stale inventory writes rather than silently overwriting data.

Common NewStore data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
OrdersRepresent customer purchases, line items, order status, payment-related information, and fulfillment state.SAP S/4HANA, NetSuite, Microsoft Dynamics 365, Salesforce, ShopifyMartini retrieves or receives order data, maps identifiers and lifecycle states, applies idempotent upsert rules, and routes invalid or conflicting orders to reconciliation.
ProductsRepresent sellable products and product-related catalog information.Shopify, SAP S/4HANA, NetSuite, KlaviyoMartini normalizes product attributes, validates required fields, applies channel-specific mappings, and synchronizes changes using documented pagination or export mechanisms.
CustomersRepresent customer profiles and related commerce data.Salesforce, Microsoft Dynamics 365, Klaviyo, NetSuiteMartini applies consent, field-selection, and data-minimization rules before mapping customer data and preserving source identifiers.
LocationsRepresent stores, warehouses, or other inventory and fulfillment locations.SAP S/4HANA, NetSuite, Microsoft Dynamics 365, ShopifyMartini maps location identifiers and capabilities, validates ownership and status, and uses location context when synchronizing inventory or fulfillment.
InventoryRepresent product availability associated with locations.Shopify, SAP S/4HANA, NetSuite, Microsoft Dynamics 365Martini distinguishes available-to-sell, on-hand, reserved, and other documented quantities, controls concurrency, and prevents stale updates from overwriting newer availability.
Fulfillment ordersRepresent fulfillment work such as allocation, shipment, pickup, or delivery processing.SAP S/4HANA, NetSuite, Microsoft Dynamics 365, carrier or warehouse APIsMartini orchestrates fulfillment status exchanges, validates state transitions, correlates shipment or pickup identifiers, and retries safe transient failures.

Authentication and security considerations

OAuth 2.0 and tenant configuration

NewStore API access generally uses OAuth 2.0 bearer access tokens. The grant type, token audience, scopes, client registration, base URL, and tenant configuration can vary by API product and environment.

Secrets and permissions

  • Store client secrets, tokens, and environment-specific endpoints in protected Martini configuration or secrets management.
  • Request only the permissions required for each workflow, such as order, inventory, fulfillment, or customer access.
  • Use separate credentials and endpoints for sandbox and production where NewStore provisions them.

Webhook protection and privacy

Protect callback endpoints using the authentication or signature mechanism specified by NewStore. Minimize customer data passed downstream and avoid logging payment credentials or unnecessary personal information.

Operational considerations for NewStore integrations

Rate limits and pagination

Confirm quotas, burst limits, and pagination behavior for every NewStore API. Use bounded concurrency, exponential backoff for throttling and transient server failures, and checkpoints or overlap windows for incremental reads.

Idempotency and state

Event deliveries and scheduled reads can overlap or repeat. Store source identifiers and correlation keys, use idempotent target operations, and model order and fulfillment statuses as state machines with explicit handling for cancellation, returns, partial fulfillment, and split orders.

Inventory and schema quality

Clarify whether quantities represent available-to-sell, on-hand, reserved, or another measure. Validate required fields and enumerations, monitor additive or breaking schema changes, and prevent stale inventory writes from replacing newer availability.

Testing and reconciliation

Test sandbox and production payloads because tenant configuration can affect fields and behavior. Classify failures, preserve partial batch visibility, and provide reconciliation paths for rejected orders, inventory mismatches, and fulfillment failures.

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

Orchestration across systems

Martini provides a workflow layer for coordinating NewStore API calls, event notifications, ERP or commerce updates, transformation, validation, and reconciliation without embedding the full integration in isolated scripts.

Reusable integration logic

REST consumption, API exposure, mappings, business rules, authentication configuration, and error handling can be organized into maintainable reusable integration assets. This supports different NewStore tenants and downstream contracts without duplicating core logic.

Operational control

Martini can combine scheduled and event-driven processing, checkpointed synchronization, idempotent writes, retry policies, and workflow monitoring. This makes failures and partial processing visible and supports controlled recovery as APIs and business rules evolve.

Frequently asked questions

How can NewStore be integrated with enterprise systems?

NewStore can be integrated primarily through its documented REST APIs for Orders, Products, Customers, Locations, Inventory, and fulfillment orders. Selected operational events can support webhook-style or callback-driven flows, while OAuth 2.0 bearer tokens secure API access. Scheduled pagination, incremental synchronization, and documented batch or export processes can support larger data movements where available.

Can Martini integrate with NewStore?

Yes. Martini can consume NewStore REST APIs, receive supported event or webhook-style notifications, expose callback endpoints, map NewStore objects to downstream schemas, and orchestrate order, inventory, fulfillment, and customer workflows. A dedicated native Martini connector was not verified in the supplied research.

Do I need a connector to integrate NewStore with Martini?

No. A dedicated NewStore connector is not required. Martini can use NewStore’s confirmed native integration mechanisms, including REST APIs, OAuth 2.0 authentication, and supported event or callback endpoints, with workflows handling transformation, business rules, retries, and reconciliation.

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

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

Which NewStore integration methods should be used?

REST APIs are the primary integration method. Selected NewStore events may support webhook-style notifications or callbacks, but coverage and delivery semantics must be confirmed for each event and tenant. Bulk or asynchronous processing may be available for selected operations; no universal bulk API was confirmed. GraphQL and SOAP were not confirmed.

Can Martini receive NewStore events or callbacks?

Martini can receive webhook-style HTTP notifications when the required NewStore event is available and enabled. The implementation should confirm event coverage, authentication or signature requirements, retries, ordering, and duplicate-delivery behavior for the specific NewStore API and tenant.

How does synchronization with NewStore handle pagination and data mapping?

A Martini workflow follows the pagination method documented for each NewStore endpoint, processes bounded batches, and persists a checkpoint or overlap-based watermark where a reliable update field exists. Mapping transforms NewStore objects into canonical and target models while validating required fields, quantities, timestamps, and lifecycle states.

How are NewStore errors, retries, and duplicate events handled?

Martini can classify authentication, authorization, validation, throttling, transport, and business-state failures. Safe transient failures can use bounded retries and backoff, while duplicate events are controlled with event or source correlation keys and idempotent upserts. Rejected orders, inventory mismatches, and fulfillment failures can be routed to reconciliation workflows.

Related Martini documentation

NewStore APIs

Events & Workflows

Mapping & Validation

Security

Operations

Connect NewStore to your enterprise systems

Use Martini to build secure, maintainable NewStore integrations across orders, inventory, fulfillment, customers, and retail operations.

EXPLORE MARTINI
BOOK A DEMO