Home/Field Guide/Client extensions & APIs
CONCEPT 16
Microservice extensions and webhooks
Integrate a remote service with explicit identity, retry semantics, and failure recovery.
Trace both directions
Liferay can invoke a remote service through a supported Object action or integration type. The service can also call back into Liferay’s headless APIs. Treat these as separate trust relationships. Specify how the remote service validates incoming authentication, and use a scoped OAuth application and effective identity for outbound API calls. Confirm the specific credential and token behavior in the extension’s type reference.
Design for delayed fulfillment
When a request is approved, the Partner Hub can pass its ERC and a transition identifier to a service. The service durably accepts work, deduplicates the transition, and returns an appropriate acknowledgement. A worker contacts the ERP and writes back fulfillment status through the generated API when it has permission. Keep an audit trail so a reviewer can distinguish “approved,” “queued,” and “fulfilled.”
| Failure | Expected handling |
|---|---|
| Duplicate approval delivery | Ignore or resume the existing work by event key |
| ERP times out | Reconcile by business key before retrying |
| Write-back token loses access | Surface the failure and retry after the grant is restored |
| Portal approves while the service is unavailable | Confirm the target trigger’s failure behavior and use a reconciliation path |
Deploy and verify
Validate the registration descriptor, network reachability, TLS, secret rotation, and retry behavior from the environment where each call originates. Use timeouts at the boundary and redact tokens and sensitive fields from logs. Test in both directions using an allowed case and a denied case. Document where the code runs and who can replay work.