DOCSEARCHbyAlgolia
Submit Docs

2600Hz Documentation

website·Indexed Jun 17, 2026

https://docs.2600hz.com

Technical documentation for 2600Hz applications and services, covering core components such as authentication, data access abstraction layers, and notifications. Includes details on the legacy HTTP API, advanced call routing, websockets, and provisioning for various phone hardware including Polycom, Cisco, Yealink, Grandstream, and Obihai.

Tokens
477.3K
Snippets
1K
Records
2.9K
Agent score
50%

What's inside 2600Hz Documentation

  2. Overview of Channel Webhook Events

    2600hz provides several channel-related webhook events that track the lifecycle of a call. While these events share a common base payload, specific fields like custom_channel_vars and custom_application_vars vary depending on the call type.

    Available channel events:

    • channel_create: Triggered when a new channel is created.
    • channel_answer: Triggered when two-way audio is established (e.g., a voicemail box or a party answering).
    • channel_bridge: Triggered when two channels are bridged together (e.g., connecting two users).
    • channel_destroy: Triggered when a channel is destroyed, typically due to a hangup.

  3. Overview of DesktopComm App features

    The DesktopComm App is a unified communications platform designed for business collaboration. Key features include:

    • Unified Communications: Integration of voice, video, messaging, and presence.
    • Team Chat: Real-time instant messaging with colleagues.
    • Voice Calls and Video Meetings: Ability to place/receive voice calls and host/participate in video meetings.
    • Faxes: Sending and receiving faxes.
    • Call Management: Tools for call forwarding, call transfer, and call recording.
    • Voicemails: Access to a virtual voicemail box.

  4. Overview of Trunking.io features and integration

    Trunking.io is a wholesale telecommunications provider that integrates with the 2600Hz platform to provide voice and messaging services. While integrated with the 2600Hz Admin portal, Trunking.io is a distinct legal entity and requires a separate account setup due to FCC regulations.

    Key features include:

    • PSTN Connectivity: Routing numbers across various telecommunications carriers.
    • Number Management: Integrated with 2600Hz; numbers purchased in the 2600Hz Admin portal are automatically fulfilled by Trunking.io.
    • SMS/MMS & Campaign Management: Support for sending/receiving messages and managing texting campaign registrations for federal compliance.
    • STIR/SHAKEN: Provides certificate signing required by the FCC.
    • E911 Integration: Configuration of alerts and emergency addresses for dynamic call routing.
    • Number Porting: Managed flow for porting numbers from other carriers.
    • Self-Service Portal: An independent web portal for service management.

  5. Overview of 2600Hz Early Bill Tasks

    The 2600Hz Early Bill Task is a daily automated process that identifies accounts due for payment and either sends a reminder notification or processes the actual billing. The task triggers a specific number of days before the first day of the next billing cycle (typically the first of the month).

    Execution Logic:

    1. The task checks if the current day falls within the configured 'early days' window.
    2. Billing vs. Reminder: If bill_early_enabled is true (at either system or account level), the system processes the charge. If not, but reminder_enabled is true, it sends a notification.
    3. Idempotency: To prevent multiple charges or notifications in a single cycle, the system checks notifications.low_balance.bill_early_task_timestamp in the account definition. This field stores the timestamp of the next due date. If the current time is not lower than this value, the account is skipped as it has already been processed for this cycle.
    4. Requirement: The account must have service plans assigned for the action to occur.
    5. Completion: Upon success, the due date is saved to notifications.low_balance.bill_early_task_timestamp to mark the account as processed.

  6. Overview of Kazoo Webhooks

    Kazoo Webhooks allow the system to send HTTP GET or POST notifications to a user-defined URL when specific events occur. These webhooks act as subscriptions to allowed events, sending event data to the URI specified in the Webhook document.

    Common use cases include:

    • Informing external services of DTMF tones (e.g., a customer pressing '1').
    • Updating work tracking systems via telephone commands.
    • Tracking agent or sales performance in external CRM/tracking systems.
    • Loading customer profiles into CRM software upon an incoming call.

  7. Overview of kz_cache internal modules

    The kz_cache system is composed of several specialized modules:

    • kz_cache: The primary API module.
    • kz_cache_lru: Manages LRU expiration logic.
    • kz_cache_ets: Handles direct ETS table manipulations.
    • kz_cache_callbacks: Processes lifecycle callbacks.
    • kz_cache_listener: An AMQP listener that enables self-flushing when document changes are detected.
    • kz_cache_nodes: Listens for new or expiring nodes via kz_nodes.
    • kz_cache_processes: Monitors PIDs if an entry is stored with {'monitor', true} or {'monitor', [pid()]} and removes the entry if the PID dies.
    • kz_cache_callbacks: Callback processor module.

  8. Overview of MobileComm App Team Chat functionality

    The Team Chat module in the MobileComm App acts as an internet-based messenger. Key constraints and features include:

    • Contact Scope: Messaging is strictly limited to contacts within the Company contact list.
    • Connectivity: It does not use SMS; it functions exclusively over the Internet.
    • Recipient Selection: To start a chat, press the Pencil button to open the Company contact list and select one or more colleagues.

  9. Overview of kapps_notify_publisher

    The kapps_notify_publisher is a wrapper around kz_amqp_worker and kapi_notifications used to publish notifications reliably to the teletype application (or the deprecated notify app).

    It uses kz_amqp_worker:call_collect/4 to wait for a response from the target application. If a timeout or error occurs during publishing, the notification payload is saved to a pending_notifications database. These failed notifications are subsequently retried by the kz_notify_resender task within the Tasks app.

  11. Overview of Blackhole WebSocket Server

    Blackhole acts as a two-way communication bridge between 2600Hz and your application or system using the WebSocket protocol. It allows you to interact with 2600Hz and subscribe to real-time events that are streamed directly to your connected sessions. While primarily designed for JavaScript applications (running in browsers or on servers), the protocol can be implemented in any programming language that supports WebSockets.

  12. Overview of Crossbar REST API

    The Crossbar REST API allows external applications to interact with 2600Hz telecom services via HTTP requests. Most requests and responses use JSON format and follow JSON-Schema for data validation.

    Common capabilities include:

    • Managing account and sub-account settings.
    • Retrieving lists of devices, users, and other resources.
    • Purchasing and porting phone numbers.
    • Creating callflows and assigning numbers to users.
    • Managing office settings (Open/After Hours, Menus, Voicemail).