Repository navigation
MPT-27353 add a webhook example in mpt-extension-python-template - #154
Conversation
Register a validatePurchaseOrderDraft webhook with one criteria per configured product, so the Extensions Service creates one platform webhook per product on the same route. The handler clears the errors of the previous answer, validates the agreementType ordering parameter and, when the value is not a known one, answers 200 with the order carrying an error on the parameter and a summary error on the order itself. Depend on mpt-extension-sdk 6.9, the first release that ships the webhooks API, replacing the locally built wheel that was pinned through tool.uv.sources while the API was unreleased. Move the mypy pre-commit hook to the same version, because it type-checks in its own environment. Cover the handler with unit tests, add the accepted and rejected webhook calls to the Postman collection, and describe the example in docs/examples.md.
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Webhook handler and registration backend/mpt_extension_python_template/routers/webhooks/order.py, backend/mpt_extension_python_template/app.py, .pre-commit-config.yaml, backend/pyproject.toml |
Adds the order validation webhook and registers its router with the application. The handler clears prior errors, accepts a missing agreement type or New and Migration, and adds order-level and parameter-level errors for other values. Updates the mpt-extension-sdk version pins to 6.9.*. |
Validation and registration tests backend/tests/routers/test_webhooks.py, backend/tests/test_app.py, docs/testing.md |
Tests accepted and rejected agreement types, error clearing, parameter metadata, logging, route registration, and generated webhook metadata. Updates the documented test scope. |
Examples and architecture documentation backend/docs/postman_collection.json, docs/architecture.md, docs/examples.md |
Adds Postman examples for accepted and rejected agreement types. Documents the webhook route, registration, validation behavior, and response semantics. |
Estimated code review effort: 3 (Moderate) | ~20 minutes
Merge Risk: 
Minimal · up to 3cf5d
-
The webhook behavior and registration are covered by the supplied tests, with no identified issue blocking merge.
Pre-merge checks: 
3
-
Full details: Documentation Up To Date
-
Explanation
The PR updates the matching documentation.
docs/architecture.md:14,28-34documents the new webhook component and route.docs/examples.md:18-20,32,142-186documents registration, criteria, validation behavior, responses, and local Postman usage.docs/testing.md:16-21updates the test scope. This follows the repository documentation responsibilities insoftwareone-platform/mpt-extension-skillsat commit9d8bcd7148e89c32545cf1ad5f80370036713e25,standards/documentation.md:50-68. The SDK and pre-commit dependency updates do not require additional behavior documentation.
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Tip
🎯 Customize your risk assessments
-
Guide how CodeRabbit assesses merge risk and security architecture risk. Highlight sensitive changes and explain your security boundaries using Merge Risk Instructions and Security Risk Instructions in your review settings. Security architecture risk assessments require the Advanced plan or above.
✅ Automatic approvals, with your rules
-
Let CodeRabbit approve pull requests once required threads are resolved, pre-merge checks pass, and your risk limits are met. Enable Automatic approvals in review settings, with overrides for teams or file paths.
CodeRabbit Verify
- Run CodeRabbit Verify to test the changes in this pull request.
|



🤖 AI-generated PR — Please review carefully.
Adds the webhook example the template was missing, so a new extension starts from a working validation webhook.
What was done
The webhook.
routers/webhooks/order.pyregisters avalidatePurchaseOrderDraftwebhook with one criteria per product inMPT_PRODUCTS_IDS, so the Extensions Service creates one platform webhook per product on the same route.The handler clears the errors of the previous answer with
without_errors()— otherwise the wizard keeps showing them after the user fixes the value — then validates theagreementTypeordering parameter. An unknown value comes back as a200carrying the rejection at both levels the SDK offers:with_ordering_error(...)on the parameter the user has to fix, andwith_error(...)as a summary on the order. An order without that parameter is accepted, because there is nothing to validate.The SDK dependency. The template now depends on
mpt-extension-sdk==6.9.*, the first release that ships the webhooks API. This replaces a locally built6.8.99+webhookswheel that was pinned through[tool.uv.sources]while the API was unreleased — that wheel lives under a gitignoredvendor/, so the pin could never have resolved in CI. The mypy pre-commit hook pins the SDK separately in its own isolated environment, so it moves to6.9.*in the same change.Tests and docs. Seven unit tests cover clearing, acceptance, the absent parameter, both rejection levels, the
required/hiddenconstraints thatwith_ordering_errorsets, and the log line; two existing tests already cover route registration and the generated metadata. The two webhook calls — one accepted, one rejected — are added to the Postman collection, anddocs/examples.md,docs/architecture.mdanddocs/testing.mddescribe the example.Testing
pytest— 49 passed, handler at 100% coverageruff format --check,ruff check,flake8(wemake),mypy,uv lock --check— all cleanmpt-ext meta generate— thewebhooks:block is produced with one entry per configured productFrontend checks were not run: this change is backend and documentation only.
agreementTypeor the valuesNewandMigration. For other values, returns parameter-level and order-level errors.mpt-extension-sdkand the mypy pre-commit hook to6.9.*.