Limelight API
The Limelight API allows you to programmatically access and manage your Limelight data.
Authentication​
All API requests require a valid API key. Include your API key in the Authorization header:
Authorization: Bearer llt_live_your_api_key_here
You can generate and manage your API keys from Settings > API Keys in the Limelight dashboard.
Rate Limiting​
API requests are rate limited per API key. The default limit is 60 requests per minute.
Rate limit headers are included in all authenticated responses:
| Header | Description |
|---|---|
X-RateLimit-Limit | Maximum requests allowed per minute |
X-RateLimit-Remaining | Requests remaining in current window |
X-RateLimit-Reset | Unix timestamp when the window resets |
When the rate limit is exceeded, the API returns a 429 Too Many Requests response with a Retry-After header indicating how many seconds to wait before retrying.
Data Handling & Privacy​
Signal Lead endpoints return personally identifiable information (PII) including names, job titles, LinkedIn profile URLs, and company details. API consumers must:
- Store PII in encrypted-at-rest datastores and transmit only over TLS.
- Implement access controls limiting PII visibility to authorized personnel.
- Honor data-deletion requests and retention policies applicable to your jurisdiction (e.g. GDPR, CCPA).
- Never use PII for purposes beyond the scope authorized by your Limelight subscription.
Fields classified as PII are annotated with x-pii: true in the schema.
Versioning & Breaking Changes​
This API follows additive-only evolution: new fields may be added to response objects at any time. Clients should ignore unknown fields.
When fields are removed or renamed, they are first marked deprecated for at least one release cycle before removal. Deprecated fields still appear in responses but may return null.
Changed — 2026-07-30: GET /signals/leads rejects a malformed sort​
A sort value that is not a field:direction pair now returns 400 invalid_parameter. It previously returned 200, served under the default createdAt:desc ordering, with the requested field discarded and nothing in the response to say so.
If you send ?sort=updatedAt you will now get a 400. Send ?sort=updatedAt:asc. The direction was never optional; it was silently ignored. The same applies to an unknown field (?sort=bogus:asc), an unknown direction (?sort=updatedAt:sideways), and repeating the parameter in one query string.
If you have been sending a bare field name, your existing data is ordered by createdAt descending, not by the field you asked for. This matters most for incremental sync: under createdAt:desc the last row of a page carries no useful updatedAt high-water mark, so a cursor derived from it will skip rows on the next run. Re-run the affected window with an explicit :asc and de-duplicate by lead id.
Omitting sort is unchanged and still yields createdAt:desc.
New: every 200 from this endpoint now carries meta.sort — the ordering actually applied. Assert it against what you sent rather than inferring the ordering from the rows.
Changed — 2026-07-28: GET /signals/leads/{id} engagement ordering​
The engagements array on the lead detail endpoint is now ordered newest-first by trackedAt (descending) and capped at 20, matching GET /signals/leads?includeEngagements=true.
It previously returned the oldest 20 engagements, in storage order. For a lead with 20 or fewer engagements only the order of the array changed. For a lead with more than 20, the response is a different set of engagements: the most recent activity now appears, and the earliest activity no longer does.
If you persist engagements from this endpoint, upsert by engagement id and treat an engagement's absence from a response as "outside the current 20-item window" rather than as a deletion. To retrieve engagements that have aged out of the window, keep your own copies — the API does not paginate engagement history.
Authentication​
- HTTP: Bearer Auth
Use your API key as the bearer token: Authorization: Bearer llt_live_...
Security Scheme Type: | http |
|---|---|
HTTP Authorization Scheme: | bearer |
Bearer format: | API Key |
Contact
Limelight Support: