API v3 is live and in beta: expect possible malfunctions and breaking changes in the coming days. If you find a bug, please report it to your Sillage contact.

Partner API

Manage your clients' workspaces with the Sillage Partner API.

The Partner API lets your application work on the workspaces of your clients. Every integration starts by creating a workspace: the partner_workspace_id you choose is your own ID for the client. It is 1 to 255 characters long, with no /, ?, # or whitespace; a malformed ID is refused with 422 and errors.partner_workspace_id. Every other route names the client it works on with partner_workspace_id in its path, and answers as the same route of the direct API would for that workspace, apart from the exceptions each page names (for example usage).

Base URL

https://api.getsillage.com

OpenAPI specification: Swagger UI · Raw JSON spec. See also OpenAPI specification.

Authentication

Send your partner master key as a bearer token:

Authorization: Bearer <YOUR_MASTER_KEY>

Master keys start with mk_live_ and let you act on every workspace you manage. See Authentication for the error model and the response headers.

Start here: create a workspace

Create one workspace per client, then use its partner_workspace_id in every other path:

curl -X POST "https://api.getsillage.com/api/v3/partner/workspaces" \
  -H "Authorization: Bearer $SILLAGE_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"partner_workspace_id": "crm-4821", "name": "Acme", "domain": "acme.com", "owner_email": "owner@acme.com"}'

See Create a client workspace.

References

Every endpoint of the API, by family.

Workspaces

Create and manage your clients' workspaces.

Signal templates

The signals you can set up.

Signal setups

The signals the client runs.

Signals

The signals detected for the client.

Signal runs

Start a signal and follow it.

Request status

Everything that is running now.

Lists

Lists of companies or people that signals watch.

Account monitoring

Choose which accounts are monitored.

Leads

The people the client's signals found.

Companies

The companies of the client's workspace.

Account mapping

The people mapped on each account.

Personas

The profiles of the people the client targets.

Setup state

What is still missing to get started.

Contents

The content collected for key accounts.

Content requests

The requests that gather content and map accounts.

Usage

What you are billed for each client.

How the routes are named

  • GET reads one item by its ID, or a plain list with few filters.
  • POST .../query searches with filters that take lists of values, such as several domains or several types. The filters travel in a JSON body.
  • POST .../count counts what a search would match.
  • PATCH, PUT and DELETE change or remove an item.

A route that takes a body (POST, PATCH or PUT) needs a JSON body, even when every field is optional: send {}. A missing or empty body is refused with 422 and the code body_required. The restore routes take no body.

Identifiers

All identifiers are integers, except partner_workspace_id, which is a string.

Dates

Date filters take an ISO 8601 date and time with a UTC offset, for example 2026-06-12T10:30:00Z. Responses return dates in UTC.

Lists in query strings and bodies

A query parameter that takes a list accepts a comma list (?company_ids=1,2) or the key repeated (?company_ids=1&company_ids=2); repeating a parameter that takes one value is refused with 422. A body sent with GET or DELETE is ignored.

Pagination

Searches and usage page by cursor, plain lists page by page number. See Pagination.

Errors

Every error is an RFC 9457 problem document with a stable code, and input the API does not know is refused with 422. See Authentication.

On this page