Close
Creates Close leads with a nested contact server-side through the Close REST API, from lead-capture events.
Why route Close through Datafly Signal
- Profiles are updated from the server, not the browser. Events reach Close even when a tracker blocker or a failed page unload would have dropped a client-side call, so the profile reflects what actually happened.
- One consent decision governs every destination. Close is gated by the same consent state as the rest of your stack, so a withdrawal applies everywhere at once.
Prerequisites
Create an API key
In Close, open Settings > Developer > API Keys. The key is sent as the Basic auth username with an empty password.
Optional: choose a lead status
Find the status ID with GET /api/v1/status/lead/ and enter it as Lead Status ID; otherwise Close uses the organisation’s default status.
Configuration
| Field | Type | Required | Description |
|---|---|---|---|
api_key | secret | Yes | Your Close API key, used as the HTTP Basic auth username (password is empty). Create one in Close under Settings > Developer > API Keys. The key is organization-scoped, so use a key for the org whose CRM should receive the leads. |
lead_status_id | string | No | Optional. The Close lead status id to assign to newly created leads (e.g. a ‘Website Lead’ stage). Find it via GET /api/v1/status/lead/ or in the Close UI under Settings > Statuses & Pipelines. Leave blank to use the org’s default lead status. |
Signal setup
- Navigate to Integrations in the sidebar and open the Integration Library tab.
- Find Close, click Install and fill in the fields above.
- Pick the preset for your use, then review the mappings in the blueprint editor.
API endpoint
POST https://api.close.com/api/v1/lead/
Authorization: Basic base64({api_key}:)Example request:
{"name": "Acme Ltd", "url": "https://acme.example", "description": "pricing_page", "status_id": "stat_...",
"contacts": [{"name": "Jane Doe", "title": "CTO",
"emails": [{"email": "jane.doe@example.com"}], "phones": [{"phone": "+447700900123"}]}]}The presets turn on the strict output contract: only the fields the blueprint maps are sent.
Event mapping
Default preset (default)
B2B lead capture: Lead Generated, Demo Requested and Signed Up each create a Close lead named after the company (else the contact) with a nested contact from the identify traits: name, title, email and phone (E.164), the company website as the lead URL and the lead source as the description. Close stores and shows the real contact, so these are sent in plain text. Close has no upsert, so one person reaching two of these events gets two leads (Close’s duplicate suggestions merge them). Events without an email are not sent.
| Signal event | Sent to the vendor as | Enabled |
|---|---|---|
generate_lead | lead | yes |
demo_requested | demo_request | yes |
sign_up | signup | yes |
Identity and personal data
The lead is named after the company trait, else the contact’s name, else the email. The contact comes from the identify traits: name, title, email (trimmed, lower-cased) and phone (E.164). These are sent in plain text because Close stores and shows the real contact. Events without an email are not sent.
Consent
Map the integration to the consent category your organisation uses for CRM or sales data. Signal does not write cookie consent into the CRM: no subscription status, do-not-disturb flag, list or tag is set from it, because a cookie banner choice is not a permission to email or call someone.
Known limitations
- Close has no upsert: each event creates a lead, so one person reaching two lead events gets two leads. Close’s duplicate suggestions merge them.
- Close rate-limits per API key and organisation; a
429is retried.
Troubleshooting
| Symptom | Cause and fix |
|---|---|
400 | Usually an invalid status ID or a custom field that does not exist. |
| Duplicate leads | Expected for repeat lead events; merge in Close or disable an event in the blueprint. |