Official Apps

Official Apps are apps maintained by Hantera that extend the platform with common functionality. They are installed on your Hantera instance and provide ingresses, rules, jobs, and portal extensions.

Many apps can be interacted with through APIs and rules, and this section contains relevant developer-centric documentation.

Available Apps

Commerce

Cart and promotion management for e-commerce. Provides HTTP ingresses for creating and managing shopping carts, a rendering pipeline for computing totals and prices, and hooks for PSP integration.

Key features:

• Cart CRUD operations via public HTTP ingresses
• Cart rendering with computed prices, taxes, and shipping
• Real-time cart updates via Server-Sent Events (SSE)
• Custom hook (OnCartMutation) for PSP and other app integrations
• Cart profiles for multi-currency and multi-country support

Products

Unified product, price list, and price management. Contributes Graph nodes and edges for the product/price/price-list model, derived price lists, and a Filtrera module that other apps can import to compute effective prices.

Key features:

• asset.product, asset.product.sku, asset.priceList, asset.price Graph nodes with their edges and sets
• Manual and derived price lists, with automatic propagation of source-list changes
• lookupPrices Filtrera module for computing current/lowest/highest effective prices and price-change history within a window — useful for custom price-lookup ingresses, ERP/PIM exports, and EU Omnibus 30-day-low displays
• Activity-log event types for price and price-list lifecycle changes

Inventory Routing

A family of apps that automatically assign order deliveries to warehouses based on stock availability and country-keyed inventory priority lists. Choose a variant depending on whether your downstream systems expect one warehouse per delivery or can consolidate multiple warehouses into a single delivery.

Key features:

• Channel-keyed, country-aware inventory priority lists
• auto_assign trigger key that the storefront / cart-to-order flow can set on new deliveries
• Best-effort multi-warehouse fill with a single-fulfiller preference for picking efficiency
• Automatic back-order handling — unfulfilable units stay on the country's primary warehouse instead of being silently dropped
• Stock reservations placed and released automatically across the order lifecycle
• Two variants:
  • inventory-routing.per-delivery — one warehouse per delivery; multi-warehouse lines are split into additional deliveries
  • inventory-routing.per-orderline — mixed warehouses within a single delivery (not yet available)

Payment Providers

A family of apps that integrate Hantera's payment system — and in particular the Payment actor — with external Payment Service Providers. Each PSP app translates Hantera payment lifecycle events (authorization, capture, refund, void) into the provider's protocol and handles incoming webhooks. Many PSP apps also ship with a Commerce integration so the cart-to-payment-to-order flow works end-to-end out of the box.

Available PSP apps:

• Kustom — Iframe-based checkout. Integrates the Payment actor with Kustom and ships with a complete Commerce cart integration: idempotent checkout ingress, hash-based cart synchronization driven by OnCartMutation, push-webhook fallback, capture flow, and the OnKustomValidation custom hook for merchant-supplied checkout validation

Shipping Providers

A family of apps that fetch shipping options (carrier products, delivery methods, pickup points) from external checkout-options providers and surface them in the portal Select shipping product flow. Each shipping app implements the standard shippingProductsService and exposes a Filtrera module other apps can import to fetch options from their own ingresses.

Available shipping apps:

• nShift Checkout — Integrates nShift Checkout as a shipping-options provider. Ships with a public nshift.module.hrc module that owns OAuth and session management, a channel-editor extension for the per-channel nshiftCheckoutConfigurationId, and the OnNShiftCheckoutVariables custom hook for merchant rules to contribute provider-specific request variables.

Tax Providers

A family of apps that calculate transaction tax on orders using an external tax engine and record the resulting documents for filing. Tax apps write the absolute amounts the engine returned onto order lines and deliveries, and share a vendor-neutral taxChecksum convention that keeps call volume down.

Available tax apps:

• Avalara AvaTax — US sales tax and Canadian GST/HST/PST/QST via Avalara AvaTax. Calculates tax on carts and orders, commits SalesInvoice and ReturnInvoice documents from Hantera invoices (with the original sale's tax date on returns), voids on cancellation, and adds portal tooling for tax-code lookup, entity/use codes, and address validation. Per-channel opt-in with its own ship-from origin, and a disableDocumentRecording mode for tenants whose ERP owns the filing record.

Returns

Customer claim and warehouse-inspection workflows. Contributes claim and rma ticket types with their graph nodes, edges, and enum value sets, public HTTP ingresses for filing and listing claims, and the OnClaimResolve custom hook that other apps and the merchant's own rules use to apply the actual side effects of a resolved claim.

Key features:

• POST /returns/claims/create and GET /returns/claims/get-by-order public HTTP ingresses, with automatic order-line matching by remaining claimable quantity
• ticket.claim, ticket.claim.line, ticket.rma, ticket.rma.line graph nodes and their edges/sets — see Graph
• OnClaimResolve custom hook fired at claim completion (for non-inspected lines) or RMA completion (for inspected lines), with orderCommand effects applied to the connected order in a single batch
• Registry-driven resolution types — declare new resolutions and per-resolution custom field editors with no code, and consume their values via the hook
• Stand-alone RMAs — RMA tickets can track returns without an originating claim
• Portal extension points — slots and warning services on the claim and RMA views

Conversion Tracking

A family of apps that report conversions to advertising and analytics platforms server-side, from the order rather than from the browser. Each app listens for the same order lifecycle events, maps them to its platform's event format, and sends them from a reactor — so conversions survive ad blockers, tracking prevention, and shoppers who close the tab before the thank-you page.

They share a vendor-neutral field:tracking:* → cart:tracking:* convention for carrying browser-side identifiers (cookies, click ids) from the storefront onto the order, so adding a platform requires no change to Commerce. See Conversion Tracking in the Storefront SDK docs for the capture-and-stamp flow.

Available tracking apps:

• Google Analytics 4 — GA4 Measurement Protocol. Sends purchase on order confirmation and refund as units are returned, attributed via the GA client id captured at the storefront and de-duplicated against the browser tag on the order number. Reports each order to every GA property configured for its channel — a master property plus per-channel properties for multi-site setups — with per-property refund idempotency so retries never double-deduct revenue.
• Meta Conversions — Meta Conversions API. Sends a Purchase event with normalized, SHA-256 hashed customer data, de-duplicated against the browser Pixel on the order number.
• Awin — Awin server-to-server conversion tracking. Reports a sale when an order is confirmed, attributed via the Awin click value, with per-channel and per-country advertiser resolution configured in the Channel editor.