
Everything a developer needs to build against Productlane: your Workspace ID, API keys and their scopes, outgoing webhooks and their signing secrets, apps connected over MCP, and usage analytics.
Settings > API.
In the API keys block, click New API key.
Give it a descriptive label.
Choose Full access, which grants the admin scope, or Only select permissions and check the scopes the key actually needs.
Click Create, then copy the secret and store it somewhere safe.
The secret is shown once. If it is lost, revoke the key and create another.
In the Webhooks block, click New webhook.
Enter a label and the destination URL.
Pick the resources you want events for. Threads are selected by default, and at least one resource stays selected.
Click Create, then copy the signing secret.
You subscribe per resource: Threads, Messages, Comments, Contacts, Companies, Changelogs, Issues, Projects, Customer needs, Docs, Tags, and Members. The exact action travels in the payload's type field, so subscribing to a resource covers every action on it.
Every delivery carries an HMAC-SHA256 signature you check with the signing secret. Read the request body raw, since a framework that re-serializes the JSON breaks the signature. Deduplicate on the event id, because a slow first response can be retried.
A webhook's detail page lists its last 200 deliveries. Each row carries the event type, the HTTP status, the time, the attempt number, and how long it took, and expanding one shows the event id, the full payload, and the response body.
Disable stops delivery while keeping the configuration, which is the gentler option when a receiver is down.
Rotate from the webhook's edit page. The current secret stops working immediately, so receivers still verifying with the old one reject events until you update them. The new secret is revealed once so you can copy it.
Apps authorized over MCP are listed with who connected them, when access was granted, and when it was last used. Revoke access cuts one off immediately, and that person can reconnect by authorizing again.
Once you have an active key or a webhook, the page charts your API requests split by success and failure, errors by endpoint, webhook deliveries by status, and P95 response time. The window covers the last 24 hours, 7 days, or 14 days.
v2 is current, and its keys are prefixed pl_v2_. v1 is deprecated with a sunset date of 20 November 2026. Migrate by creating a v2 key and updating your integration. New keys are always v2.
POST /threads/bulk-update and POST /threads/bulk-delete apply one patch or one delete to up to 100 thread ids in a single call. The whole batch counts as one write against the rate limit, instead of one write per thread. Each id is resolved independently: the response returns the ids that succeeded and, for any that failed, an id, an error code, and a message, so one bad id never blocks the rest of the batch. Use these instead of looping PATCH /threads/{id} or DELETE /threads/{id} over many ids.
Revoking a key, deleting a webhook, and rotating a secret all take effect immediately and break anything still using the old value.
A 429 response includes retry_after_seconds alongside reset_at, so you know exactly how long to wait before your next request.
Full endpoint reference and rate limits live in the public API documentation rather than on this page.