Legacy Public API - Living Security Platform

This guide covers existing /api/v1 integrations that exchange an API access key for a bearer token. Their credentials and request format differ from the /v1 Public API. For a new integration, start with the API quickstart and Authentication. The new /v1 API uses service-account API keys or OAuth access tokens.

Before You Start

You need:

Living Security access that permits API access-key management
An API access key created under Settings → Access Keys
The one-time access-key secret shown when the credential is created
The API issuer ID supplied with your Public API credentials by Living Security
The regional base URL for the organization you are integrating
A server-side runtime and secret manager

Access-key secrets must not be placed in browser code, mobile apps, source control, client-side environment variables, tickets, or shared logs.

The Access Keys dialog shows the one-time secret, but it does not show the API issuer ID. If Living Security has not supplied the issuer ID with your Public API credentials, request it from Living Security Support. The issuer ID is not the access key ID or organization ID.

Regional Hosts

The legacy contract uses these regional /api/v1 production hosts:

Region	Base URL
US	`https://api.us-east-1.livingsecurity.ai/api/v1`
EU	`https://api.eu-west-1.livingsecurity.ai/api/v1`

Use the region assigned to the Living Security organization. Do not switch regions to work around an authorization or availability error.

Legacy Resources

Resource	Supported operations
People	Search organization people and retrieve a person’s membership
API access keys	Create, list, rotate, and revoke API access keys

Use Developers → Public API Reference for the complete operation, parameter, request, response, and schema list. If an operation is not there, it is not currently part of the Public API.

Authentication

Public API access has two stages:

Exchange the secret access key and API issuer ID for a short-lived bearer token and organization ID.
Send the bearer token and organization ID with each API request.

Required request headers are:

Authorization: Bearer <access-token>
x-organization-id: <organization-id>

The organization header must be the organization returned by the access-key exchange. A key does not authorize access to an arbitrary organization ID.

TypeScript SDK

Install the current major version:

npm install @livingsecurity/sdk@^1

Then exchange the key and configure the SDK:

import { configure, exchangeAccessKey } from "@livingsecurity/sdk";

const accessKeySecret = process.env.LS_API_ACCESS_KEY_SECRET;
const apiIssuerId = process.env.LS_API_ISSUER_ID;

if (!accessKeySecret || !apiIssuerId) {
  throw new Error("LS_API_ACCESS_KEY_SECRET and LS_API_ISSUER_ID are required");
}

const { accessToken, organizationId } = await exchangeAccessKey(
  accessKeySecret,
  apiIssuerId,
);

configure({
  baseUrl: "https://api.us-east-1.livingsecurity.ai/api/v1",
  accessToken,
  organizationId,
});

Use the EU base URL for an EU organization. The SDK exchange is intended for server-side Node.js runtimes.

Direct REST Request

If you perform the exchange outside the SDK, send its bearer token and organization ID on every request:

curl --request GET \
  "https://api.us-east-1.livingsecurity.ai/api/v1/people/search?limit=1" \
  --header "Authorization: Bearer $LIVING_SECURITY_BEARER_TOKEN" \
  --header "x-organization-id: $LIVING_SECURITY_ORG_ID" \
  --header "Accept: application/json"

Bearer tokens are short-lived. Exchange the access key again when obtaining a new token rather than persisting a bearer token as a permanent credential.

Access-Key Lifecycle

Name keys after the owning integration or automation.
Choose the least-privileged scopes offered by the access-key form.
Store the one-time secret immediately; it cannot be retrieved after creation or rotation.
Rotate a key through Settings → Access Keys and deploy the replacement before revoking the old credential.
Revoke keys that are no longer used or whose secret may have been exposed.
Use service-account keys for non-human integrations when that key type is available to your organization.

Pagination

People search supports limit, cursor, offset, and includeTotal parameters. Prefer the cursor returned by the previous response for sequential traversal.

limit defaults to 50 and accepts 1–100.
cursor continues from a previous response.
offset skips a number of records and defaults to 0.
includeTotal=true requests an exact filtered count; omit it when the count is not needed.

Read the pagination object returned by the endpoint. Do not calculate the next page from the number of rows received or combine independently paginated requests and sort the partial results yourself.

Errors

Documented JSON errors use this general shape:

{
  "statusCode": 400,
  "message": "Validation failed",
  "error": "Bad Request"
}

message can be a string or an array of validation messages.

Status	Meaning	Response
`400`	Invalid parameters or request body	Correct the named validation errors
`401`	Bearer token is missing, invalid, or expired	Exchange the access key again and retry once
`403`	Credential lacks permission or organization access	Check key scopes and organization context
`404`	Resource does not exist in the authorized organization	Verify the resource ID and organization
`408`	Request timed out	Retry with bounded exponential backoff
`429`	Rate limit reached	Wait at least as long as `Retry-After`, when present
`5xx`	Temporary service failure	Retry safe reads with bounded exponential backoff

The curated contract does not currently publish one universal numeric rate limit or guarantee a request-ID response header for every operation. Capture the UTC time, method, path, status, and sanitized response body when requesting support. Do not automatically retry create, rotate, revoke, or delete operations unless the operation explicitly documents idempotency. Check current resource state after an ambiguous network failure.

Compatibility and Deprecation

V1 evolves additively by default. Clients must ignore unknown response fields. A breaking change requires a documented migration path; deprecated operations remain in the reference with their reason, replacement when available, and sunset date during the migration window. Pin the SDK to a compatible major version and review its release notes before upgrading. Treat the generated Public API Reference—not first-party app clients—as the schema source of truth.

Public API, MCP, and the Web Application

Surface	Use for	Compatibility model
Public API	Customer systems, partners, and external automation	Stable, versioned resources
MCP	Permissioned AI-tool interactions	Tool contracts and compact structured outputs
Web application	Human workflows in the Living Security product	App-owned contracts that may evolve with the UI

See MCP Integration to connect an AI tool to Living Security.

Get Help

Contact Living Security Support with:

Organization and region
SDK name and version, if used
UTC timestamp, method, and path
HTTP status and sanitized error body

Never include access-key secrets, bearer tokens, or private customer data.

API Access Keys

Create, rotate, and revoke API credentials.

MCP Integration

Connect supported AI tools through Model Context Protocol.

Public API

Public API Reference

​Before You Start

​Regional Hosts

​Legacy Resources

​Authentication

​TypeScript SDK

​Direct REST Request

​Access-Key Lifecycle

​Pagination

​Errors

​Compatibility and Deprecation

​Public API, MCP, and the Web Application

​Get Help

​Related

API Access Keys

MCP Integration

Before You Start

Regional Hosts

Legacy Resources

Authentication

TypeScript SDK

Direct REST Request

Access-Key Lifecycle

Pagination

Errors

Compatibility and Deprecation

Public API, MCP, and the Web Application

Get Help

Related