Allowed Methods, URLs and Headers

Allowed Methods, URLs, and Headers

This page describes the HTTP related constraints imposed when configuring webhooks through SMSPortal.

Method Types

SMSPortal webhooks convey information using either an HTTP GET or POST method. Other HTTP method types (PUT, PATCH, etc.) are not supported.

Whether you use a HTTP GET or POST method, the webhook template is fully customizable. Along with variable substitution, customers can:

  • Insert their own constant data into the URL path / query parameters for either HTTP GET or POST webhooks.
  • Configure their own JSON request body structure and/or insert their own constant data into the JSON request body for HTTP POST webhooks.

This enhancement gives you greater control and flexibility when consuming our webhooks.

Specific request method details are discussed in the subsections below.

HTTP GET Requests

Data is conveyed through property substitution in the URL query string.

Example below:

PartData
URLhttps://www.your-example-domain.com?type=REDIRECT&customerRef=your_optional_reference_id&msgNumTo=27000000001&landingPageVersion=Version1&landingPageName=ExampleLandingTemplate
Request Bodynull

It is easy to debug these webhook types as all the data is conveyed in the URL. No request body is sent (Content-Length and Content-Type headers are omitted).

The URL length limited to 2000 UTF8 characters (~2 KB). Because of this, GET webhooks are typically NOT suited for very large payloads.

HTTP POST Requests

Data is conveyed through property substitution in a JSON-encoded request body.

Example below:

PartData
URLhttps://www.your-example-domain.com
Request Body{"phoneNumber":"27000000001","customerId":"your_optional_reference_id","type":"REDIRECT","interactionUtc":1735718400,"landingPageName":"ExampleLandingTemplate","landingPageVersion":"Version1","landingPageComponentId":"button_77"}

Because the data is conveyed in the body of the request and not the URL, these are slightly more challenging to debug and do require JSON parsing capability on the server that will receive the webhook.

SMSPortal's HTTP client will always set the following HTTP headers for HTTP POST requests:

Header NameHeader Value
Content-Typeapplication/json; charset=utf-8
Content-LengthCalculated as the character length of the JSON request body. (eg. 229)

Similar to the GET requests, the URL length remains limited at 2000 UTF8 characters (~2 KB). The JSON request body is limited to 4000 UTF8 characters (~4 KB), making POST requests more suitable for very large/complex payloads.

To help configure your integration, a preview of the JSON request body (with example data) is provided within the add/edit modal, giving you full visibility into the data structure being sent.

SMSPortal do not allow property substitution in the URL of a POST webhook request.

URL Constraints

The URL provides the address where the webhook request will be made. For security reasons, SMSPortal do impose some limitations on the URL.

These limitations are as follows:

  • The URL has to be HTTPS. HTTP is not supported.
  • The URL may not contain an IP address.
  • Domains must resolve to IPv4 addresses. IPv6 is not supported.
  • The URL must be compliant with the following RFC standards:
StandardDescription
RFC 1122Requirements for Internet hosts at the link, IP, and transport layers (the “communication layers”).
RFC 1918Defines private IPv4 address space for use inside private networks (e.g., enterprise internets).
RFC 2544Benchmarking methodology for network interconnect devices (e.g., throughput, latency, frame loss).
RFC 3927Dynamic configuration of IPv4 link-local addresses in 169.254/16 for same-link communication.
RFC 5737Reserves three IPv4 unicast blocks for documentation and examples (TEST-NET addresses).
RFC 5771IANA guidelines for assigning IPv4 multicast addresses and related allocation categories.
RFC 6598Reserves 100.64.0.0/10 as shared address space for Carrier-Grade NAT (CGN).
RFC 6890Defines and maintains the IANA special-purpose address registries for IPv4/IPv6 (e.g., loopback, link-local).

Headers

SMSPortal offers the capability for customers to save their own custom HTTP headers (provided these are not in the forbidden list). This allows customers to define headers required for their own domain-specific purposes (e.g. Authorization, X-Custom-Token, etc.).

Constraints

The following constraints are applicable to custom HTTP headers:

  • Header name length: Maximum of 50 characters.
  • Header value length: Maximum of 500 characters.
  • Total header entry limit: Approximately 550 characters (name + value).
  • Header format: Must comply with HTTP header field syntax and naming rules (case-insensitive, no whitespace around the name or colon). See the following references for more information:
    • RFC 9110, see sections § 5.1 and § 5.6. These sections define header field structure, allowed characters, and general field limits
    • RFC 9112, see section § 2.2: This section describes header line formatting (field-name: field-value) and parsing behavior.
    • Mozilla HTTP Header Description: Gives an approachable introduction into usage of HTTP headers.
  • Header value: Must contain a non-whitespace, non-empty value.
  • Forbidden headers: Headers in the Forbidden Headers section are reserved and cannot be overridden.

NOTE 1: While HTTP itself does not define strict size limits, SMSPortal enforces these practical limits to ensure compatibility, security resilience and performance across common HTTP implementations.

Default Headers

SMSPortal always set the following headers:

Header NameHeader Value
User-AgentSMS Webhook Engine

Forbidden Headers

The list of comma-separated headers below are forbidden for usage from customers.

:authority, :method, :path, :scheme, Accept, Accept-Charset, Accept-Encoding, Accept-Language, Cache-Control, Connection, Content-Disposition, Content-Encoding, Content-Language, Content-Length, Content-Location, Content-MD5, Content-Range, Content-Type, Cookie, Cookie2, Digest, DNT, Expect, Forwarded, Host, http2-settings, Idempotency-Key, If-Match, If-Modified-Since, If-None-Match, If-Range, If-Unmodified-Since, Keep-Alive, Max-Forwards, Origin, Pragma, Proxy-Authenticate, Proxy-Authorization, Proxy-Connection, Range, Referer, Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site, Set-Cookie, Signature, Signature-Input, TE, Trailer, Transfer-Encoding, Upgrade, Upgrade-Insecure-Requests, User-Agent, Via, X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto