Add Zenkraft Shipping v1.0.0

[svetlanakostadinova]

Commerce App Submission

App Name: zenkraft-shipping
Display Name: Zenrkaft Shipping
Domain: shipping
ISV/Vendor Name: Zenkraft
Version: 1.0.0

Type of Change

• New app submission
• App version update
• Bug fix for existing app
• Documentation update
• Other (please describe):

Architecture

• UI-only (storefront-next only)
• Backend-only (cartridges/impex only)
• Fullstack (both UI and backend)

Description

This commerce app integrates the Zenkraft rate API with Storefront Next storefronts. The backend cartridge (int_zenkraft_sfnext) fetches real-time rates and estimated delivery dates from carriers at checkout and persists them to session and shipment custom attributes. The Storefront Next extension replaces the standard shipping options step at checkout with a component that displays those enriched shipping methods.

Checklist

Required Files

• ZIP file name follows format: {appName}-v{version}.zip
• ZIP contains single root folder: commerce-{appName}-app-v{version}/
• Root manifest.json includes all required fields (id, name, description, iconName, domain, version, zip, sha256)
• App icon exists in ZIP at commerce-{appName}-app-v{version}/icons/ (CI extracts automatically)
• Icon filename in ZIP matches iconName field in root manifest
• Translations added to commerce-apps-manifest/translations/en-US.json (minimum requirement)
• catalog.json included for new apps only (with INIT values)
• If updating existing app: Did NOT add new versions to catalog.json (CI handles this)
• If deprecating a version: Added "deprecated": true to existing version in catalog.json

Version and Hash Validation

• version in manifest.json matches version in commerce-app.json
• zip field in manifest.json matches actual ZIP filename
• sha256 in manifest.json matches computed hash of ZIP file
• SHA256 hash verified with: shasum -a 256 [path-to-zip]

ZIP Content Validation

• No junk files (.DS_Store, __MACOSX, Thumbs.db, hidden files)
• No registry path prefixes in ZIP (no tax/, domain/, etc.)
• Required files present: commerce-app.json, README.md, app-configuration/tasksList.json
• All referenced scripts/files exist
• No absolute paths in code
• No hardcoded credentials

Directory Structure

• App located at {domain}/{appName}/ where {appName} matches the "id" field in manifest
• Only ZIP, root manifest.json, translations, and catalog.json (new apps) are committed
• No extracted directories (commerce-*-app-v*/) committed
• No system files (.DS_Store, Thumbs.db) committed

Validation (if using Claude Code)

• Ran /validate-app skill
• Ran /validate-impex skill (if app contains impex files)
• Architecture-specific validations passed

Impex Files (if applicable)

• Service install file has matching uninstall file
• Uninstall files use mode="delete"
• All attribute IDs prefixed with app name
• No hardcoded production credentials in services.xml
• SITEID placeholder used (not actual site ID)
• XML files are well-formed and valid

Testing

• Tested installation in sandbox environment
• Verified service configurations work
• Tested site preferences are configurable
• Verified hooks execute correctly
• Tested UI components render properly (if applicable)
• Ran unit tests (if applicable)

Additional Notes

[github-actions]

@/home/runner/work/_temp/slack-marker.md

[shauryemahajanSF]

Lets point this at the release/26.8 branch instead of main.

[github-actions]

@/home/runner/work/_temp/slack-marker.md

[shauryemahajanSF]

Hey Svetlana, thanks for the PR! Some things to consider:

• Do we want explicit guarding against fetching fresh estimates on add to cart/change qty?
• Do we want portions of the Zenkraft estimate API call saved on the basket so that repeated GET shipping-methods and PUT shipping-methods calls when basket hasn’t changed can use them?
• We use dimWeight, dimWidth, dimHeight, dimDepth, length fields. Do we want to add them as part of the type-extension impex + config task to tell merchant to fill them?
• Not sure enableZenkraftShipping is used anywhere, we can remove it.
• Lets use the deliveryWindowStartAt, deliveryWindowEndAt fields if possible, similar to whats used in the app example below.

Example of the performance stuff above are here: cds-shipping-v1.0.5.zip

[shauryemahajanSF]

We should also include delivery estimates on PDP using the sfcc.app.shipping.estimate hook, which wires in to the new delivery estimates SCAPI. You can find an example here: cds-shipping-v1.0.5.zip

[github-actions]

@/home/runner/work/_temp/slack-marker.md

[github-actions]

@/home/runner/work/_temp/slack-marker.md

[github-actions]

@/home/runner/work/_temp/slack-marker.md

[shauryemahajanSF]

@svetlanakostadinova App looks good in shape, should be good to go in after these last comments are addressed:

We shouldn't need to implement any storefront next UI components for shipping apps, the template already handles what we need. To get the template to display what we want, this app should

1. Set the deliveryWindow field on ShippingMethodWO in thesfcc.app.shipping.quote hook, this will automatically show in the standard shippingOptions component in storefront next (if estimate is a single day instead of a range, just set both startAt and endAt to the same value).
2. For saving estimates, have the app register deliveryWindowStartAt and deliveryWindowEndAt fields on the Shipment object, and use those. This way, the order confirm page on template will automatically look at those fields and display the estimate.

Take a look at the shipping option and order confirm UI that is already present in the template to see what fields they use.