Asynchronous callback not triggered in order fulfillment after external API post

[tom_specialist]

We have an order fulfillment integration where Fusion posts order data to an external shipping system via REST API. The external system is supposed to send an asynchronous callback to Fusion when shipping labels are generated, but the callback never reaches Fusion even though the external system logs show successful HTTP 200 responses.

Our external system posts to the callback URL we registered in Fusion’s API gateway configuration. The URL format is: https://[instance].oraclecloud.com/fscmRestApi/callbacks/orderShipment. We’ve verified the external system can reach this URL (ping succeeds, no firewall blocks), but Fusion shows no record of receiving the callback in the integration logs.

Is there specific endpoint configuration needed in Fusion to accept asynchronous callbacks? Do we need to register the external system’s IP address or configure authentication differently for inbound callback requests? The initial outbound API call from Fusion works fine - it’s only the return callback that’s failing.

[sharon_arch]

We’re not including OAuth tokens in the callback because we thought callbacks were pre-authenticated based on the registered URL. If OAuth is required, how does that work? The external system would need to obtain a token before making the callback, which adds complexity and latency. Is there a way to whitelist the external system’s IP so callbacks are trusted without token validation?

[ritu_expert]

Let me provide a comprehensive solution addressing all three focus areas, as async callbacks in Fusion require careful configuration across multiple layers.

Async Callback Troubleshooting: The root issue is likely a combination of incorrect endpoint configuration and authentication setup. Let’s debug systematically:

1. Verify Callback Registration: In Fusion, navigate to Setup and Maintenance → Integration → REST Service Catalog. Search for “orderShipmentCallback” (or similar name for your fulfillment integration). Check the registered endpoint details:

   • Status must be “Active”
   • HTTP Method must be POST
   • Authentication Type should show “Webhook Signature” or “OAuth 2.0”

2. Test Callback Endpoint Directly: Use a tool like Postman to POST to your callback URL with a sample payload. This isolates whether the issue is endpoint configuration or external system behavior. If Postman fails with 401/403, it’s authentication. If it fails with 404, the endpoint isn’t registered correctly.

3. Check Integration Logs: The fact that Fusion shows “no record” of callbacks is key. Go to Tools → Integration Audit → Inbound Messages. Filter by service name and time range. If messages appear with “Authentication Failed” status, it’s OAuth issues. If messages don’t appear at all, the external system isn’t reaching Fusion’s gateway.

API Gateway Configuration: Fusion’s API Gateway for inbound callbacks requires specific setup:

1. Enable Inbound Integration: In the Order Fulfillment setup, there’s a checkbox for “Allow External Callback Integration” that must be enabled. This is often missed because it’s separate from the outbound API configuration.

2. Register Callback Service: Create a callback service definition:

   • Go to Setup → Integration → Callback Services
   • Create New Service: “ShipmentCallback”
   • Base URL: Leave empty (auto-generated by Fusion)
   • Resource Path: /orderShipment/callback
   • Authentication: Select “Webhook Signature” (recommended) or “OAuth 2.0”

When you save, Fusion generates the actual callback URL. Copy this URL and provide it to your external system - don’t construct it manually.

3. Webhook Signature Setup (if using this auth method):

   • Fusion generates a shared secret key when you create the callback service

   • Copy this key and configure it in your external system

   • External system must include a signature header in callback requests:

     
     X-Fusion-Signature: HMAC-SHA256(payload + timestamp + secret)
     

   • Fusion validates this signature before processing the callback

4. OAuth 2.0 Setup (alternative auth method):

   • Create a dedicated integration user in Fusion for callback authentication

   • Grant this user the “Order Fulfillment Callback Integration” role

   • Generate OAuth credentials: Client ID and Client Secret

   • Configure external system to request tokens:

     
     POST https://[instance].oraclecloud.com/oauth2/v1/token
     grant_type=client_credentials
     client_id=[your_client_id]
     client_secret=[your_client_secret]
     

   • Include token in callback: Authorization: Bearer [access_token]

Endpoint Accessibility: Even with correct configuration, network-level issues can block callbacks:

1. Verify External System’s Outbound Access: The external shipping system must be able to make outbound HTTPS calls to Oracle Cloud. Some corporate firewalls block outbound connections to cloud services. Test with:

   curl -v https://[your-fusion-instance].oraclecloud.com/fscmRestApi/health
   
   

   If this fails from the external system's network, you have a firewall issue.

2. **Check Oracle Cloud Access Control**: In Oracle Cloud Console (OCI), verify that your Fusion instance's security list allows inbound HTTPS (port 443) from the internet. This should be enabled by default for SaaS instances, but custom VCN configurations might restrict it.

3. **Validate DNS Resolution**: Ensure the external system can resolve your Fusion instance's hostname. Some internal networks have DNS restrictions that prevent resolution of external domains.

4. **SSL/TLS Compatibility**: Oracle Cloud requires TLS 1.2 or higher. Verify the external system's HTTP client supports modern TLS. Older shipping systems sometimes use outdated SSL libraries.

5. **Proxy Configuration**: If the external system routes through a proxy, ensure the proxy is configured to allow HTTPS to *.oraclecloud.com domains. Some proxies intercept SSL traffic in ways that break OAuth token validation.

**Complete Implementation Steps:**

1. Enable callback integration in Order Fulfillment setup
2. Create callback service definition (use Webhook Signature for simplicity)
3. Copy the auto-generated callback URL from Fusion
4. Configure external system with:
   - Callback URL (exact copy from Fusion)
   - Shared secret for signature generation
   - Retry logic (3 attempts with exponential backoff)
5. Test with a sample shipment order
6. Monitor Integration Audit logs for callback receipt

If callbacks still fail after this configuration, enable debug logging:
- Go to Tools → Diagnostic Dashboard → Integration Diagnostics
- Enable "Trace Inbound REST Calls"
- Reproduce the issue
- Download trace logs and search for your callback URL
- Logs will show exactly why callbacks are rejected (auth failure, invalid payload, etc.)

One final critical point: the HTTP 200 response the external system receives might not be from Fusion - it could be from an intermediate proxy or load balancer. True confirmation of callback success is seeing the message in Fusion's Integration Audit logs with "Processed" status. If the external system gets 200 but Fusion shows nothing, the callback is hitting an intermediate layer that's not forwarding to Fusion properly.

[ritu_expert]

Oracle’s newer versions (23d included) do support webhook-style callbacks with pre-signed URLs for certain modules. You need to enable this in the Integration Setup. Look for “Webhook Configuration” under Order Management settings. When enabled, Fusion generates a unique signed URL for each outbound request that the external system can use for callbacks without separate authentication. The signed URL is valid for 24 hours and includes a verification token.

[karanmanager]

Let me add some context about endpoint accessibility since that’s often overlooked in async callback scenarios.