Integration status
Eighteen audited capabilities have code, route, test, or contract evidence. Sandbox, Swagger, Postman Collection, and SDK remain blocked.
Developers
Review authentication, request lifecycle, results, idempotency, webhooks, security guidance, and capability maturity without invented SDKs or endpoints.
Eighteen audited capabilities have code, route, test, or contract evidence. Sandbox, Swagger, Postman Collection, and SDK remain blocked.
Existing REST-style JSON routes cover selected contact-data and workspace workflows; this hub does not add endpoints.
Existing API-key controls bind access to authorized account and workspace scope.
Requests pass authentication, scope, input, policy, and operation checks before a normalized response.
Integrations must handle success, partial, unavailable, invalid, unauthorized, limited, and safe internal-error outcomes.
Supported write operations use existing idempotency controls; callers must follow the documented contract.
Webhook configuration, signing, delivery history, and retries remain governed by current permissions and maturity.
Internal mock-provider execution is isolated and zero-live; no public sandbox is available.
Keep keys server-side, apply least privilege, rotate access, verify webhook signatures, and never expose credentials in client code.
A route or class does not prove live availability. Use the capability status before planning an integration.
Status is limited to Available, Implemented Not Deployed, Approval Required, or Blocked.
These links point to existing product surfaces. Authentication and maturity controls still apply.
Start with governed access
Use existing account controls to manage approved access; this hub does not enable blocked developer capabilities.