postDeploy script should have created doesn't exist.Zen Electron's Deployment says it succeeded, but no email arrives. By the end of this page, you can tell in one request whether the Connector is wired up, and you have seen an Order reach it.
Choose an install route
| Route | Environments it offers | Fits |
|---|---|---|
| Connect CLI | Sandbox, production, and preview | Trial Projects, scripted installs, and repeated test cycles |
| Connect API | Sandbox, production, and preview | Automation and CI pipelines |
| Merchant Center | Preview (a Connector requested for preview) and production (a published Connector) | Non-trial Projects, and people who install without scripting |
The Merchant Center has no sandbox install. If your Project is a trial, production isn't available either, so install a published Connector to sandbox with the CLI or the API.
Choose the Region and environment
supportedRegions, the Deployment's Region must be one of them, or the request fails with DeploymentUnsupportedRegion. You set europe-west1.gcp on the previous page.--region. Run commercetools connect deployment create --help to see the values your installed CLI accepts before you deploy to an AWS Region.preview, as on the previous page. A published Connector uses sandbox, the default, or production in a Project that isn't a trial. This module uses sandbox for Zen Electron's test installation. Environments defines each type.sandbox Deployment scales to zero when idle, so the first event after an idle period can miss the acknowledgment deadline and be redelivered, as the event contract explains. If one Order produces two confirmation log lines on sandbox, check for a cold start before you debug the handler.Install with the Connect CLI
CONFIG array from the previous page:commercetools connect deployment create \
--connector-key zen-order-confirmation \
--key zen-order-confirmation-sandbox \
--region europe-west1.gcp \
--type sandbox \
"${CONFIG[@]}"
manage_connectors_deployments and manage_api_clients scopes. Authorization describes both. Without manage_api_clients, the request fails with 403, because Connect can't generate the Connector's API Client.Deployed or Failed:commercetools connect deployment describe --key zen-order-confirmation-sandbox
Install with the Connect API
CONFIGURATIONS array:jq -n --argjson configurations "$CONFIGURATIONS" '{
key: "zen-order-confirmation-sandbox",
type: "sandbox",
connector: { key: "zen-order-confirmation" },
region: "europe-west1.gcp",
configurations: $configurations
}' | curl -sS --fail-with-body -X POST "$CONNECT_URL/$CTP_PROJECT_KEY/deployments" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d @- | jq '{key, type, status}'
connector: omitstaged: trueto reference the published Connector instead of the ConnectorStaged. The CLI has no flag forversion, so the status check below shows which version was deployed.configurations:applicationNamemust matchdeployAs[].nameinconnect.yaml.
Poll the status:
curl -sS --fail-with-body "$CONNECT_URL/$CTP_PROJECT_KEY/deployments/key=zen-order-confirmation-sandbox" \
-H "Authorization: Bearer $TOKEN" | jq '{status, connector: .connector.version}'
Install from the Merchant Center
- Connector: select Zen Electron order confirmation on the Organization connectors tab, and use Deploy on Production for the published Connector.
- Projects: on production, choose the specific Project that you're testing in.
- Fields: one for each key in your
connect.yaml:CTP_REGIONand the eight secured keys. Use the values from theCONFIGarray. The deployment step also displays the scopes thatinheritAsrequests for the generated API Client, so nobody enters commercetools credentials.
Verify the resource, not the status
Deployed, the application is running. That doesn't prove that postDeploy created the Subscription. A postDeploy script that exits with an error can still produce a "Post-deployment setup succeeded" message, and the script's error output might not appear in the Deployment logs. A rejected environment variable, such as the Google Cloud destination validator, can cause exactly that.view_subscriptions or manage_subscriptions. The token from the previous page has both Connect and Platform scopes if you created the CLI's API Client as described in Start from the email template:curl -sS --fail-with-body -G \
"https://api.$CTP_REGION.commercetools.com/$CTP_PROJECT_KEY/subscriptions" \
-H "Authorization: Bearer $TOKEN" \
--data-urlencode 'where=key="ct-connect-email-delivery-subscription"' \
| jq '.results[] | {key, status, destination: .destination.type, messages}'
A working installation returns one Subscription:
{
"key": "ct-connect-email-delivery-subscription",
"status": "Healthy",
"destination": "GoogleCloudPubSub",
"messages": [
{
"resourceTypeId": "order",
"types": ["OrderCreated", "OrderImported"]
}
]
}
Read the result as follows:
- No result:
postDeploydidn't create the Subscription, whatever the Deployment says. Check the destination validator change and theinheritAsscopes inconnect.yaml, then redeploy. statusother thanHealthy: the Subscription exists, but delivery has a problem. Look up the value in SubscriptionHealthStatus to see whether delivery is still being retried. Operate a Deployment covers what to do.messageswith Customer types: the Deployment runs a tag from before Implement and test the event app to the contract. Checkconnector.versionon the Deployment.destinationisSNS: the Project is in an AWS Region. The template doesn't decode the SNS envelope, as noted in Implement and test the event app to the contract.
commercetools-connect skill's lifecycle-scripts reference states the same rule: verify registration by querying the resource, not by status: "Deployed". For this symptom, start with the resource rather than deployment logs, because the logs might not contain the script's output.Trigger an Order
OrderImported Message, which the Connector handles as a confirmation. Create Order by Import needs the manage_orders scope and creates an Order without a Cart:ZE-MON-4K, or choose the SKU of an existing Product Variant in your Project. Order Import resolves variant.sku against a Product Variant; the SKU in the request does not create one. If you prepare the Product through the API instead, that setup needs manage_products in addition to the manage_orders scope used for the import. Set SKU to the actual Variant SKU before running the request:ORDER_NUMBER="ZE-$(date +%s)"
SKU="ZE-MON-4K" # Replace with the SKU of a Product Variant in your Project.
curl -sS --fail-with-body -X POST \
"https://api.$CTP_REGION.commercetools.com/$CTP_PROJECT_KEY/orders/import" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d "{
\"orderNumber\": \"$ORDER_NUMBER\",
\"customerEmail\": \"learner@example.com\",
\"totalPrice\": { \"currencyCode\": \"AUD\", \"centAmount\": 4900 },
\"lineItems\": [
{
\"name\": { \"en-US\": \"Zen Electron 4K monitor\" },
\"variant\": { \"sku\": \"$SKU\" },
\"quantity\": 1,
\"price\": { \"value\": { \"currencyCode\": \"AUD\", \"centAmount\": 4900 } }
}
]
}" | jq '{id, orderNumber}'
orderNumberis generated per run, because repeating a number fails the import.customerEmailis the recipient. Without it and without acustomerId, the template skips the Order.namehas anen-USkey, because the template reads line item names from that locale only.
commercetools-ai-plugins plugin, give your server a name other than commerce-mcp. The plugin defines a server with that name, and the clash disables your tools.Find the work in the logs
mail-sender application:commercetools connect deployment logs \
--key zen-order-confirmation-sandbox \
--application mail-sender
Email provider stub: email not sent {"sender":"orders@example.com","templateId":"order-confirmation","lineItemCount":1}
Order confirmation handed to email provider {"messageType":"OrderImported","resourceId":"<order-id>","sequenceNumber":1}
y/n prompt for the next page, which can look like a hang. In the Merchant Center, the same logs are on the installation's App logs tab.If no line appears within a few minutes:
- Wait a minute after a new Deployment. Deliveries in the first minute can be rejected with
401while Connect sets up push authentication. Pub/Sub retries them, and they then succeed. - Check for a cold start. On sandbox, the first Message after an idle period can arrive late.
- Check the Subscription again. If it's missing or unhealthy, the Message never reached the application.
Worked example: install Zen Electron's Connector
- Install
zen-order-confirmationto sandbox withdeployment createand wait forDeployed. - Query the Subscription by key: one result,
Healthy,GoogleCloudPubSub, and the two Order Message types. - Import an Order with a new order number.
- Find one
Order confirmation handed to email providerline with the imported Order's ID.
One Order produced one stubbed send. Zen Electron has proved the full path, from Order to Subscription to Connector, without trusting the Deployment status.
event application and logs a stubbed provider call; it doesn't test actual email delivery or cover service and job applications. If you administer a Connector with those application types, follow Test applications locally for service, event, and job endpoint tests before publishing. Test each application against its own contract rather than treating this event-only check as a general installation test.Keep this Deployment. The next page operates it.
Key takeaways
- Installing your own private Connector is the same Client task as installing a public one.
- The Merchant Center offers preview and production installs. Use the CLI or the API for sandbox, which is the route for trial Projects.
- Deploy in the Project's Region, which Connect recommends, and within the Connector's
supportedRegions. Connect supports Google Cloud and AWS Regions. - A Deployment can report success when
postDeployfailed. Prove the installation by querying the resource it creates, such as the Subscription, by key. - Trigger the Connector with a real platform event, such as an imported Order, and confirm the work in the Deployment logs.
- Expect delays right after deployment and after a sandbox cold start before you debug.