Developers integrating AYA REST endpoints into applications and agent workflows.
Make AYA API capabilities and entry points discoverable.
REST capabilities
AYA API documentation covers panel resolution, quick pulse jobs, concept tests, job status, and integration patterns for product teams. Example paths include /v1/panels/resolve, /v1/pulses, /v1/concept-tests, /v1/jobs/{job_id}, and /v1/reports/{report_id} where enabled for the workspace.
Implementation path
Developers should start with authentication, choose the workflow endpoint that matches the research job, submit a clear audience and stimulus payload, store returned job identifiers, poll or receive webhooks for status, and render reports only after completion.
Errors and limits
Integrations should handle 400 validation errors, 401 or 403 authorization failures, 404 missing workspace resources, 409 conflicting job state, 422 unsupported brief inputs, 429 rate limits, and 5xx retryable platform errors with idempotent retry logic.
Developer evaluation path
Technical buyers should use the developer pages to understand the public integration surface, authentication model, connector routes, API concepts, and documentation map before building against AYA. Private consoles and account-specific tools remain outside the crawlable marketing surface.
AI agent context
These pages are written so coding assistants and retrieval agents can distinguish AYA APIs, MCP connectors, ChatGPT Actions, install guides, and reference material from the general product marketing pages.
Implementation boundary
A useful developer journey starts with the public docs, then moves into authenticated workspace setup only when the buyer is ready. Public documentation should explain what an integration can do, which workflows are available, how authentication is approached, how job status is handled, and where examples or reference material sit. It should not expose private customer data, secret tokens, or account-specific console routes to search engines.