Developers and AI agents reading AYA integration documentation.
Index the primary developer documentation hub.
Documentation map
The docs cover getting started, REST APIs, MCP integration, ChatGPT Actions, authentication, webhooks, examples, and API reference material. Important paths include /docs/api, /docs/auth, /docs/mcp, /docs/chatgpt, /docs/webhooks, /docs/examples, and /docs/reference.
Integration goal
The developer platform makes AYA research workflows addressable from external products and AI assistants while preserving clear authorization, workspace scope, and asynchronous job status. Public docs explain concepts; authenticated console pages manage keys and account details.
Common request shape
Most API calls use JSON bodies, an Authorization: Bearer header, a workspace context, and stable identifiers for audiences, concepts, jobs, or reports. Errors should be handled by status code, machine-readable code, and request identifier where available.
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.