Skip to main content
Before you can publish a batch, its destination has to be configured. Publishing settings live under Settings › Publish Targets, where you register the targets your organization publishes to. This page covers the configuration step; for how batches flow through approval, scheduling, and promotion, see the publishing overview.

​
Targets are destination + environment

A publishing target is a place a batch can go. Every target is the combination of two things:
​
the system
Which system the batch publishes to — for example a VTEX store’s catalog or its pricing. Each destination has a target key (such as vtex_catalog or vtex_pricing).
​
which instance
Which instance of that destination — typically a QA store versus a production store.
Each destination + environment pair is configured once as an integration. A batch can then point at one integration, and MerchantOps publishes there once the batch is approved and its effective date arrives. Pointing at a target is optional, though — a batch approved without one stays active in MerchantOps but is never published.

​
Register a target

1

Open Settings › Publish Targets

Adding, editing, deleting, or testing an integration requires the pricing:approve permission — not settings:write. Viewing the targets requires pricing:read.
2

Choose the destination and environment

Pick the destination (for example a VTEX catalog or pricing target) and the environment it represents (for example QA or production).
3

Provide the destination's configuration

Supply whatever that destination needs to reach it — for a hosted storefront like VTEX, the store’s connection details and credentials; for a self-built connector, a poll-based setup where your own service holds the credentials instead.
4

Enable it

An enabled integration is available to point batches at. Disable an integration to stop routing new batches to it without deleting its config.

​
Publishing defaults: the timezone

The same screen carries one organization-wide default, in the Publishing Defaults card: your Default Publishing Timezone. Effective dates are picked as calendar days — “May 15” — but a publish happens at an instant. This setting is the rule that turns one into the other: a date picked anywhere in MerchantOps (price batches, catalog batches, the Set Prices dialog) means midnight on that day in this timezone, converted to UTC before it’s stored. That converted instant is what scheduled publishing compares against, so the timezone decides when a batch dated “May 15” actually fires. The default is America/New_York. Most US retailers set it to the most-eastern timezone they sell in, so a price is live everywhere by the time the day starts. The picker offers the common North American and UK zones plus UTC; a zone set outside that list still displays correctly.
Changing the timezone does not reschedule work that’s already dated. A batch stores the instant that was computed when its effective date was set, so existing batches still fire at that instant; the new zone applies to dates you pick from then on. Saved dates are displayed in whatever zone is set now, though, so moving to a zone further west can make an already-dated batch read as the previous day.

​
Permissions

Worth knowing if your organization builds narrowly scoped custom roles: the Publish Targets page is not governed by the settings permissions, with one exception.
The Publishing Defaults timezone on this page sits behind two different permissions today: the page only enables the timezone control for users with pricing:approve, while saving it requires settings:write. A user with just one of the two can’t change it — the control is disabled without pricing:approve, and saving is rejected without settings:write. Grant a role that carries both if it needs to manage the timezone.Without settings:read, the card can’t read your organization’s setting and falls back to showing America/New_York without saying so. Check the timezone from an account that has settings:read before trusting what’s displayed.

​
Multiple environments at once

You can keep several environments of the same destination enabled simultaneously — for example a QA store and a production store side by side. Each is its own integration with its own configuration and credentials, and each batch chooses exactly one. This is what makes promotion work: you publish and verify a batch against QA, then promote it to production without rebuilding it. Promotion requires the destination target to be enabled for the environment you’re promoting into. See the publishing overview for the promotion flow.
Because environments are configured separately, MerchantOps tracks publish outcomes per target and per environment. A QA publish and a production publish of the same product never collide — each carries its own result.

​
Per-target configuration

Some options are set on the integration itself rather than on individual batches. For a hosted connector like VTEX, this includes the store’s connection details and, optionally, per-target overrides such as a custom placeholder image for products that don’t yet have real imagery (see VTEX). For a self-built connector, the integration records that the target is poll-based; your own service holds any downstream credentials.
A target is optional for approval. You can create or approve a batch with No publish target — its records go active in MerchantOps but the batch is never published: scheduled publishing skips targetless batches, and Publish Now requires a target. Set a target on the draft only if you want the batch delivered downstream. See the publishing overview for the batch lifecycle.

Publishing overview

Batches, approval, scheduling, promotion, and status.

Build your own connector

Register a poll-based target for a system MerchantOps doesn’t ship support for.