Cirro Endpoints

Camel → Cirro / eLogistic. Calls go through the cm-cirro-sys proxy; the per-env business mappings (warehouse, shipping method) live in cm-edi-prc.

Host per environment

dev / qa / stage all share the Cirro UAT host; only prod is live Cirro.

Environment	Cirro API host
dev/qa/stage	uat-oms-elogweb.eminxing.com
prod	oms.elogistic.com

Cirro account is a secret, not a host

Which Cirro account a call uses (EL2837 / EL2835) is set by cirro.app.key / cirro.app.token (Key Vault, redacted) — not by the host. If you need to confirm the account for an env, probe it live via /order/detail.

Endpoints

Prepend the per-env host above. All under /v1.

Call	Path
Order detail	/v1/order/detail
Order create	/v1/order/create
Order create — B2B	/v1/order/create-b2b
Plan-order create (prepack)	/v1/plan-order/create
Auth / get-access-token	/v1/auth/get-access-token

Business mappings (cm-edi-prc)

These are the values that differ between UAT and live fulfillment — the classic prod-vs-nonprod gotcha lives here.

	dev	qa	stage	prod
warehouse-code	USEA	USEA	USEA	USWE
shipping-method	MORKRM	MORKRM	MORKRM	PPS_PENDING_ROUTING

The nonprod Config Server lies about prod shipping-method

The prod-profile row in the nonprod Config Server table says shipping-method = Mapping_Transfer. That is a stale mirror. The live prod Config Server serves PPS_PENDING_ROUTING — that's the real value. Always read prod from the prod Config Server.

Inbound Cirro webhooks → Camel

Cirro posts ship/pack confirmations onto a Service Bus queue consumed by cm-ext-service-exp. Prod is not wired in the Config Server.

Queue	dev	qa	stage	prod
fulfillment-confirmation-cirro	int-dev-fulfillment-confirmation-cirro	int-qa-fulfillment-confirmation-cirro	int-stage-fulfillment-confirmation-cirro	—
fulfillment-request-cirro	int-dev-fulfillment-request-cirro	int-qa-fulfillment-request-cirro	int-stage-fulfillment-request-cirro	—

---

Related: EDI B2B pipeline · Cirro B2B overview · Endpoint map home