Overview

Use HTTP Configuration to define define settings in a single location and share them between multiple HTTP Action nodes.

HTTP Configurations work in a similar way to Shared Styles, where a HTTP Action inherits the settings defined by the associated HTTP Configuration, but these settings can be overridden on the HTTP Action.

Properties Tab

Basic Settings

Field Description Example Value

Name Name given to the HTTP Configuration. Governemnt_APIs

URL

The URL of the request.

Input literal values or expressions with attributes encapsulated within ${} syntax, for example ${in.MyValue}.

This URL will act as a prefix to the URL on the HTTP Action i.e. the URL defined on the HTTP Action will be added to this one. However, if the HTTP Action's URL starts with http, mailto or callto, this URL will not be used at all.

https://api.example.com

Headers

Headers are typically used to specify information for the request, such as the character set being used, session tokens or passwords. Headers can make use of the PhixFlow Secret Key Details see below. For more information see HTTP Header.

For example,

Name: Authorization
Expression: ${_datasource.MyAPIKey}

Secret Key Details

Secret Keys allow sensitive data such as passwords or security tokens to be encrypted and stored in the PhixFlow Database.

Secret keys have a name which they can be referenced by using the syntax ${_datasource.keyName}. For full details on secret keys see Secret Key and Local Secret.

Description

We recommend that you always enter a description to explain the purpose of this item.

Rate Limiting

Rate limiting can be used to limit traffic and help stability. It works by restricting the number of requests that can be sent.

Field	Description
Rate Limiting	Toggle on or off to restrict the number of requests.
When enabled the following options are available:
Request Capacity	Maximum number of requests that can be sent during the time period defined by the Request Capacity Rate (ms).
Request Capacity Rate (ms)	Defines time period, in milliseconds, in which requests can be processed. The number of requests processed during this period is defined by the Request Capacity and the Maximum Rollover Requests.
Maximum Rollover Requests (Optional)	The maximum number of requests that can be saved, to be sent later. Defaults to to the Request Capacity.
Maximum Parallel Requests (Optional)	The maximum number of requests that can be sent at the same time. Note: If more than the allowed number of requests are queued, as soon as a request is finished, another is sent.
Requests in Queue	A read-only field that displays the number of requests waiting to be sent when the properties were opened.

Rate Limiting Example

Requests gained per time period: 20

Time period for gaining new requests: 30000ms

Maximum rollover requests: 25

If 10 requests are sent, then 30000ms later another 30 requests are sent, 25 requests would be sent straight away (up to the Maximum rollover request), and the other 5 requests would be sent 30000ms later.

Request Capacity: 80

Request Capacity Rate: 30000ms

Maximum Rollover Requests: 101

Time	Request Capacity	Pending Requests	Sent Requests	Requests Remaining	Request Capacity Remaining	Maximum Rollover Requests
0s	80	100	80	20	0	0
30s	80	20	20	0	60	60
60s	80+60	0	0	0	140	101
90s	80+101	100	100	0	81	81
120s	80+81	0	0	0	161	101
150s	80+101	150	150	0	31	31
180s	80+31	0	0	0	111	101

Advanced

Field	Description
Connection Timeout (s)	The maximum time to wait to while attempting to create a connection, measured in seconds. The default for this is set to 300 seconds.
Response Packet Timeout (s)	The maximum time to wait between responses from the data packets, measured in seconds. The default for this is set to 180 seconds.

Learn More