Internet Tools

The Internet Tools Events Provider enables your workflows to react to external HTTP requests in real-time. It acts as a bridge between external systems and your process flows, using custom End Points to receive data and trigger automation.

End Points

Before diving into the available events, it's important to understand the concept of End Points.

Each project can define multiple End Points, which currently accept only HTTP requests. Support for additional protocols is planned in the future.

An End Point is a unique identifier that extends your service URL. For example:
https://api.fl101.io/ext/x19x4y6d4hh08rx3/

You can optionally assign a human-readable alias:
https://api.fl101.io/ext/demo/

Note: Once an alias is assigned, the original system-generated URL will no longer accept requests. Alias support is currently unavailable on the Free Plan.

Each End Point also comes with configurable attributes that give you fine-grained control over its behavior:

• Response Timeout – Maximum time (in seconds) the End Point will wait for your backend to respond. The maximum allowed value is 300 seconds (5 minutes).
• Request Rate Limit – Maximum number of requests per second the End Point will accept. The maximum allowed value is 60 requests per second.

CORS Settings (optional)

You can enable Cross-Origin Resource Sharing (CORS) for an End Point to allow web browsers to call it directly from frontend applications. When enabled, the following options become available:

These settings give you full control over performance, security, rate-limiting, and cross-origin access for each End Point in your project.

Authentication is required (optional)

Enable authentication to protect your endpoint from unauthorized access. When turned on, incoming requests must include valid credentials; otherwise, the endpoint returns a 401 Unauthorized response.

Three authentication methods are currently supported:

• API Key / Session
• Basic Authentication
• Google Sign In Token

API Key / Session

Validates requests using a static API key or session identifier passed in a header or query parameter.

• Header or Parameter Name
  The name of the header (e.g. X-Api-Key) or query parameter (e.g. api_key) that carries the key/session value.
• Authentication Data Source
  Where the expected key/session value is stored:
  • Direct Settings — the value is entered directly in the endpoint configuration (single key/session only).
  • Data Schema — select a Data Schema and column containing the key/session ID. Optionally, include an “Expired At” column (Unix Epoch seconds, UTC) to enforce expiration.
• Hash Function
  How the stored value is protected:
  • Plain text — direct comparison (not recommended for production).
  • Selected hash function — incoming value is hashed before comparison (e.g., SHA-256, SHA-512).

Basic Authentication

Standard HTTP Basic Auth scheme. Clients send an Authorization header containing Basic <base64(username:password)>.

• Basic realm
  The realm name shown in the WWW-Authenticate challenge header (e.g. WWW-Authenticate: Basic realm="User Visible Realm").
• Authentication Data Source
  Where credentials are stored:
  • Direct Settings — single username/password pair entered in endpoint settings.
  • Data Schema — select a Data Schema with columns for username and (hashed) password. Supports multiple users.
• Hash Function
  How passwords are stored:
  • Plain text — direct comparison (use only for testing).
  • Selected hash function — incoming password is hashed before comparison (SHA-256, SHA-512).

Google Sign In Token

Validates a Google-issued JWT (ID token) sent by the client. The token is verified and its payload becomes available for use in your workflow (e.g., extracting email or user ID).

• Header or Parameter Name
  The header (e.g. X-Google-Token: <token>) or query parameter name containing the JWT.
• Web Client IDs
  List of allowed Google OAuth 2.0 Client IDs (from your Google Cloud Console). The token’s aud claim must match one of these values.

Note: For production use, prefer hashed storage and avoid plain-text credentials whenever possible. Choose the method that best matches your client applications (e.g., API Key for servers, Google Sign In for web/mobile apps with Google login).

HTTP Request

This event is triggered when an incoming HTTP request is received at a configured End Point.

Event Filters

Note: If a filter value is incorrect, the event will silently fail to trigger — no error will be raised.

Result Payload

When triggered, the event provides the following data in the Execution State:

Sample Payload

When calling the following URL: curl -X POST "https://api.fl101.io/ext/k32768b8maib4o6t?test=456" -d '{"test": 123}' -H "Content-Type:application/json"

You’ll receive a payload like this:

{
  "id": "66d297ed-d429-43ce-8f53-797eae8404bd",
  "method": "POST",
  "headers": {
    "content-length": 13,
    "x-forwarded-proto": "https",
    "host": "api.fl101.io",
    "x-forwarded-port": 443,
    "content-type": "application/json",
    "x-forwarded-for": "192.168.0.1",
    "user-agent": "curl/8.7.1",
    "accept": "*/*"
  },
  "parameters": {
    "test": 456
  },
  "body": {
    "test": 123
  }
}

Responding to the Request

The HTTP Request event is designed to work with a paired Send Task using the event type HTTP Response. This allows your process to respond directly to the original HTTP request.

To send a response:

• Provide the original Request ID.
• Specify a response status code (e.g. 200).
• Optionally define headers and a response body.

The maximum time allowed to respond is 10 seconds. If the response is not returned in time, the request will time out.

This setup enables real-time, event-driven communication between your workflows and external systems — with full control over how requests are processed and responded to.