Skip to main content

Partner API reference

All machine endpoints are under /api/partner/v1. Send a ykp_ key unless an endpoint explicitly requires a leased ykt_ token. JSON failures use { "error": { "code", "message", "details"? } }.

Looking for the endpoints inside a customer?

This page covers fleet operations - provisioning, leases, workers, entitlements - authorized by your key alone.

To drive what is inside a customer organization (agents and flows, connections, domains, triggers, sessions, knowledge, settings), see Customer tenant API. Those endpoints live under /organizations/{orgId}/… and take an extra X-Yekar-Subject header naming the provisioned person the call acts as.

Endpoints

Method and pathCredentialContract
POST /organizationsykp_Provision one customer; requires Idempotency-Key; returns 202.
POST /tokenykp_Mint a one-hour app lease for { orgId, appId }.
POST /worker-tokenykp_Mint a one-hour named-worker lease for { orgId, appId, partnerSubject }.
GET /organizations/:orgId/workersykp_Read mappings for that customer.
POST /organizations/:orgId/workersykp_Vouch a named worker and domain roles.
DELETE /organizations/:orgId/workers/:mappingIdykp_Revoke a mapping.
GET /organizations/:orgId/entitlementsykp_Read default, override, and resolved standing for each agent and flow.
PATCH /organizations/:orgId/automations/:automationId/entitlementykp_Set { "enabled": boolean } as a customer override.
DELETE /organizations/:orgId/automations/:automationId/entitlementykp_Clear the override and return to the platform default.
GET /worker/approvals?limit=&offset=worker ykt_List approvals visible to the named worker; default 50, maximum 100.
POST /worker/approvals/runs/:runIdworker ykt_Decide a run approval with decision, optional comment, and optional approvalId.
POST /worker/approvals/sessions/:sessionIdworker ykt_Decide a turn approval with the same decision contract.
GET /support-sessions/:grantIdykt_Read one support session by the id delivered to you. There is no collection endpoint.

Closed provisioning refusals

Provisioning uses this closed set. Treat error.code as the stable decision field.

CodeMeaningRetry posture
PARTNER_PLATFORM_SUSPENDEDThe platform or partner is not accepting provisioning.Wait for standing to be restored.
PROVISIONING_NOT_ENABLEDThis key is not entitled to create customers.Correct the platform grant.
TEMPLATE_SUSPENDEDThe template is unavailable.Restore the template before retrying.
QUOTA_EXHAUSTEDThe durable customer allowance is exhausted.Raise the allowance; request-rate retries do not help.
IDENTIFIER_TAKENThe requested customer identifier is unavailable.If details.existing is present, reconcile that returned customer; otherwise choose another segment.
CLIENT_SEGMENT_INVALIDThe requested URL segment is invalid.Correct the request.
PROVISIONING_FAILEDProvisioning could not complete.Inspect the returned onboarding state before retrying.

Authentication failures are deliberately neutral. Customer ids outside your platform and nonexistent ids are not distinguishable through protected reads and writes.

Accepted work and retries

202 Accepted means the durable customer record exists; it does not claim every onboarding step has already converged. Read onboardingStatus and the release detail in the response.

Provisioning additionally returns:

  • 409 IDEMPOTENCY_KEY_REUSED when the key was used with a different validated request.
  • 409 IDEMPOTENCY_IN_PROGRESS with Retry-After: 2 while the winner is still executing.
  • 409 IDEMPOTENCY_OUTCOME_UNKNOWN when execution may have crossed the commit boundary but no safe replay could be stored. Do not retry this response blindly.
  • Idempotency-Replayed: true on a successful seven-day replay.

Request-volume limits return 429 with Retry-After. Honor the header and add jitter. Quota refusals are durable business bounds, not rate limits.