Ellipse Gradient for Header

Productsup Integration Guide

Productsup integrates with enterprise systems through authenticated REST APIs, feed-oriented file exchange, and selective event or notification capabilities for product-data workflows.

Productsup integration options at a glance

Productsup provides authenticated REST APIs for accessing platform resources and product-data workflows, including projects, sources, channels, imports, exports, and related processing operations where supported by the tenant’s API version. Feed-oriented bulk and asynchronous processing is important for large catalogs, although job and status capabilities should be confirmed for the applicable edition. File and feed exchange can support scheduled imports, exports, and recovery processes through the supported upload, URL, SFTP, or other transfer method. Productsup may provide selective event or notification capabilities, but broad webhook coverage is not confirmed. Martini can authenticate through securely managed environment configuration, orchestrate scheduled or event-driven workflows, transform product attributes, validate data, and coordinate Productsup with surrounding systems.

Integration pointSupported by Productsup?Common use casesHow Martini supports it
REST APIsYesAccess Productsup platform resources and product-data workflows, including project metadata, sources, channels, imports, exports, and processing operations where exposed by the tenant API.Martini can consume the Productsup REST API, manage request configuration securely, paginate responses, transform payloads, and orchestrate downstream actions.
GraphQL APIsNot confirmedNo official Productsup GraphQL API was verified in the supplied research.Martini should use the confirmed Productsup REST or file-based mechanisms rather than assuming GraphQL availability.
SOAP APIsNoNo official Productsup SOAP API was confirmed.Martini can use REST, files, or other confirmed Productsup endpoints instead of SOAP.
Webhooks / outbound callbacksLimitedProductsup may provide notifications for selected workflows, but broad coverage for project, product, import, export, and channel events was not confirmed.Martini can receive a confirmed callback through an exposed API or use scheduled polling when event coverage, signatures, retries, or replay behavior are unavailable.
Bulk / async / batch processingLimitedFeed and catalog processing is central to Productsup, but the applicable API’s bulk submission, asynchronous job, and status endpoints must be verified.Martini can batch payloads, persist import or job identifiers, poll processing status, and separate transport acceptance from product-level results.
File / feed exchangeLimitedFiles and feeds support large catalogs, scheduled delivery, exports, recovery, and marketplace or advertising-channel distribution. The required upload, URL, SFTP, or transfer method must be confirmed.Martini can generate, validate, transform, and exchange feed files or consume export files through the supported transfer mechanism.
AuthenticationNot confirmedProductsup APIs require authenticated access, but the exact token, API-key, scope, permission, expiration, and rotation model must be confirmed for the tenant.Martini can store credentials and tokens in environment configuration or secrets and apply separate least-privileged settings for development, testing, and production.
Database / analytics accessNot confirmedNo direct Productsup customer-database or general-purpose SQL access was verified.Martini should use Productsup APIs or supported feed exchange, while separately connecting to enterprise databases when required by the surrounding workflow.

How Productsup exposes data and business events

Productsup REST APIs

Productsup provides API-based access to platform resources and product-data workflows. REST is the primary mechanism to investigate for project metadata, source and channel operations, product-data submission, and import or export monitoring, subject to the tenant’s API version and permissions.

Martini implementation pattern

Martini implementation pattern: Martini authenticates to the confirmed Productsup REST endpoints, retrieves or submits resources, handles pagination and response validation, maps the payload to an internal model, and persists correlation identifiers and checkpoints for later reconciliation.

Implementation sequence

Authenticate using the Productsup credential model confirmed for the tenant
Retrieve the project, source, channel, product, or feed resource
Handle pagination and normalize the response
Map Productsup fields to the target system model
Apply validation and business rules
Write the result and store the correlation or synchronization checkpoint

Productsup Webhooks and callbacks

Productsup may offer event-driven or notification-oriented capabilities for selected workflows, but universal coverage and delivery semantics were not confirmed. Event types, configuration scope, signatures, retries, duplicate behavior, and replay must be verified before relying on callbacks.

Martini implementation pattern

Martini implementation pattern: Martini exposes a controlled API endpoint to receive a confirmed Productsup callback, validates the request according to the documented security model, deduplicates the event, retrieves current state through the REST API when necessary, and routes processing failures for retry or investigation. Scheduled polling remains the fallback when no suitable callback exists.

Implementation sequence

Confirm the Productsup event type and callback delivery contract
Receive the callback through a Martini API
Validate authentication, signature, and event identity when documented
Check the event against the stored idempotency key
Retrieve current Productsup state when the notification is not authoritative
Process the event and record the completion status

Productsup bulk and feed processing

Productsup is designed for large-scale product-feed processing, making batch and file-oriented exchange important. The specific support for asynchronous job control, bulk record operations, upload endpoints, and status polling must be confirmed for the applicable API and account configuration.

Martini implementation pattern

Martini implementation pattern: Martini prepares a bounded batch or feed, validates encoding and required product attributes, submits it through the supported Productsup API or file mechanism, persists the import or export identifier, and polls or retrieves the processing report before updating downstream systems.

Implementation sequence

Collect changed products or prepare the complete feed
Validate identifiers, required attributes, URLs, and file structure
Partition the payload into supported batches
Submit the batch or feed through the confirmed Productsup mechanism
Persist the import, export, or job identifier
Poll or retrieve processing results and reconcile accepted and rejected products

Productsup file and feed exchange

Productsup can participate in feed-oriented file exchange for large catalogs, scheduled deliveries, exports, and recovery processes. The implementation must confirm whether the tenant uses file upload, a reachable URL, SFTP, cloud storage, or another supported transfer method.

Martini implementation pattern

Martini implementation pattern: Martini reads source data, creates the required feed format, applies mapping and validation, transfers or exposes the file through the agreed mechanism, and records file identity, checksum or timestamp, and processing results for replay and reconciliation.

Implementation sequence

Determine the required Productsup file-transfer method
Extract and transform the source catalog
Generate the required feed encoding, headers, delimiter, and compression
Validate the feed and media URLs
Transfer or expose the file through the confirmed mechanism
Record the file identifier and reconcile Productsup processing results

Common Productsup integration patterns

Pattern 1: Distribute PIM or ERP products through Productsup

When to use this pattern

Use this pattern when a PIM, ERP, commerce platform, or database is the product-data system of record and Productsup is responsible for optimization and downstream channel distribution. It supports incremental or scheduled catalog processing while isolating source-specific mappings from Productsup-specific payloads.

Integration direction
Akeneo
Martini
Productsup
Example Mapping
Productsup FieldCanonical FieldTarget Field
product_identifierskuProduct identifier
product_nametitleTitle
sale_pricepricePrice
stock_statusavailabilityAvailability
Martini implementation pattern

A scheduled Martini workflow retrieves changed products, normalizes locales, currencies, units, and availability values, validates identifiers, prices, landing-page URLs, and images, then submits a bounded batch or feed to Productsup. The workflow persists the import or feed identifier, separates transient failures from validation failures, and routes rejected products for remediation.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • data validation
  • batch orchestration
  • error handling
  • reconciliation

Pattern 2: Coordinate commerce catalog synchronization

When to use this pattern

Use this pattern when Shopify or Magento / Adobe Commerce provides commerce catalog data and Productsup distributes a normalized version to external channels. The workflow can synchronize changed products, monitor processing completion, and communicate exceptions without assuming that omission automatically deletes a product.

Integration direction
Shopify
Martini
Productsup
Example Mapping
Productsup FieldCanonical FieldTarget Field
handleproduct_keyProduct identifier
body_htmldescriptionDescription
variants.pricepricePrice
variants.inventory_quantityavailabilityAvailability
Martini implementation pattern

Martini retrieves changes using the commerce system’s supported API, applies business rules for channel-specific attributes and deletion semantics, maps the result to Productsup, and polls or retrieves processing status where available. Stable product keys and stored checkpoints prevent duplicate submissions, while reconciliation identifies products that require explicit removal or correction.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • mapping and transformation
  • business rules
  • idempotency handling
  • status polling
  • monitoring

Pattern 3: Monitor Productsup channel processing

When to use this pattern

Use this pattern when an organization needs a central operational view of Productsup projects, channels, imports, exports, and rejected products. It is useful for sending processing status to internal systems even when Productsup remains responsible for delivery to commerce or advertising destinations.

Integration direction
Productsup
Martini
ServiceNow
Example Mapping
Productsup FieldCanonical FieldTarget Field
project_idintegration_projectService or configuration reference
channel_namedestinationAffected service
rejected_product_countexception_countImpact count
processing_errorfailure_detailIncident description
Martini implementation pattern

A scheduled Martini workflow retrieves available Productsup processing and export information, normalizes status values, applies escalation thresholds, and creates or updates operational cases for material failures. It records correlation identifiers, avoids duplicate incidents, and retries only transient API or transport errors.

Martini capabilities used
  • workflow orchestration
  • REST API consumption
  • mapping
  • business rules
  • error classification
  • duplicate prevention
  • API integration

Pattern 4: Validate and reconcile product feeds

When to use this pattern

Use this pattern when product feeds require a control layer before or after Productsup processing. The pattern detects missing identifiers, invalid URLs, unsupported values, inconsistent pricing, and discrepancies between submitted, accepted, rejected, and unresolved products.

Integration direction
Productsup
Martini
PostgreSQL
Example Mapping
Productsup FieldCanonical FieldTarget Field
product_idproduct_keyproduct_key
feed_statusprocessing_statusprocessing_status
error_messagevalidation_detailvalidation_detail
processed_atlast_processed_atlast_processed_at
Martini implementation pattern

Martini retrieves a feed, report, or processing result through the confirmed Productsup API or file mechanism, validates the response, writes normalized status and error details to a database, and generates a reconciliation result. The workflow distinguishes data corrections from retryable service failures and stores a cursor, timestamp, or export identifier for subsequent runs.

Martini capabilities used
  • scheduled synchronization
  • file processing
  • API consumption
  • data validation
  • database integration
  • retries
  • reconciliation

Applications commonly integrated with Productsup

Productsup commonly sits between product-content sources and commerce, marketplace, advertising, and retail destinations. Martini can coordinate these systems through Productsup APIs, feed exchange, and surrounding application APIs, while the exact direction depends on the configured system of record and channel setup.

Application Scenario Direction Martini Pattern
Google Merchant Center Distribute optimized product data for Google Shopping and related commerce placements. Productsup → Martini → Google Merchant Center Martini can retrieve Productsup export status or feed outputs, normalize operational data, and publish monitoring or reconciliation information through the applicable Google integration. Productsup’s configured channel remains responsible for the product-data distribution path.
Meta Commerce Manager Deliver catalog data for Meta commerce and advertising environments and centralize processing visibility. Productsup → Martini → Meta Commerce Manager Martini can orchestrate catalog-status workflows, transform Productsup processing results, and route rejected-product details to the appropriate operational or Meta-facing process where supported.
Amazon Seller Central Transform and distribute marketplace product content, pricing, inventory, and offer data. Amazon Seller Central → Martini → Productsup Martini can retrieve marketplace product inputs, apply canonical mappings and validation rules, submit the normalized feed or API payload to Productsup, and track import or processing results without duplicating successful submissions.
Shopify Use commerce catalog data as input to Productsup and optionally synchronize processing or exception status back to the commerce platform. Shopify → Martini → Productsup A scheduled or source-system trigger starts a Martini workflow that retrieves changed products from Shopify, maps titles, prices, availability, images, and identifiers to the Productsup feed model, validates required fields, and records processing outcomes.
Magento / Adobe Commerce Use commerce catalog data as an input for product-feed optimization and channel distribution. Magento / Adobe Commerce → Martini → Productsup Martini can consume the commerce API, normalize catalog and locale data, batch the result for Productsup through its supported API or file mechanism, and route rejected products for remediation.
Microsoft Merchant Center Distribute product feeds for Microsoft Shopping and related advertising destinations. Productsup → Martini → Microsoft Merchant Center Martini can coordinate Productsup export monitoring, reconcile submitted and rejected product counts, and expose a controlled operational API or write results to an internal data store.
TikTok Business Center / Catalog Provide structured product catalog data for TikTok commerce and advertising use cases. Productsup → Martini → TikTok Business Center / Catalog Martini can validate channel-specific attributes before Productsup submission, poll supported processing identifiers, and send exceptions to operations when the configured TikTok channel rejects product data.
Akeneo Use enriched PIM product data as input to Productsup for downstream channel distribution. Akeneo → Martini → Productsup Martini can retrieve changed Akeneo products, map localized and channel-specific attributes to Productsup, validate identifiers and media URLs, and submit a repeatable batch or feed with checkpointed results.

How to build a Productsup integration in Martini

Objective

Establish Productsup access using the authentication scheme and permissions confirmed for the tenant, while separating development, testing, and production credentials.

Instructions in Martini

  • Confirm the Productsup API version, credential type, token lifecycle, and scopes
  • Store credentials in Martini secrets or environment configuration
  • Use least-privileged project and resource permissions
  • Test access against a non-production Productsup project

Objective

Select the trigger that matches the Productsup workflow and source-system latency requirements.

Instructions in Martini

  • Use a scheduler for polling, batch, or reconciliation workflows
  • Use a confirmed Productsup callback only for supported event types
  • Use a source-system API event when the upstream application provides one
  • Define the polling interval and checkpoint strategy

Objective

Acquire Productsup resources, product data, feed files, or processing notifications without assuming that an accepted submission represents completed processing.

Instructions in Martini

  • Retrieve the relevant project, source, channel, product, feed, or status resource
  • Handle pagination and bounded batch sizes
  • Receive callbacks through a Martini API only when the Productsup event contract is confirmed
  • Persist import, export, job, file, or correlation identifiers

Objective

Coordinate extraction, transformation, Productsup submission, status tracking, and downstream actions in a maintainable Martini workflow.

Instructions in Martini

  • Separate transport, transformation, submission, polling, and reconciliation stages
  • Apply timeouts for pending asynchronous processing
  • Use conditional routing for accepted, rejected, pending, and failed outcomes
  • Keep Productsup-specific request construction isolated from general workflow logic

Objective

Create a stable canonical product model and validate channel-specific requirements before data reaches Productsup or downstream systems.

Instructions in Martini

  • Map identifiers, titles, descriptions, prices, availability, categories, images, and custom attributes
  • Normalize currencies, locales, units, and condition values
  • Validate required fields, product keys, image URLs, landing-page URLs, and feed structure
  • Separate non-retryable data errors from transient service errors

Objective

Apply organization and channel rules that determine inclusion, enrichment, deletion behavior, and exception routing.

Instructions in Martini

  • Define explicit behavior for removed products and tombstone or replacement-feed semantics
  • Apply channel-specific required attributes without contaminating the canonical model
  • Use stable keys and deterministic payloads to prevent duplicate submissions
  • Route rejected products and unresolved discrepancies to an operational destination

Common Productsup data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
ProjectsOrganize product-data processing, transformation logic, and distribution configuration.PIMs, commerce platforms, ERP systems, operational databasesMartini can retrieve project metadata, use project identifiers in workflow configuration, and isolate environment-specific settings through secure configuration.
SourcesRepresent input feeds or data sources from which Productsup receives product content.Akeneo, Shopify, Magento / Adobe Commerce, ERP systems, filesMartini can submit or coordinate source data through the confirmed API or feed mechanism and track source-level processing outcomes.
ChannelsDefine configured destinations or distribution paths for commerce, advertising, marketplace, or retail platforms.Google Merchant Center, Meta Commerce Manager, Amazon Seller Central, Microsoft Merchant CenterMartini can read permitted channel metadata, validate channel-specific requirements, and monitor configured processing without assuming unrestricted channel administration.
ProductsRepresent product-level catalog items processed and distributed by Productsup.PIMs, ERP systems, e-commerce platforms, marketplaces, advertising destinationsMartini can map product identifiers and attributes, process incremental or batched changes, validate values, and maintain checkpoints for retries and reconciliation.
Product attributesCarry identifiers, titles, descriptions, prices, availability, images, categories, and custom fields.Productsup feeds, commerce platforms, marketplaces, advertising channelsMartini can apply canonical mappings, normalize currencies and locales, validate URLs and required fields, and route invalid attributes for remediation.
FeedsProvide structured product-data inputs or outputs exchanged through files, URLs, APIs, or configured channel processes.File stores, PIMs, commerce platforms, marketplaces, data warehousesMartini can generate or consume feed payloads, batch large catalogs, track export or import identifiers, and reconcile submitted, accepted, and rejected counts.

Authentication and security considerations

Tenant and project permissions

Productsup API authentication and authorization details must be confirmed for the tenant’s current API version and account configuration. Do not reuse a Productsup user login, channel credential, or marketplace credential as an API credential unless Productsup explicitly documents that behavior.

Credential protection

Store Productsup credentials, tokens, and endpoint configuration in Martini secrets or environment configuration rather than workflow source code. Use separate credentials for development, testing, and production and apply the least privilege available for projects, sources, channels, and product-data operations.

Transport and callback security

Use the authentication and transport protections documented by Productsup. If callbacks are enabled, verify the documented authentication or signature mechanism, event identity, duplicate behavior, and replay controls before treating a notification as authoritative.

Operational considerations for Productsup integrations

Rate limits and throughput

Confirm Productsup request quotas, payload limits, concurrent-job limits, and feed-size constraints. Use pagination, bounded batches, throttling, and retry backoff for rate-limit and transient server responses.

Asynchronous processing

Separate submission acceptance from completed product processing. Persist import, export, or job identifiers when available and define polling intervals, pending timeouts, and escalation behavior.

Idempotency and reconciliation

Use stable product keys, deterministic payloads, correlation identifiers, and persisted checkpoints to avoid duplicate submissions. Reconcile source, submitted, accepted, rejected, and unresolved counts rather than relying only on HTTP success.

Schema and media handling

Maintain explicit mappings for product attributes, channel-required fields, currencies, locales, units, image URLs, and landing pages. Confirm whether each implementation uses upload endpoints, reachable URLs, SFTP, or another file-transfer method; do not assume Productsup is a general-purpose binary attachment store.

Testing and change management

Confirm the Productsup API version and deprecation policy, isolate Productsup-specific mappings, and test changes against a non-production project. Monitor channel requirements, taxonomies, required attributes, and validation rules as they evolve.

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

Orchestration beyond a script

Martini provides a workflow layer for coordinating Productsup with PIM, ERP, commerce, marketplace, advertising, database, and operational systems. It can manage scheduled retrieval, batch submission, status polling, callback handling, validation, routing, and reconciliation in one maintainable integration flow.

Reusable transformation and business rules

Martini separates canonical product models from Productsup-specific mappings and channel rules. This makes it easier to normalize currencies, locales, identifiers, availability, media references, and custom attributes without duplicating logic across point-to-point scripts.

Operational reliability

Martini can classify errors, apply controlled retries, persist checkpoints, prevent duplicate processing, and expose or consume APIs where required. These capabilities provide a clearer operational boundary than isolated scripts while retaining flexibility for custom logic when the Productsup API or feed contract requires it.

Frequently asked questions

How can Productsup be integrated with enterprise systems?

Productsup can be integrated through its authenticated REST APIs, feed-oriented bulk or asynchronous processing where available, and supported file or feed exchange. Productsup may also provide selective event or callback capabilities, but broad webhook coverage should be confirmed for the tenant. Enterprise workflows can connect PIM, ERP, commerce, marketplace, advertising, database, and operational systems around Productsup.

Can Martini integrate with Productsup?

Yes. Martini can integrate with Productsup by consuming its REST API, processing supported feed or file exchanges, orchestrating scheduled synchronization, and receiving confirmed callbacks when the required event capability is available. Martini can also map product attributes, validate data, track processing identifiers, and coordinate surrounding enterprise systems.

Do I need a connector to integrate Productsup with Martini?

No. A dedicated Productsup connector is not required. Martini can use Productsup’s confirmed native integration mechanisms, including REST APIs, supported files or feeds, and any tenant-specific callback or notification capabilities that Productsup documents.

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

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

Which Productsup integration methods should an enterprise use?

REST APIs are the primary mechanism to investigate for platform administration and product-data workflows. File or feed exchange is particularly relevant for large catalogs, scheduled delivery, exports, and recovery. Bulk or asynchronous capabilities should be verified for the applicable API, and callbacks should be used only when the event types and delivery semantics are confirmed.

Are Productsup webhooks or callbacks available?

Productsup supports event-driven or notification-oriented capabilities in some workflows, but broad coverage across products, imports, exports, projects, and channels was not confirmed. The event types, callback configuration, authentication, retries, duplicate behavior, and replay options must be checked for the customer environment. Martini can use scheduled polling when no suitable callback exists.

How does Martini synchronize Productsup data with other systems?

Martini can run scheduled or event-driven workflows that retrieve Productsup resources or feeds, handle pagination and batches, map data to a canonical model, validate attributes, and write results to target systems. Checkpoints, timestamps, cursors, import identifiers, or export identifiers can support incremental synchronization and periodic reconciliation.

How does Martini handle Productsup errors, retries, and duplicates?

Martini can distinguish transport failures, rate limits, timeouts, Productsup validation errors, and downstream channel rejections. Transient failures can be retried with controlled backoff, while non-retryable data errors are routed for correction. Stable product keys, correlation identifiers, deterministic payloads, and persisted checkpoints help prevent duplicate submissions and support reconciliation.