Availability: the OutboundAPI block is enabled per environment. Contact your Lobyco representative if you don’t see it in the orchestration canvas.
When the block fires
The OutboundAPI block runs each time a customer reaches it in an orchestration flow. It must sit downstream of an event block — that event supplies the data the block sends. The flow itself can be segmentation-based or event-driven (for exampleSegment → Challenge → [event] → OutboundAPI); the only requirement is that an event block comes somewhere before the OutboundAPI block.
The triggering event can be any of a growing set of platform and activity events — currently including customer sign-up, game won / lost, challenge completed, and offer assigned. More event types are added over time, so treat this as a non-exhaustive list.
One event for one customer produces one HTTP request. A failed request affects only that customer’s journey — other customers in the flow continue normally.
The call is one-way: the response from your endpoint is recorded for troubleshooting but does not change the orchestration flow.
How it works
A marketer (or you, as an integrator) places the OutboundAPI block in an orchestration flow on the visual canvas, downstream of an event block. Each time a customer passes through the block, the platform:1
Takes the event data
Takes the event data produced by the upstream event block (for example a sign-up or purchase event).2
Enriches the data
Enriches the data with the full customer profile and/or purchase details — but only if your templates reference them (see Dynamic values).3
Renders the request
Renders the URL, header values, and body, replacing all placeholders with real data.4
Authenticates
Authenticates — obtains an OAuth2 Bearer token, builds a Basic Auth header, or attaches your custom headers.5
Sends the request
Sends the HTTP request to your endpoint.6
Records the outcome
Records the outcome (status code, response body, response time) in the run details.Configuration reference
The configuration is validated when the flow is saved: the URL and method are checked, an inline auth config must be complete, and a referenced integration must exist and not be deleted.
Testing the block
The block’s configuration dialog has a Test button that sends a single real request with the current configuration — including authentication — and shows the response status code, response time, and response body. Use it to confirm credentials and payload format with your endpoint before publishing the flow, and prefer a test endpoint or pre-production environment while doing so.Dynamic values (placeholders)
URL, header values, and the body are Liquid templates. Placeholders use double curly braces:Data sources
The placeholder namespace for a customer is calledmember, as are the API and the memberId field behind it.
Enrichment is automatic and on-demand: the platform scans your templates and only calls the Member or Purchase API when a template actually references
member. or purchase.. If the required ID is missing from the event, or the lookup returns no data, the block fails and no request is sent.
Tip: in the configuration dialog, type two opening braces to open an autocomplete dropdown of the placeholders available for your flow’s event type, including nested values (e.g.
purchase.products[0].name).Example body
Supported Liquid features
Conditionals and loops are supported too:
Authentication
Three authentication types are supported. Credentials can be stored once as a reusable Integration in the Lobyco Admin Portal and referenced from any number of flows — this is the recommended approach. Integration secrets are encrypted at rest (AES-256-GCM), always masked in the UI and API responses, and can be rotated in one place. The Admin Portal also offers a test action that performs a real call with the configured credentials.OAuth2 Client Credentials
For platforms that issue short-lived Bearer tokens (e.g. Salesforce).
Token request behavior — your identity provider receives:
access_token (required) and expires_in (in seconds). The platform then calls your endpoint with Authorization: Bearer {access_token}.
Tokens are cached for 90% of expires_in and reused across executions with the same credentials, so your token endpoint is not called on every event. If expires_in is missing or zero, the token is not cached and is requested per call.
Basic Auth
For platforms authenticating with username/password or key/secret pairs (e.g. Bloomreach private API groups). The platform base64-encodesusername:password and sends Authorization: Basic {encoded} on every request.
Custom Headers
For platforms using static API-key headers (e.g. IterableApi-Key, Adobe X-Api-Key). Configure one or more headers; mark sensitive values as secret so they are encrypted and masked. All configured headers are attached to every request.
What your endpoint must do
- Respond within 5 seconds. The per-attempt timeout is 5 seconds by default (configurable per environment). Accept the request, respond, and process asynchronously if your handling is slow.
- Return a 2xx status for success. Any 2xx counts as success; everything else marks the block execution as failed. Redirects are followed by standard HTTP client behavior; auth headers are set on the initial request.
- Be idempotent. Failed attempts are retried (see below), so the same event can reach your endpoint more than once. The platform does not send an idempotency key today — deduplicate using an identifier from the event payload (e.g. a receipt or activity ID).
- Expect UTF-8 JSON when a body is configured (
Content-Type: application/json; charset=utf-8).
Retries and timeouts
Retries trigger on transient failures only: HTTP
5xx, HTTP 408, network errors, and timeouts. Other non-success statuses (e.g. 400, 401, 404) are not retried and fail the block immediately. The same retry policy applies to OAuth2 token requests.
Defaults can be tuned per environment by Lobyco.
What is recorded
For every execution, the platform records the response status code, response body, and response time in the run details. This data is visible to flow operators for troubleshooting, so avoid returning sensitive data in your response body.Security and restrictions
- Private networks are blocked. The target URL — and the OAuth2 token URL — must not resolve (directly or via DNS) to a private or link-local address (
127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,169.254.0.0/16, plus Lobyco-internal ranges). This is enforced both when the flow is saved and again at execution time, after placeholders are resolved. - Allowed methods are limited to
GET,POST,PUT,DELETE,PATCH. - Body content type is always
application/json; charset=utf-8. Other formats (form-urlencoded, XML, multipart) cannot be configured, and aContent-Typecustom header is silently ignored. - Secrets (OAuth2 client secrets, Basic Auth passwords, secret custom headers) are encrypted at rest and never returned in plaintext by any Lobyco API or UI.
Example setups
Salesforce (OAuth2 Client Credentials)
1
Create a Connected App
In Salesforce, create a Connected App with the client-credentials flow enabled and note the consumer key/secret.2
Create an Integration
In the Lobyco Admin Portal, create an Integration of type OAuth2 Client Credentials with Token URLhttps://{your-domain}.my.salesforce.com/services/oauth2/token, the consumer key as Client ID, and the consumer secret as Client Secret.3
Configure the OutboundAPI block
In the OutboundAPI block, reference the integration and configure the target REST endpoint, e.g.POST https://{your-domain}.my.salesforce.com/services/data/v60.0/sobjects/Lead/ with a JSON body built from event and member placeholders.Bloomreach Engagement (Basic Auth)
1
Create a Private API group
In Bloomreach, open Project Settings → Access Management → API → API Groups and create a Private API group with the permissions your flow needs. Copy the API Key ID and API Secret.2
Create a Basic Auth Integration
Create a Basic Auth Integration: Username = API Key ID, Password = API Secret.3
Configure the endpoint
Point the block at the desired endpoint, e.g.POST https://api.exponea.com/track/v2/projects/{projectToken}/customers/events./track/v2/..., consent fetch) alternatively work with a Custom Headers Integration carrying Authorization: Token <api_token> (marked secret). Private endpoints (/data/v2/..., /api/v2/...) require Basic Auth — default to Basic Auth if your flow touches anything beyond tracking.
API-key platforms (Custom Headers)
For Iterable, Adobe, or your own webhook receiver: create a Custom Headers Integration with the vendor’s key header (Api-Key, X-Api-Key, etc.), mark the value as secret, and reference it from the block.