Ingress webhook bootstrap

The fastest way to seed a new Lead Pool’s identifier fields is to POST a sample lead via the Ingress webhook. The pool reads the payload, creates any missing fields automatically, and you then rename their labels in the UI.

This is faster than manually clicking through Add-Field in the pool settings, especially for pools with five or more identifier fields.

When to use this

• New Lead Pool, empty schema, no leads yet.
• You want the same firstName / lastName / phone / email keys you use in every other pool (because stable keys make automations portable).
• You’re comfortable making a POST request from Postman, curl, or Make’s HTTP module.

Skip this article and use the UI if the pool’s schema is one-off or you’re not familiar with HTTP tooling.

What you need

Thing	Where to get it
The pool’s Ingress URL	Einstellungen → Lead-Pools → [pool] → Webhooks
The pool’s Ingress token	Same place, displayed once; copy to a vault
A tool to POST JSON	Postman, curl, Insomnia, Make’s HTTP module — any of these

The token authenticates the call. Pass it as the x-rocketlead-ingress-token request header — not as a query string parameter. (Header names are case-insensitive, but the canonical form in the API schema is lowercase.)

The request

The body has three top-level keys:

• contacts — who the lead is. Names and contact channels go here and nowhere else.
• data — an object of Tabellenschema fields keyed by their string key (e.g. course). New keys here cause the pool’s schema to grow.
• customFieldData (optional) — an object of Custom Field values keyed by UUID. Validated against the org’s Custom Field registry; unknown UUIDs are rejected.

POST <ingress-url>
Content-Type: application/json
x-rocketlead-ingress-token: <token>

{
    "contacts": [
        {
            "firstName": "Test",
            "lastName": "Lead",
            "isPrimary": true,
            "isSubject": false,
            "channels": [
                {"kind": "email", "value": "test@example.com", "isPrimary": true},
                {"kind": "phone", "value": "+4915112345678", "isPrimary": true}
            ]
        },
        {"firstName": "Kid", "isSubject": true}
    ],
    "data": {
        "course": "Kids BJJ"
    }
}

Names and channels do not belong in data

A name, phone number or email inside data or customFieldData is stored and read by nothing. It will not name the lead and will not reach your automations. A payload without a contacts array creates a lead with nobody on it. See Stating who is on a lead.

The parent carries "isSubject": false because isSubject defaults to true — without it the parent would count as a participant too.

A 200 response returns the created lead. New data keys auto-create Tabellenschema fields on the pool with those raw keys as initial labels. Open the pool in the console — the fields exist, ready for relabeling.

For bootstrap, data is for the pool’s own questions — the course asked about, where the lead heard of you, a note. Every new key there lands as Tabellenschema.

Pool view is cached for 5 minutes

After the POST, the pool’s column list is cached in the browser for ~5 minutes. Reload the page to see the new columns immediately.

Recommended canonical keys

Who the lead is no longer lives in the pool’s schema at all — it is on the contacts you state, and the lead name, the click-to-call and the click-to-mail all come from there. There is nothing to standardise for identity, and nothing to relabel.

What is left for data is what the pool itself asks. Keep those keys consistent across pools so automation templates can reference them with no per-pool branching:

Key	Type	Notes
course	Tabellenschema, type text	Which course or offer the lead asked about
source	Tabellenschema, type text	Where the lead came from, when the sender knows
note	Tabellenschema, type text	Free text the sender captured

After the bootstrap

Rename the auto-generated labels (e.g. course → “Kurs”) in the pool’s field settings (Einstellungen → Lead-Pools → [pool] → Felder). The key stays stable; only the display label changes. Then assign the appropriate type to each field — see Tabellenschema vs Custom Fields for which fields get which type.

The Ingress webhook isn’t going away — it remains the canonical inbound channel for third-party form fills, Make scenarios, and any custom integration. After bootstrap you’ll keep using it for actual lead intake from external sources.

What’s next

• Move on to Scheduling once the schema looks right.
• Or revisit Tabellenschema vs Custom Fields for the long-term direction.