HTTP and HTTPS Receive Endpoint Settings

HTTP and HTTPS receive endpoint settings configure where to receive messages in the following context:

  • Source at host

    Source endpoint in an outbound message flow that receives application JSON and XML messages from the backend systems

Only a host can own HTTP and HTTPS receive endpoints.

Create HTTP and HTTPS receive endpoints by configuring these settings on the host page:

Name Description Required

Endpoint Name

Automatically generated name used to identify the endpoint, which you can subsequently modify manually.

Yes

Owner

Host that owns the endpoint.

Yes

Protocol

Protocol selected in the Protocol field of the New endpoint. You cannot modify this value.

Yes

Description

User-supplied value that describes the purpose of the endpoint.

No

URL

HTTP or HTTPS address where you receive outbound source messages from backend systems.

Yes

Response timeout (in milliseconds)

Response timeout period in milliseconds. The default is 15000.

Yes

Authentication type

Type of authentication method used to protect the HTTP receive service.

Yes

Basic authentication

User name and password that protects the HTTP listener.

After saving your new or reconfigured endpoint, you cannot subsequently retrieve or modify the password.

The backend applications that send JSON or XML payloads to the HTTP or HTTPS receive endpoint must pass the credentials in the HTTP request header.

Yes

API Key

API key for the HTTP listener.

After selecting API Key in the Authentication type list, specify the HTTP header name and API key to protect the HTTP listener. After saving your new or reconfigured endpoint, you cannot subsequently retrieve or modify the API key.

The backend applications that send JSON or XML payloads to the HTTP receive endpoint must pass the API key in the HTTP request with the configured HTTP header name.

Yes

HTTP or HTTPS Receive Endpoint URL

You can deploy an HTTP or HTTPS receive endpoint on a public port, on a private port, or on-premises.

Deploy to CloudHub on a Public Port

When an HTTP or HTTPS receive endpoint is deployed with the private port configuration enabled, the endpoint application is deployed on the public HTTPS port (8082), with the traffic routed through the shared load balancer. The value in the URL field is automatically generated when you deploy a message flow that uses this endpoint to CloudHub.

You can view this URL by selecting the receiving endpoint from your deployed message flow or by clicking the endpoint name from the endpoints list. You can share this URL with the partners that send HTTP or HTTPS messages to this endpoint.

If your organization uses CloudHub VPC without a dedicated load balancer (DLB), your organization’s platform administrator can configure the necessary VPC firewall rules to allow specific IP addresses of your partners to access the endpoint.

Deploy to CloudHub on a Private Port

When an HTTP or HTTPS receive endpoint is deployed with the private port configuration enabled, the endpoint is deployed to the private HTTPS port (8092) and the internal URL of the endpoint appears on the the Message Flow or Endpoint detail page.

You can also set CloudHub to automatically deploy newly created HTTP, HTTPS, and AS2 endpoints to a private port via the CloudHub Deployment Settings.

After deploying the first message flow using the HTTP or HTTPS receive endpoint configuration, you can view the runtime application name for the endpoint from the Endpoint details page or from the Receive section of your message flow. To configure URL mapping rules in the DLB to forward HTTP or HTTPS messages received from your backend applications to outbound B2B message flows, provide the application name to your organization’s platform administrator.

If your backend processes consuming the HTTP or HTTPS receive endpoints are also running inside the same VPC, they can call the internal URL directly.

If your backend processes consuming the endpoint are in a different network, your organization’s platform administrator add your partner’s IP addresses to a list of allowed addresses in the DLB settings to allow specific IP addresses to access the endpoint.

The external URL that you can share with your partners is https://{DLB-domain}/{Input-path}/{base-path}/{message-type}.

For example, if the name of your DLB domain is mythical.lb.anypointdns.net, the runtime application name is b2b-inbound-http-ognq, and the base path you configured in the HTTPS receive endpoint is send2, then your administrator adds a URL mapping rule in the DLB settings to forward incoming requests to the runtime application within your VPC:

URL mapping rules for HTTPS in the DLB settings

Using the following values, depending on your environment:

  • The external HTTPS receive endpoint URL is https://mythical.lb.anypointdns.net/apm/qa/outbound/send2/.

  • Your backend applications send the application JSON/XML messages for your outbound message flows from https://mythical.lb.anypointdns.net/apm/qa/outbound/send2/{message-type}.

  • If enterprise-ob-po-ack is the message type, your backend systems post the HTTPS requests to the URL https://mythical.lb.anypointdns.net/apm/qa/outbound/send2/enterprise-ob-po-ack.

Deploy to an On-Premises Mule Instance

If you are deploying to an on-premises Mule instance with a firewall and load balancer, work with your hosting or network security team to obtain the externally accessible DNS or name of the host where the Mule instance is running, and replace {runtime_host} in the URL with the DNS name of your host. For example, if your DNS host name is b2b.mycompany.com, the receiver URL is https://b2b.mycompany.com/base-path/, and your backend systems post the HTTPS request to https://b2b.mycompany.com/base-path/{message-type}.

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub