Birdy APIdocs.birdy.chat ↗
Access structured data from the BirdyChat Integrations OpenAPI spec: operations, schemas, tags, webhooks, and field definitions across bots, channels, threads, and messaging.
What is the Birdy API?
This API surfaces structured data from the BirdyChat Integrations API OpenAPI specification across 3 endpoints, covering operations grouped by tag, full per-operation detail, and named component schema definitions. The get_operation_detail endpoint returns HTTP method, path, parameters, request body fields, and response schemas for any named operation — such as createIntegration, listThreadMessages, or addThreadUsers — by operation ID.
No input parameters required.
curl -X GET 'https://api.parse.bot/scraper/474d99f0-02c9-4f92-b5fa-2b2b065714b9/get_api_overview' \ -H 'X-API-Key: $PARSE_API_KEY'
Returns a high-level overview of all BirdyChat API operations grouped by tag, including authentication details, rate limits, webhook information, server URL, and the complete list of operations with their IDs, HTTP methods, paths, and summaries. One round trip to the public OpenAPI spec.
No input parameters required.
{
"type": "object",
"fields": {
"tags": "Array of tag objects with name and description",
"title": "API title string",
"version": "API version string",
"base_url": "Production server URL",
"webhooks": "Array of webhook definitions with name, summary, description",
"rate_limit": "Rate limit description",
"tag_groups": "Array of tag group objects organizing tags into categories",
"description": "Full API description with auth, reliability, error, and webhook documentation",
"authentication": "Authentication method description",
"operations_by_tag": "Object keyed by tag name, each containing array of operations with operation_id, method, path, summary"
},
"sample": {
"tags": [
{
"name": "Threads",
"description": "Thread resources and related operations."
},
{
"name": "Messages",
"description": "Message resources and related operations."
}
],
"title": "BirdyChat Integrations API",
"version": "v1",
"base_url": "https://birdy.chat/api/v1",
"webhooks": [
{
"name": "integrationEvent",
"summary": "Outbound integration webhook delivery",
"description": "BirdyChat sends this webhook to integration-configured webhook URLs."
}
],
"rate_limit": "500 requests per minute shared across endpoints",
"tag_groups": [
{
"name": "Core Messaging",
"tags": [
"Threads",
"Messages",
"Scheduled Messages"
]
}
],
"authentication": "Bearer token (sk_...)",
"operations_by_tag": {
"Threads": [
{
"path": "/threads",
"method": "GET",
"summary": "List threads",
"operation_id": "listThreads"
},
{
"path": "/threads",
"method": "POST",
"summary": "Create thread",
"operation_id": "createThread"
}
],
"Messages": [
{
"path": "/threads/{thread_id}/messages",
"method": "GET",
"summary": "List messages in thread",
"operation_id": "listThreadMessages"
}
]
}
}
}About the Birdy API
What the API Returns
The three endpoints cover three levels of the BirdyChat OpenAPI spec. get_api_overview returns the complete operation index — every operation grouped by tag with its operation_id, HTTP method, path, and summary — along with the server base URL, authentication description, rate limit notes, webhook definitions, and tag group structure. This is useful for building navigation or discovery tools without parsing a raw spec file.
Per-Operation and Schema Detail
get_operation_detail accepts an operation_id string (e.g. createIntegration, listThreadMessages) and returns the full operation record: method, path, all parameters with their names, locations (in), required flags, descriptions, and schemas, the request_body definition including content type and field list, and responses keyed by HTTP status code with per-field descriptions. For GET operations, request_body is returned as null.
get_schema_detail accepts a schema_name (e.g. Thread, Message, Channel, User, Integration, Event, WebhookEvent) and returns every field with its type, required status, description, pattern, and enum values where applicable. Nested schemas are resolved one level deep and returned under nested_schemas, giving callers a complete field map without additional lookups for most common data shapes.
Coverage Scope
The API reflects the publicly available BirdyChat Integrations OpenAPI specification. Functional areas covered include bot and integration creation, channel management, thread and message operations, event handling, webhooks, user management, permissions, and attachments — matching the tag groups exposed by get_api_overview. The data is spec-level: it describes the BirdyChat API surface rather than returning live chat messages or user records.
The Birdy API is a managed, monitored endpoint for docs.birdy.chat — not a raw scraper you maintain. Every endpoint is automatically health-checked on a schedule, and when docs.birdy.chat changes and a check fails, the API is automatically queued for repair and re-verified. It is built to keep working as the site underneath it changes.
This isn't an official docs.birdy.chat API — it's an independent, maintained REST wrapper over public data. Where the source has no official API (or only a limited one), Parse gives you a stable contract over a source that never promised one, and keeps it current. Need a new endpoint or field? You can revise it yourself in plain English and the agent rebuilds it against the live site in minutes — contributing the change back to the shared API is free.
Will this API break when the source site changes?+
Is this an official API from the source site?+
Can I fix or extend this API myself if I need a new endpoint or field?+
What happens if I call an endpoint that has an issue?+
- Auto-generate SDK client code by iterating operations from
get_api_overviewand fetching full parameter schemas viaget_operation_detail. - Build internal API documentation portals that render field descriptions, types, and enums from
get_schema_detailresponses. - Validate integration payloads by checking required fields and patterns returned for schemas like
IntegrationorWebhookEvent. - Produce Postman collections or OpenAPI-compatible test suites by extracting method, path, and request body definitions per operation.
- Create onboarding guides for BirdyChat bots that list all thread and messaging operations grouped by the tags returned in
operations_by_tag. - Audit webhook coverage by inspecting the
webhooksarray fromget_api_overviewalongside their summaries and descriptions.
| Tier | Price | Credits/month | Rate limit |
|---|---|---|---|
| Free | $0/mo | 100 | 5 req/min |
| Hobby | $30/mo | 1,000 | 20 req/min |
| Developer | $100/mo | 5,000 | 100 req/min |
One credit = one API call regardless of which marketplace API you call. Exceeding the rate limit returns a 429 response. Authenticate with the X-API-Key header.
Does BirdyChat have an official developer API?+
What does `get_operation_detail` return for an operation like `listThreadMessages`?+
method, path, all parameters (each with name, location, required flag, description, and schema), request_body (null for GET operations), and responses keyed by status code — each with a description, schema name, and field-level definitions. You pass the exact operation_id string as the required input parameter.Does `get_schema_detail` resolve deeply nested schemas, such as schemas within schemas more than one level deep?+
nested_schemas. Fields that reference schemas beyond that level are not further expanded. You can fork this API on Parse and revise it to add recursive resolution for deeper nesting if your use case requires it.Can I retrieve live chat messages or real-time user data through this API?+
Is there a way to search or filter operations by path pattern or HTTP method rather than by tag?+
get_api_overview returns operations_by_tag, which organizes all operations under their tag names. There is no built-in filter by method or path pattern. You can fork this API on Parse and revise it to add a filtered endpoint that accepts method or path substring as query parameters.