Settings live on the instance form (3PL Connector > Configuration > Instances). Only Admins can change them, and every change is tracked in the instance's chatter. Settings whose capability the provider does not support are hidden throughout.

Header and identity

Name. The label used everywhere - dashboard card, dropdowns, chatter, the Sync Log. Must be unique per company.

Provider. Which 3PL this instance talks to. Locked once the instance leaves Draft - create a new instance rather than repointing an existing one, so history stays attached to the right 3PL.

Environment - Sandbox / Staging vs Production. Controls the default API host and shows as a coloured badge (blue Sandbox, green Live) on the dashboard and instance list. Locked while the instance is Active. Example: run "the 3PL (Sandbox)" and "the 3PL Live" as two instances; test risky changes on the sandbox one first, with zero chance of touching live orders.

State. Draft > Connected > Active (and Paused). Draft means untested credentials. Connected means Test Connection succeeded but the scheduler is not running. Active means scheduled flows run automatically. Paused stops the scheduler but keeps manual operations available.

• Test Connection - makes a real, harmless API call and logs it.
• Activate - requires at least one warehouse mapping; starts the scheduler.
• Pause - suspends scheduled syncs. Nothing queues up dangerously: when you resume, polls simply pick up the current remote state.
• Reset to Draft - for re-keying credentials or repointing hosts.

Connection tab (Admins only)

API Base URL. Pre-filled from the provider and environment. Override only if your 3PL gives you a dedicated host.

Credentials. Fields shown depend on the provider's authentication type (API key, Basic, bearer token with refresh). The provider-specific help box on this tab states exactly what goes in each field. Credential values are never shown to non-Admins and are always redacted in Sync Log request headers.

Webhook URL / token. Some 3PLs can push events instead of waiting to be polled. Give the 3PL the displayed URL (it embeds a secret token). Anything received is logged against the instance and triggers a status refresh for any order the payload references. Polling remains the safety net - a missed webhook is caught by the next poll, so webhooks are an accelerator, never a dependency. Amazon offers no plain-webhook push at all, so Amazon MCF instances are kept current by polling alone.

Register Webhooks (shown for providers that accept webhook subscriptions via API - currently ShipHero). One click subscribes the 3PL's push events to the instance's webhook URL: Shipment Update, Order Canceled, Inventory Update, Return Update and PO Update. From then on despatches, remote cancellations, stock movements, returns and inbound receipts trigger an immediate refresh instead of waiting for the next poll. The subscriptions actually registered are confirmed in the instance chatter; scheduled polling stays on as the safety net exactly as described above.

Provider-specific connection fields. Some adapters add their own fields next to the environment - for example, ShipHero instances choose the carrier source for Fetch Carriers (Use Experimental Functionality or Use Historical Orders - exactly one; see Carrier mappings). Fields only appear for the provider they belong to.