Postman walkthrough for the bootstrap POST

Concrete walkthrough of issuing the bootstrap POST from Postman. The same configuration applies to Insomnia, curl, or Make’s HTTP module — only the UI changes.

The high-level concept is in the Ingress webhook bootstrap article. Read that first; this article is the click-by-click version.

Step 1 — Set the request method and URL

Method: POST
URL: paste the Ingress URL from the pool’s settings page

Step 2 — Set the authorization header

In the Authorization tab:

Type: API Key
Key: x-rocketlead-ingress-token — exact name from the API schema (header names are case-insensitive on the wire)
Value: paste the Ingress token from the pool’s settings
Add to: Header

This adds an x-rocketlead-ingress-token: <token> header to the outgoing request. You can also configure this manually in the Headers tab — same result.

Step 3 — Set the body

In the Body tab:

Type: raw
Format: JSON

The body has three top-level keys: contacts (who the lead is), data (Tabellenschema fields, keyed by string key) and customFieldData (Custom Field values, keyed by UUID; optional).

Paste the bootstrap payload:

{
    "contacts": [
        {"firstName": "Test", "lastName": "Lead", "isPrimary": true, "isSubject": false},
        {"firstName": "Kid", "isSubject": true}
    ],
    "data": {
        "course": "Kids BJJ"
    }
}

Keys you’ve not used before are auto-created on the pool as Tabellenschema fields.

"isSubject": false on the parent matters: isSubject defaults to true, so leaving it off would make the parent a participant of the lead alongside the child.

Step 4 — Send and inspect the response

Hit Send. A successful response returns 200 OK with the created lead’s full record:

{
    "id": "<lead-uuid>",
    "tableId": "<pool-uuid>",
    "leadStateId": "<default-state-id>",
    "identity": {
        "primary": {
            "id": "<contact-uuid>",
            "firstName": "Test",
            "lastName": "Lead",
            "channels": [],
            "isPrimary": true,
            "isSubject": false,
            "position": 0
        },
        "participants": [
            {"id": "<contact-uuid>", "firstName": "Kid", "channels": [], "isPrimary": false, "isSubject": true, "position": 1}
        ],
        "all": [{"...": "both people"}],
        "source": "contacts"
    },
    "data": {
        "course": "Kids BJJ"
    },
    "customFieldData": {},
    "createdAt": "...",
    "updatedAt": "..."
}

identity is resolved from the contacts you stated — that is where the lead’s name comes from. The data object holds Tabellenschema fields keyed by their string keys. The customFieldData object holds Custom Field values keyed by UUID — that’s why automations reference these via the UUID and not the name.

Step 5 — Verify in the console

Open the pool in the console and reload the page (the column list is browser-cached for ~5 minutes after the POST). The new lead is in the table; the new fields appear as columns with their raw keys as labels. Now you can:

Rename the labels via the pool’s field settings.
Assign types to the fields the pool asks about.
Move fields you ask in several pools to global Custom Fields so they’re available across all of them.

Alternative: `curl` one-liner

curl -X POST "<ingress-url>" \
    -H "Content-Type: application/json" \
    -H "x-rocketlead-ingress-token: <token>" \
    -d '{
        "contacts": [{"firstName": "Test", "lastName": "Lead", "isPrimary": true}],
        "data": {"course": "Kids BJJ"}
    }'

Same result, no GUI.

What’s next

You’re done with schema setup. Continue to the Scheduling mental model — the densest topic in the handbook.