Customer Developer Portal

Create tenant-scoped credentials, test requests, measure usage, and deliver signed events from one workspace-owned console.

Open the console: workspace Owners and Admins can use the customer-facing Developer Portal. Capacity and production access follow the workspace subscription before any credential is created.

What the portal includes

View	Purpose
`Credentials`	Create live or sandbox API keys, choose least-privilege scopes, set expiration, copy the plaintext once, and revoke immediately.
`Connect AI`	Copy the remote MCP endpoint, configure bearer authentication, and map key scopes to tenant-scoped research, analysis, and governed decision tools.
`API explorer`	Prepare authenticated requests against supported public endpoints without guessing the route or scope.
`Usage`	Review requests, errors, error rate, latency, per-key volume, route volume, daily traffic, and exportable JSON windows.
`Webhooks`	Register HTTPS endpoints, copy the signing secret once, send a diagnostic event, inspect delivery health, and remove endpoints.
`Events`	See the event names and payload contracts used for pursuit decisions and delivery diagnostics.
`Quickstart`	Copy bounded cURL, Node.js, and Python examples that use the same scoped public API.

Plan capacity

Access is resolved by the API from the verified workspace subscription. API keys are secure credentials included with eligible plans—not separately billable products. The browser displays the same operational limits, but it is not the enforcement boundary.

Plan	Total keys	Sandbox keys	Webhooks
`Solo`	1	1	2
`Growth`	5	2	5
`Growth Plus`	10	3	15
`Enterprise`	Unlimited	Unlimited	Unlimited

Enterprise unlimited capacity is subject to fair-use and service-protection controls.

Total-key and sandbox-key counts are active-credential safety limits, not units for sale. Revoke unused credentials or compare plans when the limit is reached. A recurring integration pack adds three integration connections and three webhook endpoints. Manage the subscription in Billing.

Create and rotate an API key

Open Developer Portal → Credentials and name the key after its consuming system.
Choose Sandbox for synthetic test data or Live for production workspace data.
Select only the required scopes and set a bounded expiration where practical.
Create the API key and copy the plaintext immediately. WinLayer stores only its hash and cannot reveal it again.
Send a request, confirm it under Usage, then move the secret into your credential manager.
For rotation, create the replacement first, update the consumer, verify traffic, and revoke the old key.

bash

curl -s \
  -H "Authorization: Bearer wl_test_..." \
  "https://api.winlayer.ai/api/v1/public/opportunities?limit=5&min=40"

Live and sandbox behavior

Live keys begin with wl_live_ and resolve the workspace that created them. Sandbox keys begin with wl_test_, return deterministic synthetic records, expire by default, and cannot receive production mutation scopes.

Continue with connecting AI with MCP, authentication and scopes, the first API call, rate limits, and signed webhooks.

See the API inside a customer product

The standalone Northstar example turns a plan-provided API credential into a fictional customer's branded opportunity, pipeline, forecast, agency, and usage portal. Its Node server owns the secret, while the browser receives only rendered business data.

Runnable guide: Build a customer website with the WinLayer API.

Customer and staff boundaries

/developer is a customer workspace feature. It uses the customer's normal Clerk session, tenant membership, Owner/Admin role, and active subscription. Internal WinLayer Developer Operations uses a separate /staff/developer application with its own staff credential and capability-scoped session.

Customer sessions, customer API keys, paid plans, and workspace ownership never grant internal staff access. See Roles and permissions for the complete boundary.

Operational safety

Never commit a key, webhook secret, or copied example containing a real secret.
Use one credential per consuming system so usage and revocation remain attributable.
Prefer the minimum scopes and short-lived sandbox keys.
Treat 401 as missing or invalid authentication, 403 as a scope or plan denial, and 429 as a rate-limit signal.
Verify every webhook HMAC signature and deduplicate retries by event identifier.