Step 1: Inbound Template Details

Details of the Inbound Call Template

In the app, select ‘Inbound Call Templates’ in the navigation bar. Then select ‘New:’

In the template details you will need to populate various fields as defined below.

Method

Select the HTTP Method that this inbound call template can accept. You can choose any of the standard methods: GET, PUT, PATCH, POST and DELETE

Active (Optional)

Mark this checkbox if the template should be live and accepting inbound calls. When you mark an inbound call template as Active, you are using one of your template counts as described in your Declarative Webhook subscription.

NOTE: You don’t need to have your template Active to test it. You can test any inbound call template via the “Test Inbound Call Template” button. We will review this in a later step.

Call Authentication

This sets how this inbound call template can be accessed by the external system

• No authentication. URL is available publicly: If this option is selected, the template will have a public URL where any system can send calls without authenticating. This can be used for accepting webhooks from other systems.
• Authenticated through the Salesforce REST API OAuth: This will generate a private URL that cannot be accessed unless the system is authenticated into Salesforce’s API. The external system needs to be capable of authenticating into Salesforce using the API. See details about Salesforce REST API Authentication.
• Basic Authentication (Username and Password): If this option is selected, the user is prompted to provide the expected Username and Password. If an external system makes a call to this template and the Authorization header does not contain the Basic authentication format with the expected username and password, the response is automatically set to 401 (Unauthorized) or 403 (Forbidden), based on user’s selection.
  • 
• Bearer Token Authentication: If this option is selected, the user is prompted to provide the expected Bearer Token. If an external system makes a call to this template and the Authorization header does not contain the expected Bearer token value, the response is automatically set to 401 (Unauthorized) or 403 (Forbidden), based on user’s selection.
  • 
• API Key Authentication: If this option is selected, the user is prompted to provide the expected header name as well as the expected API Key value in the specified header. If an external system makes a call to this template without the correct header and value, the response is automatically set to 401 (Unauthorized) or 403 (Forbidden), based on user’s selection.
  • 
• Authenticated with SHA-256 Signed Body: If this option is selected, the user is prompted to provide the expected header name where the signature is expected to arrive, as well as a private key to verify the signature. If an external system makes a call to this template, the request body needs to be signed using the SHA-256 algorithm and the private key and sent into the expected header. The signature is accepted as base64 or hex. If the signature does not match, 401 (Unauthorized) or 403 (Forbidden) is returned (based on user’s selection).
  • 
• Custom Authenticated using an Apex Class: If the authentication verification is too complex, you have the option to provide an apex class that can verify the authentication based on headers and request body.
  • 
  • The class used needs to be global and extend the d_wh.InboundAuthenticationCallable2 abstract class. Below is an example class that can be used to verify the authentication.

    global class TestCallable extends d_wh.InboundAuthenticationCallable2 {
    
        global override Boolean Verify(Map<String, String> parameters, Map<String, String> headers, String body) {
    
            // Add code to verify authentication based on headers and body
            // return headers.get('custom-auth-header') == '346tecerw34cew';
        }
    }

    The parameters parameter contains a map of all URL parameters.
    The headers parameter contains a map of all headers.
    The body parameter contains the received request body as string. If the request body is binary and cannot be converted to UTF-8 string, it will be base64 encoded and the body parameter will contain the base64 encoded request body.
    The response should be a boolean. True means the authentication was successful, false means it could not be verified successfully.

In case the authentication fails, return code:

If you select one of the custom authentication methods in the “Access Type” field above, you can select what HTTP code to respond with in case of authentication failure. You have a choice between “401 Unauthorized” and “403 Forbidden“. If you are not sure which one to use, 401 is the safer choice, used by most applications.

Template Name (Required)

This is the title of your template. You should name this something that you will be able to identify easily that is based on what the inbound call will do.

Main Object (Optional)

A list of your SFDC standard and custom objects will appear in this dropdown menu. The “Main Object” is the object the inbound call will consider as the main record.