> ## Documentation Index > Fetch the complete documentation index at: https://docs.zenzap.co/llms.txt > Use this file to discover all available pages before exploring further. # Issue an OAuth access token > Exchanges OAuth client credentials for a short-lived bearer access token. Only the **`client_credentials`** grant is supported on this endpoint. Use the `clientId` and `clientSecret` returned when the bot was created (or rotated) in your Zenzap admin console. **Client authentication**: either send `client_id` + `client_secret` in the form body, or use HTTP Basic Auth with the same values (`Authorization: Basic base64(clientId:clientSecret)`). **Scopes**: omit the `scope` field to receive a token with all scopes configured on the bot, or pass a space-separated subset to down-scope. Requesting a scope that the bot was not granted at creation will fail. **Token lifetime**: 1 hour. There is **no refresh token** — re-mint with the client credentials when the token expires. Tokens are JWTs bound to the issuing region and to the bot. They are validated on every request. See [Authentication](/api-reference/authentication) for the full reference. ## OpenAPI ````yaml /openapi.yaml post /oauth/token openapi: 3.0.3 info: title: Zenzap External Integration API description: > API for external applications to integrate with Zenzap. ## Getting Started Welcome to the Zenzap External Integration API documentation. This API is used to integrate with Zenzap. As a context we would like to familiarize you with the Zenzap platform and how it works. Zenzap is a platform for creating and managing topics and messages. Topics (Zenzap term for group chats/channels/conversations) are used to create and manage conversations with your team. Topics are used to group messages and tasks together. Messages are used to send and receive messages with your team. Tasks are used to create and manage tasks with your team. Members are used to manage your team members. API keys are used to authenticate your requests to the Zenzap API. API keys are created and managed by the Zenzap admin user. When you create a new API key, it would create a new bot user in Zenzap, on which behalf you can send messages, create topics, create tasks and manage members. All actions you perform with the API key will be performed on behalf of the bot user. The bot can be used within the scope of your organization. You can create topics, send messages, create tasks and manage members on behalf of the bot. 1. On a Zenzap admin user, go to https://app.zenzap.co/console 2. Create a new API key with the needed permissions 3. Copy the API key and secret from the API key settings 4. For each request: - Add the Authorization header with your API key - Generate a Unix timestamp in milliseconds - Calculate the HMAC-SHA256 signature: - For POST/PUT/PATCH/DELETE: Sign `{timestamp}.{body}` - For GET: Sign `{timestamp}.{uri}` (e.g., `/v2/members?limit=10`) - Add the X-Signature header with the hex-encoded signature - Add the X-Timestamp header with the timestamp used in the payload ## Authentication All API endpoints require two forms of authentication: 1. **Bearer Token**: Include your API key in the Authorization header: ``` Authorization: Bearer YOUR_API_KEY ``` 2. **Request Signing**: Include an HMAC signature and timestamp in headers: ``` X-Signature: X-Timestamp: ``` The signature includes a timestamp for replay protection. Requests older than 5 minutes are rejected. The signature payload differs by HTTP method: - **POST/PUT/PATCH/DELETE requests**: Sign `{timestamp}.{body}` - **GET requests**: Sign `{timestamp}.{uri}` The signature is calculated using HMAC-SHA256 with your API secret. **How to calculate:** 1. Get the current Unix timestamp in milliseconds 2. Determine the payload: - **POST/PUT/PATCH/DELETE**: Use `{timestamp}.{body}` (e.g., `1699564800000.{"topicId":"123"}`) - **GET**: Use `{timestamp}.{uri}` (e.g., `1699564800000./v2/members?limit=10`) 3. Calculate HMAC-SHA256 of the payload using your API secret 4. Hex-encode the result (64 character lowercase string) 5. Include timestamp in X-Timestamp header **Example (Python):** ```python import json import hmac import hashlib import time import requests def create_topic(name: str, members: list[str], description: str = None, external_id: str = None) -> dict: """Create a topic in Zenzap with HMAC signature and replay protection.""" # Build request body body = { "name": name, "members": members, } if description: body["description"] = description if external_id: body["externalId"] = external_id # Serialize body (no spaces for consistent signing) body_json = json.dumps(body, separators=(",", ":")) # Get timestamp for replay protection timestamp = int(time.time() * 1000) # Unix milliseconds # Create HMAC-SHA256 signature with timestamp signature_payload = f"{timestamp}.{body_json}" signature = hmac.new( API_SECRET.encode(), signature_payload.encode(), hashlib.sha256 ).hexdigest() # Make request headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json", "X-Signature": signature, "X-Timestamp": str(timestamp), } response = requests.post(f"{BASE_URL}/v2/topics", headers=headers, data=body_json) response.raise_for_status() return response.json() ``` **Note:** Our API documentation tools cannot automatically generate HMAC signatures. You will need to calculate this manually or use a tool like Postman with pre-request scripts. ## Rate Limits API requests are rate limited per organization. Contact support for specific limits. version: 2.0.0 contact: name: Zenzap Support url: https://zenzap.co/support servers: - url: https://api.zenzap.co description: Production server security: - bearerAuth: [] hmacSignature: [] - oauth2ClientCredentials: [] tags: - name: OAuth description: > OAuth 2.0 `client_credentials` grant. Used by API-key bots that were created with `credentialType: oauth` to mint short-lived bearer access tokens. **In a nutshell:** 1. Get a `clientId` and `clientSecret` from your bot in the Zenzap admin console. The `clientSecret` is shown once at creation; if lost, rotate it from the same screen. 2. `POST /oauth/token` with `grant_type=client_credentials` to receive a JWT access token (1-hour TTL). 3. Call any `/v2/*` endpoint with `Authorization: Bearer `. No `X-Signature` / `X-Timestamp` headers are needed on the OAuth path. 4. Re-mint when the token expires. There is **no refresh token**. Scopes are granular per endpoint — see the [Authentication page](/api-reference/authentication#oauth-scopes) for the full scope catalog and the endpoint → scope mapping. - name: Polls description: > Operations for creating polls, recording votes, and retracting votes. Polls are posted as messages in a topic. When you create a poll, each option is assigned a server-generated 6-character ID — use those IDs as `optionId` when submitting votes. **Voting constraints:** - The bot must be a member of the topic the poll was posted in - Anonymous polls (`anonymous: true`) do not support voting via the API - Votes cannot be cast on closed or expired polls - Each `{pollId, optionId, voter}` combination is idempotent - Votes can be retracted with `DELETE /v2/polls/{pollId}/votes/{voteId}` using the `id` returned when the vote was cast - name: Agentic description: > Endpoints for AI agents to programmatically set up Zenzap organizations. Use `POST /v2/agentic/organization/create` to create an organization, install a bot, and invite a human user in a single request — no authentication required. - name: Messages description: Operations for sending messages - name: Topics (group chats/channels/conversations) description: Operations for managing topics (group chats/channels/conversations) - name: Tasks description: Operations for managing tasks - name: Members description: Operations for retrieving organization members - name: Long Polling description: > Long polling allows your integration to fetch outbound events instead of receiving webhooks. Use `GET /v2/updates` with: - `offset`: value returned as `nextOffset` from the previous response - `limit`: max updates per request (default 50, max 100) - `timeout`: wait time in seconds when no updates are available (default 0, max 30) Event payloads in polling responses match webhook `data` payloads for the same event type. This includes `data.message.attachments[]` with signed URLs for file/image/video/audio messages. - name: Webhooks description: > Webhooks allow your application to receive real-time notifications when events occur in Zenzap. Configure your webhook URL in the Zenzap console for your API key. ## Webhook Headers Each webhook delivery includes the following headers: - `X-Zenzap-Event`: The event type (e.g., `message.created`) - `X-Zenzap-Signature`: HMAC-SHA256 signature for verification - `X-Zenzap-Timestamp`: Unix timestamp (milliseconds) when the webhook was sent - `X-Zenzap-Delivery-Id`: Unique ID for this delivery (for deduplication) ## Signature Verification Webhooks are signed using the same API secret (`BOT_SECRET`) used for request signing. Verify webhooks by calculating: ``` expected = HMAC-SHA256(BOT_SECRET, "{timestamp}.{body}") ``` Where `{timestamp}` is from `X-Zenzap-Timestamp` and `{body}` is the raw request body. If the request includes `Content-Encoding: gzip`, decompress before verifying. ## Webhook Payload Format All webhook events follow the same envelope structure (see `WebhookEvent` schema): ```json { "id": "evt_550e8400-e29b-41d4-a716-446655440099", "type": "message.created", "eventVersion": 1, "timestamp": 1699564800000, "data": { ... } } ``` The `data` field contents vary by event type. See the schemas section for detailed payload structures. ## Event Types ### Message Events | Event | Trigger | Data Schema | |-------|---------|-------------| | `message.created` | New message sent | `WebhookMessageCreatedEvent` | | `message.updated` | Message edited or transcription completed | `WebhookMessageUpdatedEvent` | | `message.deleted` | Message deleted | `WebhookMessageDeletedEvent` | ### Reaction Events | Event | Trigger | Data Schema | |-------|---------|-------------| | `reaction.added` | Emoji reaction added | `WebhookReactionAddedEvent` | | `reaction.removed` | Emoji reaction removed | `WebhookReactionRemovedEvent` | ### Member Events | Event | Trigger | Data Schema | |-------|---------|-------------| | `member.added` | User added to topic | `WebhookMemberAddedEvent` | | `member.removed` | User removed from topic | `WebhookMemberRemovedEvent` | ### Topic Events | Event | Trigger | Data Schema | |-------|---------|-------------| | `topic.updated` | Topic name/description changed | `WebhookTopicUpdatedEvent` | ## Message Types Messages can have different types based on their content: | Type | Description | Additional Fields | |------|-------------|-------------------| | `text` | Regular text message | `text` | | `image`, `file`, `video`, `audio` | Message with attachment | `attachments[]` | | `location` | Shared location | `location` | | `task` | Task snapshot | `task` | | `contact` | Shared contact | `contact` | ## Attachments & File Access Attachment URLs in webhook payloads are signed and **expire after 60 minutes**. Download files promptly after receiving the webhook. ```json { "id": "att_...", "type": "image", "name": "screenshot.png", "url": "https://storage.zenzap.co/attachments/...?token=...&expires=..." } ``` ## Voice Message Transcription Voice messages (audio attachments) are automatically transcribed: 1. **`message.created`** - Initial message with `transcription.status: "Pending"` 2. **`message.updated`** - Fired when transcription completes with `status: "Done"` ```json { "attachments": [{ "type": "audio", "name": "voice-note.mp3", "url": "https://...", "transcription": { "status": "Done", "text": "Hey team, just a quick update..." } }] } ``` ## Reply Messages Messages that reply to other messages include: - `parentId`: UUID of the message being replied to paths: /oauth/token: post: tags: - OAuth summary: Issue an OAuth access token description: > Exchanges OAuth client credentials for a short-lived bearer access token. Only the **`client_credentials`** grant is supported on this endpoint. Use the `clientId` and `clientSecret` returned when the bot was created (or rotated) in your Zenzap admin console. **Client authentication**: either send `client_id` + `client_secret` in the form body, or use HTTP Basic Auth with the same values (`Authorization: Basic base64(clientId:clientSecret)`). **Scopes**: omit the `scope` field to receive a token with all scopes configured on the bot, or pass a space-separated subset to down-scope. Requesting a scope that the bot was not granted at creation will fail. **Token lifetime**: 1 hour. There is **no refresh token** — re-mint with the client credentials when the token expires. Tokens are JWTs bound to the issuing region and to the bot. They are validated on every request. See [Authentication](/api-reference/authentication) for the full reference. operationId: issueOAuthToken requestBody: required: true content: application/x-www-form-urlencoded: schema: $ref: '#/components/schemas/OAuthTokenRequest' examples: clientCredentialsBody: summary: Credentials in form body value: grant_type: client_credentials client_id: b@660e8400-e29b-41d4-a716-446655440003 client_secret: very-long-random-secret withScope: summary: Down-scoped request value: grant_type: client_credentials client_id: b@660e8400-e29b-41d4-a716-446655440003 client_secret: very-long-random-secret scope: channel:list message:send basicAuth: summary: >- Credentials via HTTP Basic (omit client_id / client_secret in body) value: grant_type: client_credentials responses: '200': description: Access token issued content: application/json: schema: $ref: '#/components/schemas/OAuthTokenResponse' example: access_token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... token_type: Bearer expires_in: 3600 scope: channel:list message:send '400': description: >- Invalid request (missing parameters, unsupported grant type, or requested scopes not allowed for the client) content: application/json: schema: $ref: '#/components/schemas/OAuthErrorResponse' examples: unsupportedGrant: summary: Unsupported grant type value: error: unsupported_grant_type error_description: unsupported grant_type invalidGrant: summary: Invalid client credentials or scope value: error: invalid_grant error_description: invalid client credentials or scopes '401': description: Client authentication failed content: application/json: schema: $ref: '#/components/schemas/OAuthErrorResponse' example: error: invalid_client error_description: missing client_secret security: [] components: schemas: OAuthTokenRequest: type: object required: - grant_type properties: grant_type: type: string enum: - client_credentials description: OAuth 2.0 grant type. Only `client_credentials` is supported. client_id: type: string description: >- The bot's OAuth `clientId` (returned when the bot was created or rotated). Omit if you authenticate via HTTP Basic Auth. example: b@660e8400-e29b-41d4-a716-446655440003 client_secret: type: string description: >- The bot's OAuth `clientSecret`. Omit if you authenticate via HTTP Basic Auth. example: very-long-random-secret scope: type: string description: > Space-separated list of OAuth scopes to request. Optional — if omitted, the issued token receives every scope the bot was granted at creation. Passing a scope the bot was not granted will fail with `invalid_grant`. example: channel:list message:send OAuthTokenResponse: type: object required: - access_token - token_type - expires_in properties: access_token: type: string description: > JWT bearer token. Pass as `Authorization: Bearer ` on every API request. token_type: type: string enum: - Bearer description: Always `Bearer`. expires_in: type: integer format: int64 description: Token lifetime in seconds (default 3600 = 1 hour). example: 3600 scope: type: string description: Space-separated list of scopes granted to this token. example: channel:list message:send OAuthErrorResponse: type: object required: - error properties: error: type: string description: RFC 6749 §5.2 error code. enum: - invalid_request - invalid_client - invalid_grant - unsupported_grant_type - invalid_scope error_description: type: string description: >- Human-readable explanation. Safe to surface to operators; not localized. securitySchemes: bearerAuth: type: http scheme: bearer description: > Bearer token for the request. Two flavors: - **Static API key** — pass your API key (the value returned as `apiKey` when the bot was created). Must be paired with `X-Signature` + `X-Timestamp` (the `hmacSignature` scheme). - **OAuth access token** — pass the JWT returned by `POST /oauth/token`. No signature headers are required. hmacSignature: type: apiKey in: header name: X-Signature description: > HMAC-SHA256 signature for request verification. Required **only** when authenticating with a static API key. Omit when using an OAuth access token. oauth2ClientCredentials: type: oauth2 description: > OAuth 2.0 `client_credentials` grant for API-key bots. Use the `clientId` and `clientSecret` returned when the bot was created (or rotated) to mint short-lived access tokens. See [Authentication](/api-reference/authentication) for details. Access tokens are bearer JWTs and expire after 1 hour. There is no refresh token — re-mint with the client credentials when the token expires. flows: clientCredentials: tokenUrl: https://api.zenzap.co/oauth/token scopes: channel:list: List topics the bot belongs to channel:read: Read topic metadata channel:write: Create/update topics and manage members message:read: Read messages message:send: Send messages message:write: Edit / delete / mark-delivered / mark-read messages reaction:write: Add and remove reactions on messages task:read: Read tasks task:write: Create / update / delete tasks poll:write: Create polls and cast / retract votes member:read: List organization members updates:read: Long-poll for outbound events ````