The relevant improveit360 data lives in custom objects, most commonly named Project (and optionally Project Activities), alongside standard objects like Lead and Opportunity. Confirm the exact object and field API names with the customer's Salesforce/improveit360 administrator before building anything — these aren't standardized across installations the way core Salesforce objects are.

Before you start

A LettrLabs Open API key and an inbound webhook connection (see Setup Guide: Open API & Webhooks).
A Salesforce System Administrator on the improveit360 org.
A technical resource comfortable with Salesforce Flow — and for the recommended option below, comfortable with a small amount of Apex. This is a more developer-involved setup than most others

Step 1: Create your LettrLabs webhook connection

In LettrLabs, go to Automations > Open API and generate an Open API key.
Go to Active Webhooks > Data Streams (Inbound) > Create, name the connection (e.g., "improveit360"), and copy the Webhook URL.
Turn on OpenAPI Key authentication.

Step 2: Allow Salesforce to call out to LettrLabs

Salesforce blocks outbound HTTP calls to any domain that isn't explicitly allow-listed. Before any of the three options below will work, an admin needs to either:

Go to Setup > Remote Site Settings > New Remote Site, and add the domain portion of your LettrLabs Webhook URL from Step 1, or
Create a Named Credential instead (Setup > Named Credentials > New Named Credential) pointed at the same URL — this is the more modern approach, and has the advantage of letting you store the X-API-KEY header on the credential itself rather than hardcoding it anywhere.

Option 1: Outbound Messages (no code, but sends XML — verify before recommending)

Classic Workflow Rules support a native Outbound Message action — genuinely no-code, and the simplest option on paper.

Go to Setup > Workflow Rules and create a rule on the Project (or relevant) object, with criteria matching your trigger — for example, a Status field equals "Job Complete."
Add a new Outbound Message action, set the Endpoint URL to your LettrLabs Webhook URL, and select the fields to include.
Save and activate the rule.

Important caveat: Outbound Messages send a SOAP XML envelope, not a JSON body. This has not been confirmed against LettrLabs' inbound webhook parser — if LettrLabs only parses JSON payloads (which appears likely based on how field-mapping is described elsewhere in this help center), this option may arrive unusable. Confirm with the LettrLabs product/engineering team whether XML is supported before presenting this as an option to a customer. If it isn't, skip to Option 2 or 3.

Option 2: Flow + External Services (no code after setup, but needs an API schema)

Salesforce Flow can call an external endpoint with no Apex, if the endpoint is registered as an External Service — this requires an OpenAPI (Swagger) specification describing LettrLabs' webhook endpoint.

Go to Setup > External Services > New External Service, and register LettrLabs' webhook endpoint using the Named Credential from Step 2.
Build a Record-Triggered Flow on the Project object, with your trigger condition (e.g., Status changes to a completed value).
Add the registered External Service as an Action step, and map Project fields (name, address, city, state, zip) into the request.

Unverified: LettrLabs doesn't currently publish a ready-made OpenAPI spec for customers to import here — this would need to be provided (even a minimal one describing the POST body shape) or built by the customer's admin from the Inbound Webhook Reference field list. Worth a product conversation if this option comes up often enough to be worth productizing.

Option 3: Flow + a small Apex callout (most flexible, requires a developer)

This is the most common real-world pattern for "get arbitrary Salesforce data to an arbitrary webhook" when no pre-built connector exists, and the one most Salesforce consultants will recognize immediately. It needs a small, reusable Apex class exposed as an invocable action:

public class LettrLabsWebhookCallout {
    @InvocableMethod(label='Send to LettrLabs Webhook')
    public static void send(List<Request> requests) {
        for (Request req : requests) {
            HttpRequest httpReq = new HttpRequest();
            httpReq.setEndpoint('callout:LettrLabs_Webhook');
            httpReq.setMethod('POST');
            httpReq.setHeader('Content-Type', 'application/json');
            httpReq.setBody(req.payload);
            new Http().send(httpReq);
        }
    }
    public class Request {
        @InvocableVariable(required=true)
        public String payload;
    }
}

A developer deploys this class (or an equivalent already in use elsewhere in the org), referencing the Named Credential created in Step 2 (callout:LettrLabs_Webhook — rename to match whatever the Named Credential is actually called).
Build a Record-Triggered Flow on the Project object with your trigger condition.
Add a Flow Formula or Text Template element to build the JSON payload string from the triggering record's fields, then pass it into the Apex action as the payload input.

This is the most flexible option — full control over the JSON shape, easy to extend later — at the cost of needing a developer for the initial setup.

Step 3: Test and confirm receipt

Trigger the automation on a test record and check the History tab on your LettrLabs webhook connection to confirm the payload arrived and is readable.

Step 4: Wire the connection to a mailing and map fields

Open the Automation (Integration Order) or Radius Mail setup, select the improveit360 connection under Select Webhook Connection, choose Mail to Recipients or Radius Mail, and map the fields from your test payload. See the Inbound Webhook Reference for the full field list.

Step 5: Go live

Save the webhook connection with a name and confirm the Salesforce-side automation is active.

Which option to recommend

In order of preference, pending the XML question above: confirm whether Option 1 (Outbound Messages) actually works end-to-end first, since it's free and no-code if it does. If it doesn't, Option 3 (Apex callout) is the most reliable and commonly-supported path in practice — most Salesforce consulting shops that manage an improveit360 org will have built something like this before. Option 2 (External Services) is elegant once set up but has the highest one-time setup cost due to the OpenAPI spec requirement.

Unverified: whether LettrLabs' inbound webhook connections accept XML (Outbound Messages) in addition to JSON is the single most important open question in this guide — please confirm with engineering before presenting Option 1 to a customer as a real path. The exact custom object and field API names (Project__c or similar) will also differ by improveit360 installation and need to be confirmed with the customer's admin.

Working through an improveit360 integration and need help scoping the Salesforce side? Reach out to our team.

Setup Guide: improveit360 (Webhook)