> ## Documentation Index > Fetch the complete documentation index at: https://docs.vocily.ai/llms.txt > Use this file to discover all available pages before exploring further. # WhatsApp numbers > The connected WhatsApp numbers an agent can answer on. `number` is what goes in an agent's `numbers.inbound_whatsapp`; `phone_number_id` is what `builtin_tools.send_whatsapp_template.phone_number_id` takes. | | | | ------------------- | ---------------------------------------------------------------------------------------------------------- | | `status` | Our connection state | | `meta_status` | What WhatsApp Manager shows. Both are published because a number can be live on one side and not the other | | `assigned_agent_id` | Which agent answers on it today, if any | Connecting a WhatsApp Business account is a dashboard action. ## OpenAPI ````yaml developers/openapi.json GET /v1/whatsapp/numbers openapi: 3.1.0 info: title: Vocily API description: >- Public REST API for Vocily. Build and configure an agent, publish a version and put it live, place outbound calls, and read back calls, chats and what the agent remembered. Authenticate with a workspace API key as a Bearer token. Some things stay in the dashboard, by design: creating an API key, buying or connecting a phone number, setting an agent's webhook URL, connecting WhatsApp and its templates, building HTTP tools, and running batch campaigns. version: v1 servers: - url: https://api.vocily.ai description: Production security: [] paths: /v1/whatsapp/numbers: get: tags: - catalogues summary: List Whatsapp Numbers description: >- Connected WhatsApp numbers, for `numbers.inbound_whatsapp`. `phone_number_id` is what `builtin_tools.send_whatsapp_template.phone_number_id` takes. `status` is the connection state on Vocily; `meta_status` is what WhatsApp Manager shows — both, because "why can't this number send" needs both. operationId: list_whatsapp_numbers_v1_whatsapp_numbers_get parameters: [] responses: '200': description: The workspace's connected WhatsApp numbers. content: application/json: schema: type: array items: type: object properties: id: type: string phone_number_id: type: string description: >- What `builtin_tools.send_whatsapp_template.phone_number_id` takes. number: type: string description: E.164. What goes in `numbers.inbound_whatsapp`. verified_name: type: string nullable: true status: type: string description: Our connection state. meta_status: type: string nullable: true description: >- What WhatsApp Manager shows. Published alongside `status` because a number can be live on one side and not the other. assigned_agent_id: type: string nullable: true description: Which agent answers on it today, if any. example: - id: 00000001-0000-4000-8000-000000000001 phone_number_id: '1160636770473887' number: '+919278045657' verified_name: Lily from Vocily status: active meta_status: CONNECTED assigned_agent_id: 00000002-0000-4000-8000-000000000002 '401': description: Missing or invalid API key. content: application/json: schema: $ref: '#/components/schemas/ApiError' example: detail: Invalid API key code: UNAUTHORIZED '422': description: Validation Error content: application/json: schema: $ref: '#/components/schemas/HTTPValidationError' '429': description: Rate limit exceeded — honor `Retry-After`. content: application/json: schema: $ref: '#/components/schemas/ApiError' example: code: rate_limited security: - bearerAuth: [] components: schemas: ApiError: type: object description: >- Error envelope. `code` is derived from the HTTP status, so branch on it for the CLASS of failure; the specific reason is `detail.code`. Every public refusal carries both. properties: detail: type: object description: >- The reason. `code` is the domain reason (e.g. `call_not_found`) and `message` is a sentence safe to log. On a `422` it also carries `errors[]`, one entry per rejected field — see `HTTPValidationError`. properties: code: type: string example: call_not_found message: type: string example: Call not found required: - code - message code: type: string description: Derived from the HTTP status, not the domain reason. example: NOT_FOUND HTTPValidationError: type: object title: HTTPValidationError description: >- A request the API could not read: a field of the wrong type, out of range, missing, or one we do not accept. Same envelope as every other error. properties: detail: type: object description: >- What was wrong, as `code`, a one-line `message`, and every offending field in `errors`. required: - code - message - errors properties: code: type: string enum: - validation_error message: type: string description: >- The first problem in one line, with a count of the rest — e.g. `model.temperature: Input should be less than or equal to 2 (and 1 more)`. errors: type: array items: $ref: '#/components/schemas/ValidationError' description: >- One entry per offending field. **Every problem is reported at once**, not just the first, so a malformed body needs one round trip to fix rather than one per field. code: type: string enum: - VALIDATION_ERROR description: Derived from the HTTP status, as on every error. ValidationError: type: object title: ValidationError required: - field - message - type properties: field: type: string description: >- The offending field as a path from the root of your request — `voice.speed`, `variables[0].key`, or `query.limit` for a query parameter. **This is the field to read.** message: type: string description: What is wrong with it, in plain language. type: type: string description: >- A stable machine code for the kind of failure, e.g. `extra_forbidden` for a field we do not accept, `missing` for a required one, or `less_than_equal` for a number out of range. Switch on this rather than on `message`, which may be reworded. securitySchemes: bearerAuth: type: http scheme: bearer description: 'Your API key as a Bearer token, e.g. `Authorization: Bearer vk_…`.' ````