# Authentication
Source: https://www.quo.com/docs/mdx/api-reference/authentication

Learn how to gain API access.

## Prerequisites

Before you begin using the Quo API, ensure you have:

<CardGroup>
  <Card title="An active Quo subscription" icon="check">
    Need an account? Follow our [account creation
    guide](https://support.openphone.com/hc/en-us/articles/1500009886621-How-to-create-an-OpenPhone-account).
  </Card>

  <Card title="Admin access" icon="user-shield">
    Owner or admin privileges in your Quo workspace.
  </Card>
</CardGroup>

<Warning>
  **US Messaging Registration Required:** To send text messages to US numbers
  via the API, you must complete US Carrier Registration. Learn more
  [here](https://support.openphone.com/hc/en-us/articles/15519949741463-Guide-to-US-carrier-registration-for-OpenPhone-customers).
</Warning>

## API key generation

The Quo API uses API keys for secure authentication. Follow these steps to get started:

<Steps>
  <Step title="Log in to Quo">Access your Quo account.</Step>

  <Step title="Access API Settings">
    Navigate to the "API" tab under workspace settings. Remember, you need
    workspace owner or admin privileges to access this tab.
  </Step>

  <Step title="Generate your key">
    Click "Generate API key" and provide a descriptive label. Each key provides
    full API access.

    <Tip>
      Name your API key based on its intended use (e.g., "production-environment" or "testing-integration"). Spaces are not allowed in the API key name.
    </Tip>
  </Step>

  <Step title="Implement authentication">
    Include your API key in the Authorization header of each request: `    Authorization: YOUR_API_KEY`
    <Tip>The Quo API does not use a Bearer token for authentication.</Tip>
  </Step>
</Steps>

## Security guidelines

<Info>
  Your API key carries the same privileges as your Quo account. Treat it
  with the same level of security as your password.
</Info>

### Best practices

* Keep your API keys confidential
* Don’t share your API keys in publicly accessible areas such as GitHub or client-side code
* Regularly rotate your API keys to enhance security
* If a key is compromised, revoke it immediately and generate a new one

### Revoking access

If a key is compromised or no longer needed:

1. Navigate to the "API" tab in Workspace Settings
2. Locate the specific key
3. Click the ellipsis (three dots) icon and select "Delete" to immediately revoke access
4. Generate a new key if needed

<Note>
  Deleting an API key only affects the integrations using that specific key.
  Other keys and integrations will continue to function normally.
</Note>


# Get a call by ID
Source: https://www.quo.com/docs/mdx/api-reference/calls/get-a-call-by-id

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json get /v1/calls/{callId}
Get a call by its unique identifier.



# Get a summary for a call
Source: https://www.quo.com/docs/mdx/api-reference/calls/get-a-summary-for-a-call

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json get /v1/call-summaries/{callId}
Retrieve a detailed summary of a specific call identified by its unique call ID. This endpoint supports summaries for both regular calls and calls handled by Sona. Call summaries are only available on business and scale plans.



# Get a transcription for a call
Source: https://www.quo.com/docs/mdx/api-reference/calls/get-a-transcription-for-a-call

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json get /v1/call-transcripts/{id}
Retrieve a detailed transcript of a specific call identified by its unique call ID. This endpoint supports transcripts for both regular calls and calls handled by Sona. Call transcripts are only available on business and scale plans.



# Get a voicemail for a call
Source: https://www.quo.com/docs/mdx/api-reference/calls/get-a-voicemail-for-a-call

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json get /v1/call-voicemails/{callId}
Retrieve a voicemail associated with a specific call. Returns null data fields while the voicemail is processing in our system. Returns competed data fields when the voicemail has finished processing.



# Get recordings for a call
Source: https://www.quo.com/docs/mdx/api-reference/calls/get-recordings-for-a-call

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json get /v1/call-recordings/{callId}
Retrieve a list of recordings associated with a specific call. The results are sorted chronologically, with the oldest recording segment appearing first in the list.



# List calls
Source: https://www.quo.com/docs/mdx/api-reference/calls/list-calls

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json get /v1/calls
Fetch a paginated list of calls associated with a specific Quo number and another number.



# Changelog
Source: https://www.quo.com/docs/mdx/api-reference/changelog

Stay up to date with the latest improvements to the API. View [main product Changelog.](https://support.quo.com/changelog)

<Update label="June 18, 2026" description="Messages endpoints: conversationId in responses and participants filter">
  ### Added

  **`conversationId` in message responses.** All messages endpoints now include `conversationId` in the response body.

  **Group messaging support.** [`GET /v1/messages`](/docs/mdx/api-reference/messages/list-messages) now supports retrieving group conversation messages via the `participants` array.
</Update>

<Update label="June 16, 2026" description="Mark conversations as done or open">
  ### Added

  **Mark a conversation as done.** [`POST /v1/conversations/{conversationId}/mark-as-done`](/docs/mdx/api-reference/conversations/mark-conversation-as-done) removes a conversation from the inbox without sending a message and returns the updated conversation.

  **Mark a conversation as open.** [`POST /v1/conversations/{conversationId}/mark-as-open`](/docs/mdx/api-reference/conversations/mark-conversation-as-open) moves a conversation back to the inbox without sending a message and returns the updated conversation.
</Update>

<Update label="June 16, 2026" description="Group messages">
  ### Added

  **Group messages.** [`POST /v1/messages`](/docs/mdx/api-reference/messages/send-a-text-message) now accepts up to 10 phone numbers in the `to` array, sending a single group message to all recipients at once. Sending to a single recipient is unchanged.
</Update>

<Update label="June 15, 2026" description="Mark a conversation as read">
  ### Added

  **Mark a conversation as read.** [`POST /v1/conversations/{conversationId}/mark-as-read`](/docs/mdx/api-reference/conversations/mark-conversation-as-read) clears a conversation's unread indicator without sending a message and returns the updated conversation.
</Update>

<Update label="June 8, 2026" description="Tasks endpoints">
  ### Added

  **Tasks API.** A new set of endpoints for managing tasks is now available.

  | Method   | Endpoint                                                                                               | Description                                                        |
  | -------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------ |
  | `GET`    | [`/v1/tasks`](/docs/mdx/api-reference/tasks/list-tasks)                                                     | List tasks with cursor-based pagination.                           |
  | `POST`   | [`/v1/tasks`](/docs/mdx/api-reference/tasks/create-a-task)                                                  | Create a task linked to a phone number, conversation, or activity. |
  | `GET`    | [`/v1/tasks/{taskId}`](/docs/mdx/api-reference/tasks/gets-a-task-by-id)                                     | Get a task by ID.                                                  |
  | `PUT`    | [`/v1/tasks/{taskId}`](/docs/mdx/api-reference/tasks/update-a-task)                                         | Update a task's title and description.                             |
  | `DELETE` | [`/v1/tasks/{taskId}`](/docs/mdx/api-reference/tasks/delete-a-task-by-id)                                   | Delete a task by ID.                                               |
  | `POST`   | [`/v1/tasks/{taskId}/complete`](/docs/mdx/api-reference/tasks/complete-a-task)                              | Mark a task as completed.                                          |
  | `POST`   | [`/v1/tasks/{taskId}/reopen`](/docs/mdx/api-reference/tasks/reopen-a-task)                                  | Reopen a completed task.                                           |
  | `POST`   | [`/v1/tasks/{taskId}/assign`](/docs/mdx/api-reference/tasks/assign-a-user-to-a-task)                        | Assign a user to a task.                                           |
  | `POST`   | [`/v1/tasks/{taskId}/unassign`](/docs/mdx/api-reference/tasks/unassign-a-user-from-a-task)                  | Remove a user from a task's assignees.                             |
  | `POST`   | [`/v1/tasks/{taskId}/change-due-date`](/docs/mdx/api-reference/tasks/change-a-tasks-due-date)               | Set a task's due date.                                             |
  | `POST`   | [`/v1/tasks/{taskId}/remove-due-date`](/docs/mdx/api-reference/tasks/remove-a-tasks-due-date)               | Clear a task's due date.                                           |
  | `POST`   | [`/v1/tasks/{taskId}/link-conversation`](/docs/mdx/api-reference/tasks/link-a-task-to-a-conversation)       | Link a task to a conversation.                                     |
  | `POST`   | [`/v1/tasks/{taskId}/unlink-conversation`](/docs/mdx/api-reference/tasks/unlink-a-task-from-a-conversation) | Unlink a conversation from a task.                                 |
</Update>

<Update label="May 26, 2026" description="Webhooks beta: call events">
  ### Added

  **Call lifecycle events.** Five call lifecycle events are now supported by the beta webhook API, completing event parity with the legacy webhook system:

  | Event type                                                                               | When it fires                                                                             |
  | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
  | [`call.ringing`](/docs/mdx/beta/webhooks-event-payloads#call-ringing)                         | A call started ringing (incoming or outgoing).                                            |
  | [`call.answered`](/docs/mdx/beta/webhooks-event-payloads#call-answered)                       | A call connected. Also fires when an outgoing call reaches voicemail.                     |
  | [`call.forwarded`](/docs/mdx/beta/webhooks-event-payloads#call-forwarded)                     | An incoming call was forwarded. Includes `forwardedFrom` and `forwardedTo` phone numbers. |
  | [`call.missed`](/docs/mdx/beta/webhooks-event-payloads#call-missed)                           | An incoming call ended without being answered.                                            |
  | [`call.voicemail.completed`](/docs/mdx/beta/webhooks-event-payloads#call-voicemail-completed) | A voicemail finished processing. Correlate with the source call via `resource.callId`.    |

  `call.answered`, `call.forwarded`, `call.missed`, and `call.voicemail.completed` are new event types with no equivalent in the legacy webhook system.

  The beta webhook API now covers the full event surface of the legacy system, plus `call.answered`, `call.forwarded`, `call.missed`, and `call.voicemail.completed` — four event types with no equivalent in legacy. See the [beta webhook overview](/docs/mdx/beta/webhooks-overview) and [event payload reference](/docs/mdx/beta/webhooks-event-payloads) for details.
</Update>

<Update label="May 11, 2026" description="Webhooks open beta">
  ### Added

  **Beta webhook API (open beta).** A new webhook API is available in open beta. See the [overview](/docs/mdx/beta/webhooks-overview) and [quickstart](/docs/mdx/beta/webhooks-quickstart) to get started.

  **Unified create endpoint.** `POST /webhooks` replaces the four legacy create endpoints (`/v1/webhooks/messages`, `/v1/webhooks/calls`, `/v1/webhooks/call-summaries`, `/v1/webhooks/call-transcripts`). Message, call, and contact event types can be combined in a single subscription. Up to 50 webhooks per workspace.

  **Supported event types at launch.**

  | Event type                                                                                 | When it fires                                     |
  | ------------------------------------------------------------------------------------------ | ------------------------------------------------- |
  | [`message.received`](/docs/mdx/beta/webhooks-event-payloads#message-received)                   | An inbound message was received.                  |
  | [`message.delivered`](/docs/mdx/beta/webhooks-event-payloads#message-delivered)                 | An outbound message was delivered.                |
  | [`call.completed`](/docs/mdx/beta/webhooks-event-payloads#call-completed)                       | A call ended. Includes final status and duration. |
  | [`call.recording.completed`](/docs/mdx/beta/webhooks-event-payloads#call-recording-completed)   | A call recording finished processing.             |
  | [`call.summary.completed`](/docs/mdx/beta/webhooks-event-payloads#call-summary-completed)       | An AI call summary finished generating.           |
  | [`call.transcript.completed`](/docs/mdx/beta/webhooks-event-payloads#call-transcript-completed) | A call transcript finished processing.            |
  | [`contact.updated`](/docs/mdx/beta/webhooks-event-payloads#contact-updated)                     | A contact was created or updated.                 |
  | [`contact.deleted`](/docs/mdx/beta/webhooks-event-payloads#contact-deleted)                     | A contact was deleted.                            |

  Call lifecycle events (`call.ringing`, `call.answered`, `call.forwarded`, `call.missed`, `call.voicemail.completed`) were not yet available at launch — they were added on May 26, 2026.

  **Payload envelope.** All events share a common `data.resource` / `data.context` / `data.links` structure. `data.resource` contains the primary business object; `data.context` contains routing metadata (phone number, conversation, participants, contact lookup). See [Webhook event payloads](/docs/mdx/beta/webhooks-event-payloads).

  **Payload versioning.** Each subscription pins a payload version at creation via the `x-quo-api-version` header. Existing subscriptions are unaffected by future version changes. See [Versioning policy](/docs/mdx/beta/webhooks-overview#versioning-policy) for the current version.

  **Signing.** Deliveries use Standard-Webhooks-compatible headers (`webhook-id`, `webhook-timestamp`, `webhook-signature`) and a `whsec_...` base64 secret, compatible with the Svix SDK. This scheme is not interchangeable with the legacy `OpenPhone-Signature` header — update signature verification before routing beta traffic to an existing endpoint. See [Validate webhook signatures](/docs/mdx/beta/webhooks-signature-validation).

  **Delivery inspection.** Send a signed test delivery (`POST /webhooks/:id/events/test`), browse delivery history and per-attempt responses (`GET /webhooks/:id/events`, `GET /webhooks/:id/events/:eventId`), and trigger manual retries (`POST /webhooks/:id/events/:eventId/retry`). See [Webhook API reference](/docs/mdx/beta/webhooks-api-reference).

  **Signing secret rotation.** `POST /webhooks/:id/rotate` issues a new `whsec_...` key for an existing subscription without changing its event subscriptions or `apiVersion`.

  For a side-by-side comparison with the legacy system and a no-downtime migration walkthrough, see [Migrating from legacy](/docs/mdx/beta/webhooks-differences-from-current).
</Update>

<Update label="January 22, 2025" description="1.2.0">
  ### Minor Changes

  * Adds a property `externalId` to the contact model. Adds `externalId` and `source` as optional parameters to the Create Contact (`POST /contacts`) request.
  * Adds `externalId` and `source` as optional parameters to the Update Contact (`PATCH /contacts/:id`) request.
  * Added a route to list contacts (`GET /contacts`).

  ### Patch Changes

  * Fixed an issue where creating or updating a contact with an invalid custom field would result in 500 error. Sending an invalid custom field will now result in a 400 "Invalid Custom Field Item" error.
</Update>

<Update label="December 6, 2024" description="1.1.2">
  ### Patch Changes

  * Fixed an issue where paginated endpoints would return a string token for the next page at the end of paginated results. Now, they will correctly return the next page token as `null`.
  * Added a callout that the `totalItems` result field for the paginated endpoints is not functioning as expected and is not returning the true total items count.
</Update>

<Update label="November 25, 2024" description="1.1.1">
  ### Patch Changes

  * Fixes an issue where phone numbers in various routes were expected to be in E164 format, but the format was not being validated correctly.
</Update>

<Update label="November 7, 2024" description="1.1.0">
  ## 1.1.0

  ### Minor Changes

  * Adds a property, `restrictions`, to the objects in the response from list phone numbers (`GET /phone-numbers`). The new property contains information about regional restrictions for outbound calling and messaging from a phone number.
</Update>

<Update label="November 4, 2024" description="1.0.2">
  ### Patch Changes

  * Fixed an issue with list calls (`GET /calls`) where sending an empty participants param resulted in a 500 response. Sending an empty participants param will now result in a descriptive 400 response.
  * Fixes an issue where attempting to send a message to an international number would result in a 500 response if international messaging is not enabled in the workspace. With this fix, the 500 error response changed to a 403 with a descriptive message
  * Fixes a bug where the GET call recordings endpoint sometimes returned an empty array.
  * Fixes an issue that was preventing some call records from returning successfully from `GET /calls`
  * Fixes an issue where getting a contact by id would result in a 500 instead of a 404 when contact is not found. Now this will respond in a 404 with a descriptive message.
  * Fixes an issue where sending a message that contained only whitespace (`' '`, `'\n'`, etc.) resulted in a 500 error response. Now, this will respond with 400 and a validation error message instead.
</Update>

<Update label="October 22, 2024" description="1.0.1">
  ### Patch Changes

  * Fixes an issue with List Calls (`GET /calls`) where the user ID applied by default when the user ID parameter was not sent was being set to the workspace owner instead of the phone number owner.
</Update>

<Update label="October 21, 2024" description="1.0.0">
  ## 1.0.0

  ### Major Changes

  OpenPhone's Public API v1 release 🚀

  Changes from the beta version include:

  * The `since` query parameter on "list calls" and "list messages" has been deprecated. It used to incorrectly behave as a `createdBefore`. Please use `createdAfter` instead, or `createdBefore` to maintain current functionality.
  * The `phoneNumberId` field for "send text message" has been deprecated. Please use `from` instead.
  * `/v0` endpoints have been deprecated. Please use `/v1` instead.
</Update>


# Get contact custom fields
Source: https://www.quo.com/docs/mdx/api-reference/contact-custom-fields/get-contact-custom-fields

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json get /v1/contact-custom-fields
Custom contact fields enhance your Quo contacts with additional information beyond standard details like name, company, role, emails and phone numbers. These user-defined fields let you capture business-specific data. While you can only create or modify these fields in Quo itself, this endpoint retrieves your existing custom properties. Use this information to accurately map and include important custom data when creating new contacts via the API.



# Create a contact
Source: https://www.quo.com/docs/mdx/api-reference/contacts/create-a-contact

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json post /v1/contacts
Create a contact for a workspace.



# Delete a contact
Source: https://www.quo.com/docs/mdx/api-reference/contacts/delete-a-contact

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json delete /v1/contacts/{id}
Delete a contact by its unique identifier.



# Get a contact by ID
Source: https://www.quo.com/docs/mdx/api-reference/contacts/get-a-contact-by-id

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json get /v1/contacts/{id}
Retrieve detailed information about a specific contact in your Quo workspace using the contact's unique identifier.



# List contacts
Source: https://www.quo.com/docs/mdx/api-reference/contacts/list-contacts

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json get /v1/contacts
Retrieve a paginated list of contacts. You can optionally filter the results by providing external IDs and sources. When no external IDs are provided, all contacts for the organization are returned.



# Update a contact by ID
Source: https://www.quo.com/docs/mdx/api-reference/contacts/update-a-contact-by-id

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json patch /v1/contacts/{id}
Modify an existing contact in your Quo workspace using the contact's unique identifier.



# List Conversations
Source: https://www.quo.com/docs/mdx/api-reference/conversations/list-conversations

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json get /v1/conversations
Fetch a paginated list of conversations of Quo conversations. Can be filtered by user and/or phone numbers. Defaults to all conversations in the Quo organization. Results are returned in descending order based on the most recent conversation.



# Mark conversation as done
Source: https://www.quo.com/docs/mdx/api-reference/conversations/mark-conversation-as-done

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json post /v1/conversations/{conversationId}/mark-as-done
Mark a conversation as done, removing it from the inbox without sending a message. Returns the updated conversation.



# Mark conversation as open
Source: https://www.quo.com/docs/mdx/api-reference/conversations/mark-conversation-as-open

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json post /v1/conversations/{conversationId}/mark-as-open
Mark a conversation as open, returning it to the inbox without sending a message. Returns the updated conversation.



# Mark conversation as read
Source: https://www.quo.com/docs/mdx/api-reference/conversations/mark-conversation-as-read

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json post /v1/conversations/{conversationId}/mark-as-read
Mark a conversation as read, clearing its unread indicator without sending a message. Returns the updated conversation.



# API response codes
Source: https://www.quo.com/docs/mdx/api-reference/error-codes

Quo uses standard HTTP response codes to indicate request status. 

## Response code categories

* 2xx: Success
* 4xx: Client-side errors
* 5xx: Server-side errors

<Info>
  Some 4xx errors include specific error codes for programmatic handling.
</Info>

## Common response codes

| Code  | Status               | Description                                                   |
| ----- | -------------------- | ------------------------------------------------------------- |
| `200` | OK                   | Request successful                                            |
| `201` | Created              | Resource successfully created                                 |
| `202` | Accepted             | Request accepted for processing                               |
| `204` | No Content           | Request successful, no content returned                       |
| `400` | Bad Request          | Invalid parameters                                            |
| `401` | Unauthorized         | Missing or invalid API key                                    |
| `403` | Forbidden            | Insufficient permissions or an account setting is not enabled |
| `404` | Not Found            | Resource doesn't exist                                        |
| `409` | Conflict             | Conflict with another request                                 |
| `422` | Unprocessable Entity | Request is well-formed but contains semantic errors           |
| `429` | Too Many Requests    | Rate limit exceeded                                           |
| `500` | Server Error         | Quo-side issue                                                |

<Tip>
  For 429 errors, implement exponential backoff in your requests.
</Tip>


# Introduction
Source: https://www.quo.com/docs/mdx/api-reference/introduction

Welcome to the Quo API!

## Overview

The Quo API enables developers to integrate powerful communication features directly into their applications and workflows. Built on REST principles, our API provides a reliable and secure way to programmatically manage phone communications.

## Key features

<CardGroup>
  <Card title="REST architecture" icon="code">
    Industry-standard REST API design with JSON responses for easy integration
  </Card>

  <Card title="Secure authentication" icon="lock">
    API key-based authentication to ensure secure access to your account
  </Card>

  <Card title="JSON responses" icon="brackets-curly">
    All API responses are returned in standardized JSON format
  </Card>

  <Card title="Developer tools" icon="screwdriver-wrench">
    Comprehensive documentation and [resources](/docs/mdx/guides) to accelerate development
  </Card>
</CardGroup>

## Next steps

Ready to dive deeper? Here are some helpful resources:

* [Authentication guide](/docs/mdx/api-reference/authentication) - Learn about securing your API requests

* [Send your first message](/docs/mdx/api-reference/send-your-first-message) - Quick start guide for messaging

* [Build with AI LLMs](/docs/mdx/guides/building-with-ai-llms) - Learn how to utilize this API alongside AI


# Get a message by ID
Source: https://www.quo.com/docs/mdx/api-reference/messages/get-a-message-by-id

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json get /v1/messages/{id}
Get a message by its unique identifier.



# List messages
Source: https://www.quo.com/docs/mdx/api-reference/messages/list-messages

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json get /v1/messages
Retrieve a chronological list of messages exchanged between your Quo number and specified participants, with support for filtering and pagination. 



# Send a text message
Source: https://www.quo.com/docs/mdx/api-reference/messages/send-a-text-message

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json post /v1/messages
Send a text message from your Quo number to a recipient.



# Partner directory
Source: https://www.quo.com/docs/mdx/api-reference/partner-directory

Connect with experts to achieve your customer communications goals.

Thinking about building with the Quo API but don’t have the time or in-house expertise to get started? Our trusted Quo Experts are here to help.

Browse our [directory of partners](https://www.openphone.com/experts) who offer tailored services to help you make the most of your Quo setup. Whether it's integrating with other tools, optimizing your workflows, or getting onboarded smoothly, we've got you covered.

<Tip>
  Not sure where to start? [Tell us about your project](https://www.openphone.com/experts/matchmaking), and we'll connect you with the right partner.
</Tip>


# Get a phone number by ID
Source: https://www.quo.com/docs/mdx/api-reference/phone-numbers/get-a-phone-number-by-id

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json get /v1/phone-numbers/{phoneNumberId}
Get a phone number by its unique identifier.



# List phone numbers
Source: https://www.quo.com/docs/mdx/api-reference/phone-numbers/list-phone-numbers

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json get /v1/phone-numbers
Retrieve the list of phone numbers and users associated with your Quo workspace.



# Rate limits
Source: https://www.quo.com/docs/mdx/api-reference/rate-limits

Quo implements rate limiting to ensure API stability and fair usage.

Each API key may make up to **10 requests per second.**

Exceeding this limit may result in `429` status code errors.

<Tip>
  Implement request throttling in your application to stay within rate limits and optimize API usage.
</Tip>


# Send your first message
Source: https://www.quo.com/docs/mdx/api-reference/send-your-first-message

This is a step-by-step guide for sending your first text message.

## Ping!

Let's get started sending text messages via the Quo API.

<Note> **Have you completed Carrier Registration?** If you plan to send text messages to US numbers via the API, you will also need to complete US Carrier Registration. Learn more [here](https://support.openphone.com/hc/en-us/articles/15519949741463-Guide-to-US-carrier-registration-for-OpenPhone-customers).</Note>

### 1. Get phone numbers (optional)

Make a call to the `GET Phone Numbers` endpoint to retrieve `userId` and `from` for the desired number (the phone number from which you'd like to send a text message). This step is optional if you already know the `userId` and `from` for the desired sending number.

```
curl --request GET \
  --url https://api.quo.com/v1/phone-numbers \
  --header 'Authorization: YOUR_API_KEY'
```

### 2. Specify user ID (optional)

If you'd like to send the text message as a particular Quo member in your workspace, make sure to include this `userId` in your request body. If `userId` is not specified, the sender will default to the phone number owner.

### 3. Send your message

You are now ready to send your first text message! Once you send your text message, you will receive a 202 Success Message via the API. Nice!

```
 curl --request POST \
  --url https://api.quo.com/v1/messages \
  --header 'Authorization: YOUR_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
  "content": "<string>",
  "from": "<string>",
  "to": [
    "+15555555555"
  ],
  "userId": "<string>"
}'
```

<Tip>Be sure to format phone numbers in E.164 format (+1234567890).</Tip>

### Summary

You are now able to send a text message to anyone in US or Canada. By using the API, you are able to programmatically send texts to your customers.


# Assign a user to a task
Source: https://www.quo.com/docs/mdx/api-reference/tasks/assign-a-user-to-a-task

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json post /v1/tasks/{taskId}/assign
Assigns the provided user to the list of assignees for the task



# Change a task's due date
Source: https://www.quo.com/docs/mdx/api-reference/tasks/change-a-tasks-due-date

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json post /v1/tasks/{taskId}/change-due-date
Sets the task's due date



# Complete a task
Source: https://www.quo.com/docs/mdx/api-reference/tasks/complete-a-task

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json post /v1/tasks/{taskId}/complete
Marks the provided task as completed



# Create a task
Source: https://www.quo.com/docs/mdx/api-reference/tasks/create-a-task

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json post /v1/tasks
Create a task linked to a phone number, conversation, or conversation activity. Provide exactly one of `phoneNumberId`, `conversationId`, or `activityId`.



# Delete a task by ID
Source: https://www.quo.com/docs/mdx/api-reference/tasks/delete-a-task-by-id

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json delete /v1/tasks/{taskId}
Deletes the task with the provided task ID



# Gets a task by ID
Source: https://www.quo.com/docs/mdx/api-reference/tasks/gets-a-task-by-id

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json get /v1/tasks/{taskId}
Retrieve a single task by its ID



# Link a task to a conversation
Source: https://www.quo.com/docs/mdx/api-reference/tasks/link-a-task-to-a-conversation

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json post /v1/tasks/{taskId}/link-conversation
Links the task with the provided task ID to a conversation



# List tasks
Source: https://www.quo.com/docs/mdx/api-reference/tasks/list-tasks

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json get /v1/tasks
Retrieve a list of tasks



# Remove a task's due date
Source: https://www.quo.com/docs/mdx/api-reference/tasks/remove-a-tasks-due-date

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json post /v1/tasks/{taskId}/remove-due-date
Clears the task's due date



# Reopen a task
Source: https://www.quo.com/docs/mdx/api-reference/tasks/reopen-a-task

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json post /v1/tasks/{taskId}/reopen
Reopens the provided task



# Unassign a user from a task
Source: https://www.quo.com/docs/mdx/api-reference/tasks/unassign-a-user-from-a-task

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json post /v1/tasks/{taskId}/unassign
Removes the provided user from the assignee list of a task



# Unlink a task from a conversation
Source: https://www.quo.com/docs/mdx/api-reference/tasks/unlink-a-task-from-a-conversation

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json post /v1/tasks/{taskId}/unlink-conversation
Unlinks the provided conversation from the task



# Update a task
Source: https://www.quo.com/docs/mdx/api-reference/tasks/update-a-task

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json put /v1/tasks/{taskId}
Updates the task's title and description



# Get a user by ID
Source: https://www.quo.com/docs/mdx/api-reference/users/get-a-user-by-id

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json get /v1/users/{userId}
Retrieve detailed information about a specific user in your Quo workspace using the user's unique identifier.



# List users
Source: https://www.quo.com/docs/mdx/api-reference/users/list-users

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json get /v1/users
Retrieve a paginated list of users in your Quo workspace.



# Create a new webhook for call summaries
Source: https://www.quo.com/docs/mdx/api-reference/webhooks/create-a-new-webhook-for-call-summaries

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json post /v1/webhooks/call-summaries
Creates a new webhook that triggers on events from call summaries.



# Create a new webhook for call transcripts
Source: https://www.quo.com/docs/mdx/api-reference/webhooks/create-a-new-webhook-for-call-transcripts

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json post /v1/webhooks/call-transcripts
Creates a new webhook that triggers on events from call transcripts.



# Create a new webhook for calls
Source: https://www.quo.com/docs/mdx/api-reference/webhooks/create-a-new-webhook-for-calls

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json post /v1/webhooks/calls
Creates a new webhook that triggers on events from calls.



# Create a new webhook for messages
Source: https://www.quo.com/docs/mdx/api-reference/webhooks/create-a-new-webhook-for-messages

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json post /v1/webhooks/messages
Creates a new webhook that triggers on events from messages.



# Delete a webhook by ID
Source: https://www.quo.com/docs/mdx/api-reference/webhooks/delete-a-webhook-by-id

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json delete /v1/webhooks/{id}
Delete a webhook by its unique identifier.



# Get a webhook by ID
Source: https://www.quo.com/docs/mdx/api-reference/webhooks/get-a-webhook-by-id

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json get /v1/webhooks/{id}
Get a webhook by its unique identifier.



# Lists all webhooks
Source: https://www.quo.com/docs/mdx/api-reference/webhooks/lists-all-webhooks

https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json get /v1/webhooks
List all webhooks for a user.



# Building with AI LLMs
Source: https://www.quo.com/docs/mdx/guides/building-with-ai-llms

Learn how to use AI Language Models to build applications with the Quo API.

## Introduction

Building with Large Language Models (LLMs) can significantly accelerate your Quo API integration development. This guide will help you effectively use LLMs to create applications with our API.

<Note>
  While we provide examples using Claude, the principles and practices outlined here apply to any capable LLM platform.
</Note>

## Getting started

### Documentation setup

Before beginning development with an LLM, gather and prepare the necessary documentation:

<Steps>
  <Step title="Download OpenAPI specification">
    Get our [OpenAPI specification](https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-v1-prod.json) for detailed endpoint information.

    **Tip**: Right-click and select "Save Link As..." to download the file
  </Step>

  <Step title="Get complete documentation">
    Download and extract our [complete documentation package](https://openphone-public-api-prod.s3.us-west-2.amazonaws.com/public/openphone-public-api-llm-ready-docs-prod.zip)
  </Step>

  <Step title="Share with your LLM">
    Provide these resources to your LLM to help it understand Quo API capabilities
  </Step>
</Steps>

## Development process

### Working with LLMs

<CardGroup>
  <Card title="Clear goals" icon="bullseye">
    Start by clearly describing your integration objectives to the LLM
  </Card>

  <Card title="Documentation" icon="book">
    Share relevant API documentation and specifications
  </Card>

  <Card title="Step breakdown" icon="list">
    Let the LLM help break complex features into manageable tasks
  </Card>

  <Card title="Iterative development" icon="rotate">
    Generate and review code one step at a time
  </Card>
</CardGroup>

### Best practices

<AccordionGroup>
  <Accordion title="Development approach">
    * Start with core functionality
    * Iterate to add features
    * Test each component thoroughly
    * Move forward only after validation
  </Accordion>

  <Accordion title="Security considerations">
    * Never share API keys with LLMs
    * Keep sensitive data out of prompts
    * Validate all generated code
    * Follow security best practices
  </Accordion>

  <Accordion title="Performance & limits">
    * Follow Quo API rate limits
    * Implement proper error handling
    * Monitor API usage
    * Optimize API calls
  </Accordion>
</AccordionGroup>

## Example interactions

Here's a practical example of how to instruct an LLM to help build with our API:

<AccordionGroup>
  <Accordion title="Sample project: message sender">
    ```text theme={null}
    I want to build an application that:
    1. Displays a list of all my phone numbers
    2. Allows me to select a number to send a message with
    3. Lets me input an external phone number to send a message to
    4. Sends a message to the external phone number

    Please help me implement this using the Quo API.
    ```
  </Accordion>

  <Accordion title="Contact management example">
    ```text theme={null}
    Help me create a system to:
    1. Sync contacts from my CRM
    2. Update contact details automatically
    3. Track message history per contact
    4. Generate contact activity reports
    ```
  </Accordion>
</AccordionGroup>

## Integration patterns

<CardGroup>
  <Card title="Message automation" icon="robot">
    Automate message handling and responses
  </Card>

  <Card title="Contact management" icon="address-book">
    Sync and manage contact information
  </Card>

  <Card title="Call analytics" icon="chart-line">
    Process call summaries and recording data
  </Card>

  <Card title="Scheduling" icon="calendar">
    Manage scheduling and reminders
  </Card>
</CardGroup>

## Implementation checklist

<Steps>
  <Step title="Code review">
    Thoroughly review all LLM-generated code
  </Step>

  <Step title="Testing">
    Test extensively in a development environment
  </Step>

  <Step title="Error handling">
    Implement comprehensive error handling and logging
  </Step>

  <Step title="Monitoring">
    Deploy with appropriate monitoring systems
  </Step>

  <Step title="Iteration">
    Continuously improve based on usage and feedback
  </Step>
</Steps>

<Info>
  Need more detailed guidance? Check out our comprehensive [API Reference](/docs/api-reference/introduction) for detailed endpoint documentation and examples.
</Info>


# External contacts
Source: https://www.quo.com/docs/mdx/guides/contacts

Learn about working with contacts imported via the Quo API or native integrations.

## Understanding external contacts

External contacts are contacts that originate from outside the Quo app: either created through the Quo API or synced via native integrations (such as CRM or other connected platforms). These contacts allow you to centralize contact records from multiple sources within your Quo workspace.

### Key characteristics

<CardGroup>
  <Card title="Distinct from app-created contacts">
    External contacts are separate from contacts created directly in the Quo app, with their own specific behaviors depending on how they were created.
  </Card>

  <Card title="Two sources, different behaviors">
    External contacts can come from two sources: the Quo API or native integrations and each has different editability rules within the Quo app.
  </Card>
</CardGroup>

### Editability by source

<CardGroup>
  <Card title="API-created contacts" icon="code">
    Contacts created via the Quo API can be updated directly within the Quo app. You can also continue managing them programmatically through API endpoints.
  </Card>

  <Card title="Native integration contacts" icon="plug">
    Contacts synced from native integrations remain read-only within Quo. Any changes must be made in the source system and synced back to Quo.
  </Card>
</CardGroup>

### Important behaviors and limitations

<CardGroup>
  <Card title="Preserving contact IDs">
    When you create a contact using the `POST /contacts` endpoint, it's essential to save the `id` returned in the response. This `id` will be required for all future API operations involving the contact.
  </Card>

  <Card title="Visibility in the Quo app">
    After creating an API contact, it will only appear in the Quo app—whether in the conversation list, contact list, or search results—if there's an associated conversation with a matching phone number.
  </Card>
</CardGroup>

## Contact field structure

Quo organizes contact information using two distinct field types. Understanding these is crucial for effective contact management.

<AccordionGroup>
  <Accordion title="Default fields">
    Every contact in Quo includes these predefined fields:

    * First Name
    * Last Name
    * Role
    * Company
    * Emails
    * Phone Numbers

    These fields maintain consistent properties across all contacts and form the foundation of contact information.
  </Accordion>

  <Accordion title="Custom fields">
    Custom fields allow for flexible, user-defined contact properties. Supported data types include:

    * Address
    * Boolean
    * Date
    * Multi-select
    * Number
    * String
    * URL

    <Note>
      **Managing Custom Fields:** Custom field definitions can only be modified within the Quo app. The API does not currently support creating or editing custom field definitions.
    </Note>
  </Accordion>
</AccordionGroup>

## Creating and managing contacts via API

Follow these steps to effectively create and manage contacts through the API:

<Steps>
  <Step title="Retrieve custom fields">
    First, call the `GET /contact-custom-fields` endpoint to retrieve your workspace's custom contact field definitions.
  </Step>

  <Step title="Prepare contact data">
    Structure your contact data according to both default and custom fields:

    ```json theme={null}
    {
      "defaultFields": {
        "firstName": "John",
        "lastName": "Doe",
        "phoneNumbers": [
          {
            "name": "primary",
            "value": "+1234567890"
          }
        ]
      },
      "customFields": {
        // Include any custom field values here
      }
    }
    ```
  </Step>

  <Step title="Create the contact">
    Use the `POST /contacts` endpoint to create the contact and store the returned contact ID for future operations.
  </Step>

  <Step title="Manage the contact">
    Update contacts either within the Quo app or programmatically using the `PATCH /contacts/:id` endpoint with the saved contact ID.
  </Step>
</Steps>

<Tip>
  Always validate phone numbers are in E.164 format (+1234567890) before creating or updating contacts to ensure proper functionality.
</Tip>


# Sync your contacts
Source: https://www.quo.com/docs/mdx/guides/sync-contacts

Implement a one-way contact sync from Google Sheets to Quo using Javascript.

## Overview

This guide provides a foundation for implementing a one-way sync from Google Sheets to Quo using JavaScript. You may need to adjust some details based on your specific requirements and environment. Remember to thoroughly test the implementation to ensure data integrity.

## Development guide

<AccordionGroup>
  <Accordion title="1. Setup and authentication">
    ##### 1.1 Quo API.

    * Obtain your Quo API key from the Quo dashboard.

    ##### 1.2 Google Sheets API

    * Enable the Google Sheets API in your Google Cloud Console.
    * Create service account credentials and download the JSON key file.

    ##### 1.3 Google Sheets

    * Create a Google Sheet in the following format:

      | contactId | firstName | lastName | phone          | email                                       |
      | --------- | --------- | -------- | -------------- | ------------------------------------------- |
      |           | Jane      | Doe      | (555) 555-5555 | [jane@example.com](mailto:jane@example.com) |

    * Share your Google Sheet with the service account email address.
  </Accordion>

  <Accordion title="2. Environment setup">
    ##### 2.1 Ensure you have Node.js installed on your system.

    ##### 2.2 Create a new Node.js project and initialize it

    ```bash theme={null}
    mkdir quo-sync
    cd quo-sync
    npm init -y
    ```

    ##### 2.3 Install required packages

    ```bash theme={null}
    npm install googleapis axios dotenv node-cron
    ```

    ##### 2.4 Create a .env file to store environment variables

    ```bash theme={null}
    QUO_API_KEY=your_quo_api_key
    GOOGLE_APPLICATION_CREDENTIALS=path/to/your/credentials.json
    GOOGLE_SHEET_ID=your_google_sheet_id
    ```
  </Accordion>

  <Accordion title="3. Implement the sync process">
    ##### 3.1 Create a new file named `sync.js` and add the setup functions

    ```js theme={null}
    require("dotenv").config();
    const { google } = require("googleapis");
    const axios = require("axios");
    const cron = require("node-cron");

    const API_BASE_URL = "https://api.quo.com/v1";

    const quo = axios.create({
      baseURL: API_BASE_URL,
      headers: {
        Authorization: process.env.QUO_API_KEY,
        "Content-Type": "application/json",
        },
    });

    const googleAuth = new google.auth.GoogleAuth({
      keyFile: process.env.GOOGLE_APPLICATION_CREDENTIALS,
      scopes: ["https://www.googleapis.com/auth/spreadsheets"],
    });
    ```

    ##### 3.2 Add the Quo API helper functions

    ```js theme={null}
    async function createQuoContact(contactData) {
      const response = await quo.post("/contacts", contactData);
      return response.data.data;
    }

    async function updateQuoContact(contactId, contactData) {
      const response = await quo.patch(`/contacts/${contactId}`, contactData);
      return response.data.data;
    }
    ```

    ##### 3.3 Add the Google Sheets to Quo contacts mapping function

    ```js theme={null}
    function mapFields(sheetRow) {
      if (!sheetRow.firstName) {
        console.warn("Missing required firstName in row: ", sheetRow);
        return;
      }
      return {
        defaultFields: {
          firstName: sheetRow.firstName,
          lastName: sheetRow.lastName,
          phoneNumbers: sheetRow.phone
            ? [{ name: "primary", value: sheetRow.phone }]
            : undefined,
          emails: sheetRow.email
            ? [{ name: "primary", value: sheetRow.email }]
            : undefined,
        },
      };
    }
    ```

    ##### 3.4 Add the Google Sheets helper functions

    ```js theme={null}
    async function getGoogleSheetsData() {
      const sheets = google.sheets({ version: "v4", googleAuth });

      const response = await sheets.spreadsheets.values.get({
        spreadsheetId: process.env.GOOGLE_SHEET_ID,
        range: "Sheet1!A1:Z", // First sheet and all initial columns
      });

      const rows = response.data.values;
      const headers = rows[0]; // First row contains headers
      return rows.slice(1).map((row) => { // Skip the first row and map the contact data
        const contact = {};
        headers.forEach((header, index) => {
          contact[header] = row[index];
        });
        return contact;
      });
    }

    async function updateSheetWithContactId(rowNumber, contactId) {
      const sheets = google.sheets({ version: "v4", googleAuth });

      await sheets.spreadsheets.values.update({
        spreadsheetId: process.env.GOOGLE_SHEET_ID,
        range: `Sheet1!A${rowNumber + 2}`, // +2 to account for 1-based index and header row
        valueInputOption: "RAW",
        resource: { values: [[contactId]] },
      });
    }
    ```

    ##### 3.4 Finally, tie it all together

    ```js theme={null}
    async function syncContacts() {
      const sheetContacts = await getGoogleSheetsData();

      for (const [rowNumber, sheetRow] of sheetContacts.entries()) {
        const mappedContact = mapFields(sheetRow);
        if (sheetRow.contactId) {
          await updateQuoContact(sheetRow.contactId, mappedContact);
        } else {
          const { id } = await createQuoContact(mappedContact);
          await updateSheetWithContactId(rowNumber, id);
        }
      }

      console.log("Sync completed successfully");
    }

    // Run sync every hour
    cron.schedule("0 * * * *", syncContacts);
    console.log("Sync process started. Running every hour.");
    ```
  </Accordion>

  <Accordion title="4. Running the sync process">
    ```bash theme={null}
    node sync.js
    ```

    This will start the sync process, which will run every hour.
  </Accordion>
</AccordionGroup>

## Considerations and Optimizations

* Implement deletion logic to remove contacts from Quo that are no longer present in the Google Sheet.
* Implement pagination for fetching Quo contacts if you have a large number of contacts.
* Implement more robust error handling and retry mechanisms.
* Implement logging for auditing and troubleshooting purposes.
* Consider using a database to store the state of the sync process and to track changes between syncs.
* Consider implementing rate-limiting and an incremental sync to reduce API calls and processing time.
* For production use, consider deploying this script to a cloud platform like Heroku or AWS Lambda for better reliability and scalability.


# Contact the team
Source: https://www.quo.com/docs/mdx/pricing-support/contact-the-team

Stuck? Need Help?

Drop us a line at [support+developers@quo.com](mailto:support+developers@quo.com).


# Tips for minimizing costs
Source: https://www.quo.com/docs/mdx/pricing-support/minimizing-costs

We’ve provided the below tips to help you minimize segment counts and save money.

<CardGroup>
  <Card title="Watch Your character count" icon="square-1">
    Standard Latin alphabet characters, numbers, and basic punctuation use 160 characters per segment.
  </Card>

  <Card title="Be cautious with special characters" icon="square-2">
    Some special characters (é, ñ, ß) reduce segment capacity to 70 characters.
  </Card>

  <Card title="Minimize emoji usage" icon="square-3">
    Most emojis count as two characters. Extensive use can quickly increase segment count.
  </Card>

  <Card title="Avoid line breaks" icon="square-4">
    Each line break counts as a character.
  </Card>

  <Card title="Use URL shorteners" icon="square-5">
    Long URLs can span multiple segments. Shortened links save space.
  </Card>

  <Card title="Leverage common abbreviations" icon="square-6">
    Use widely understood abbreviations to reduce character count.
  </Card>
</CardGroup>


# API Pricing overview
Source: https://www.quo.com/docs/mdx/pricing-support/pricing-overview

Welcome to Quo's simple and transparent API pricing structure.

## Our pricing philosophy

At Quo, we believe in transparent and fair pricing. Sometimes it can be hard to understand the true cost of something when it's buried in the fine print. We are committed to helping you clearly understand and manage your costs when using our platform.

## Core pricing model

Our pricing is based on message segments, making it easy to calculate costs:

<CardGroup>
  <Card title="Local (US and Canada) SMS" icon="location-pin">
    <p>\$0.01 per segment</p>
  </Card>

  <Card title="International SMS" icon="globe">
    <p>\$0.01 + country-specific rate per segment</p>
    <p>Rates vary by destination country</p>
  </Card>
</CardGroup>

<Info>
  For detailed international rates by country, see our [International Pricing Guide](https://www.openphone.com/rates).
</Info>

## Understanding message segments

A **segment** is the basic unit we use to calculate SMS billing. Every message you send is divided into one or more segments based on two factors:

1. **Message length** (character count)
2. **Character type** (standard or special characters)

## How character types affect segment size

### Standard GSM characters

Messages using only standard GSM-7 characters fit **up to 160 characters per segment**.

Standard characters include:

* Letters (A-Z, a-z)
* Numbers (0-9)
* Spaces
* Basic punctuation (. , ! ? - etc.)

### Special/Non-GSM characters

<Info>
  **If your message contains even one special character, the entire message is billed at the 70-character limit** — not just the portion with special characters. This often results in more segments and higher costs than you might expect.
</Info>

Messages containing **any** special characters fit only **up to 70 characters per segment**.

Special characters include:

* Accented letters (é, ñ, ü)
* Curly/smart quotes (" " ' ')
* Emojis (😊, 🚀, ✨)
* Many international characters

## Tools and optimization

### Segment calculator

Use our [Segment Calculator](https://twiliodeved.github.io/message-segment-calculator/) tool to estimate costs before sending messages. This helps you optimize your message length and content to avoid unexpected charges.

### Smart encoding

The Quo API automatically enables **smart encoding** to minimize segment usage and reduce costs wherever possible. This feature works behind the scenes to choose the most efficient encoding for your messages.

## API message types

You're only charged for outgoing API-powered messages, which include:

<CardGroup>
  <Card title="Direct API Usage" icon="code">
    Messages sent through direct API calls
  </Card>

  <Card title="Integration Messages" icon="puzzle-piece">
    Messages sent via applications built with our API
  </Card>
</CardGroup>

## How our billing works

We use a credit-based system for all API messaging charges:

<Steps>
  <Step title="Purchase credits">
    Add funds to your account through the "Plans & Billing" tab
  </Step>

  <Step title="Automatic deduction">
    Credits are automatically deducted when messages are sent
  </Step>

  <Step title="Credit management">
    Monitor your balance and enable auto-recharge to prevent service interruptions
  </Step>
</Steps>

## Important service notes

### Requirements & limitations

1. An active Quo subscription is required for API access.
2. MMS is not supported in the current API version.
3. Partial credits cannot be used for sending messages; the API will return an error.

<Warning>
  If your credit balance is insufficient for a message's full cost, the API will return an error and the message won't be sent.
</Warning>

### Support & assistance

<Info>
  Need help understanding our pricing or managing your costs? Our team is here to help. Email us at [support+developers@quo.com](mailto:support+developers@quo.com) with any questions.
</Info>


# Terms of Service
Source: https://www.quo.com/docs/mdx/pricing-support/terms-of-service

Developer API Terms of Service

Please read these Developer API Terms of Service (the “Agreement”) carefully before using the API and Service (each as defined below) offered by OpenPhone Technologies, Inc. (“OpenPhone”). By clicking on the “Accept” or “Submit” button, you or the entity or company that you represent (“You,” “Your,” “Yours” or “Developer”) are unconditionally consenting to be bound by and are becoming a party to this Agreement. Your use of any portion of the API or Service, as well as your submission of any registration form or similar document that references this Agreement shall also constitute assent to this Agreement. If you do not unconditionally agree to all of the terms of this Agreement, click the “Decline” button and you shall have no right to use the API or Service. If you are entering into this Agreement on behalf of an entity, then you represent and warrant that you are authorized to bind such entity to the terms of this Agreement. If the terms of this Agreement are considered an offer, acceptance is expressly limited to such terms.

WHEREAS, OpenPhone owns and operates a business phone, texting, and collaborative workspace system and application (the “Service”);

WHEREAS, Developer desires to acquire from OpenPhone, and OpenPhone desires to provide to Developer, the right and license to access and use certain technologies and develop integrations to the Services as more fully described herein;

NOW THEREFORE, the parties hereto, in consideration of the foregoing and other good and valuable consideration recognized by the parties, hereby agree as follows:

​

1. Definitions
   The following terms shall have the following meanings for the purpose of this Agreement:

1.1 “Acceptable Use Policy” means OpenPhone’s acceptable use policy for Developers creating Integrations, available at [https://www.openphone.com/terms](https://www.openphone.com/terms), which may be updated by OpenPhone from time to time.

1.2 “API” means OpenPhone’s application programming interfaces and specifications thereto, as it is provided by OpenPhone to Developer, to enable Developer and End Users to interface with the Service.

1.3 “Documentation” means documentation and information regarding the API and Service that are delivered by OpenPhone to Developer in any form (including the documentation set forth at [https://www.openphone.com/docs](https://www.openphone.com/docs), including any updates to such documentation provided by OpenPhone from time to time.

1.4 “End User” means a user that accesses the API or the Service through the Integration for such user’s own benefit.

1.5 “End User Content” means any information, data, text, content or other materials that Developer or End Users upload, submit, transmit, display, post, store, or otherwise make available through the Service, including through the API or the Integration.

1.6 “Integration” means a software application or process that utilizes the API to make the Services compatible and/or interoperable with another software application or platform.

1.7 “OpenPhone Data” means any information, data, text or other content provided by or on behalf of OpenPhone to Developer about an individual End User.

1.8 “OpenPhone Terms of Service” means OpenPhone’s standard terms of service, available at [https://www.openphone.com/terms](https://www.openphone.com/terms), which may be updated by OpenPhone from time to time.

​
2\. API, Service and OpenPhone Data License; Restrictions
2.1 License. Subject to the terms and conditions of this Agreement, OpenPhone hereby grants Developer a non-exclusive, non-transferable, non-sublicensable, revocable, and limited right and license during the Term to access and use the Service, API and OpenPhone Data (a) to build one or more Integrations that connect to the Service, and (b) to permit End Users who have agreed to the OpenPhone Terms of Service to access the Service via such Integrations, in each case, in accordance with the Documentation, Acceptable Use Policy, and the OpenPhone Terms of Service. For the avoidance of doubt, Developer may not make any Integration or provide access to the Service to any End User or any other person or entity who has not agreed to the OpenPhone Terms of Service.

2.2 Registration; Monetization. Prior to accessing the API or developing an Integration, Developer shall complete OpenPhone’s standard registration process and provide all requested information, including, without limitation, (i) contact information for Developer, (ii) the purpose, features, and functionality of the Integration, and (iii) whether Developer intends to charge End Users for or otherwise monetize the Integration. Developer may not charge End Users for access to the Services via the Integration or otherwise monetize the Integration without OpenPhone’s prior written approval.

2.3 Responsibilities. Developer is solely responsible for the acts or omissions of Developer and each End User in connection with their use of the API and Service in connection with the Integration. Developer’s agreements with End Users must: (i) be no less protective of OpenPhone’s rights and ownership than this Agreement and the OpenPhone Terms of Service; (ii) not grant greater use or access rights to the Service or API than those rights, licenses and permissions described in OpenPhone Terms of Service; (iii) include substantially and materially similar restrictions to those set forth in Section 2.5 with respect to the Service and API to the extent applicable; and (iv) require, as a condition of accessing the Services via the Integration, that End Users have agreed to the OpenPhone Terms of Service. Developer shall prohibit unauthorized access to or use of the API and to promptly notify OpenPhone of any such unauthorized access or use. Developer accepts and assumes all responsibility for complying with all applicable laws and regulations in connection with all of Developer’s and End Users’ activities involving the API, the Service, End User Content and OpenPhone Data.

2.4 Updates and Modifications. Developer understands and agrees that the specifications for the API and the Service shall be defined by OpenPhone in its sole discretion, and Developer is responsible for its development and other costs associated with Developer’s use of the API or Integration. OpenPhone reserves the right to modify, change, update and/or enhance the API and/or the Service (each a “Modification”) at any time in OpenPhone’s sole and exclusive discretion. Developer acknowledges and agrees that such Modifications may affect Developer’s and End Users’ ability to access the Service and may require Developer to make changes to the Integration. OpenPhone shall not be liable for any costs incurred by Developer arising out of or in connection with any Modification.

2.5 License Restrictions.

2.5.1 Except as expressly permitted hereunder, Developer shall not, and shall require that End Users do not (i) use any method to access or use the Service other than as permitted through the API, (ii) provide the API or access to the Service to any third parties other than End Users, (iii) permit or enable third parties to copy or obtain the API or access to the Service in any manner not expressly authorized in this Agreement, (iv) use the API or Service, in any manner that violates applicable laws, (v) license, sell, re-sell, rent, lease, transfer, assign, reproduce, distribute, or alter the API, Service or any portion of the API or Service, or permit or enable any third parties to do so; (vi) use the Service, the API, or any documentation or other materials received from OpenPhone in connection with this Agreement, to develop a product or service that competes with the Service; (vii) modify, translate, adapt, merge, make derivative works of, disassemble, decompile, reverse compile or reverse engineer, or otherwise attempt to discover the source code or underlying algorithms of any part of the Service or API except to the extent the foregoing restrictions are expressly prohibited by applicable law; (viii) remove or destroy any copyright notices or other proprietary markings contained on or in the Service or API; (ix) access or use the API or Service in any manner that could disable, overburden, damage, disrupt or impair the API or Service or interfere with any other party’s access to or use of the API or Service or use any device, software or routine that causes the same; (x) attempt to gain unauthorized access to, interfere with, damage or disrupt the API or Service, accounts registered to other users, or the computer systems or networks connected to the API or Service; (xi) circumvent, remove, alter, deactivate, degrade or thwart any technological measure or content protections of the API or Service; (xii) use any robot, spider, crawlers, scraper, or other automatic device, process, software or queries that intercepts, “mines,” scrapes, extracts, or otherwise accesses the API or Service to monitor, extract, copy or collect information or data from or through the API or Service; or (xiii) introduce any viruses, trojan horses, worms, logic bombs or other materials that are malicious or technologically harmful into OpenPhone’s systems.

2.6 Public Announcement. The timing and content of any advertisements, announcements, press releases or other promotional activity relating to this Agreement, and the use of one party’s name or trademarks by the other party shall be subject to the prior approval of both parties. Notwithstanding the foregoing, OpenPhone may reference Developer as a Developer in advertisements, press releases, or other marketing or promotional activities regarding OpenPhone’s products or services.

​
3\. Ownership; Licenses; Third-Party Materials
3.1 OpenPhone Ownership. As between OpenPhone and Developer, OpenPhone retains all rights, title and interest in and to all intellectual property rights embodied in or pertaining to the API, Service, OpenPhone Data, and OpenPhone Marks (as defined in Section 3.3), and all improvements, modifications, enhancements, and derivative works of any of the foregoing. There are no implied licenses under this Agreement, and any rights not expressly granted to Developer hereunder are reserved by OpenPhone or its licensors. Developer shall not take any action inconsistent with OpenPhone’s ownership of the API, Service, OpenPhone Data, or OpenPhone Marks.

3.2 Integration; End User Content. As between OpenPhone and Developer, to the extent permitted by applicable law, Developer retains ownership of the Integration, subject to the license granted to OpenPhone in the following sentence. Developer grants OpenPhone a perpetual, non-exclusive, sublicensable (through multiple tiers of sublicensees) royalty-free, fully paid right and license to use, copy, host, store, transfer, display, perform, reproduce, modify for the purpose of formatting for display, and distribute the Integration and End User Content, in whole or in part, in any and all media or distribution methods (now known or later developed) for the purposes of operating and providing the Service to Developer and End Users, and any for any other lawful business purpose, including to improve the usability, functionality, and accuracy of the Service.

3.3 Trademark License. Developer will prominently include the words \[“Powered by OpenPhone”] wherever it makes the Service available to End Users (including in the end-user facing interface of the Integration) and in all marketing and promotional materials that reference the functionality provided by the Service or Integration. OpenPhone hereby grants Developer a limited, non-exclusive, non-transferable, non-sublicensable, royalty-free license to use OpenPhone’s trademarks, service marks, and logos (collectively “OpenPhone Marks”) during the Term on Developer’s websites or promotional materials solely to (i) attribute OpenPhone as the provider of the Service and (ii) otherwise advertise and promote the availability of access to the Service in the Integration. Developer agrees to use the OpenPhone Marks only in a form identified by OpenPhone in writing for use hereunder and such quality standards as may be reasonably established by OpenPhone and communicated to Developer from time to time in writing. Developer shall obtain OpenPhone’s prior written approval of any material change in the style and manner in which any of the OpenPhone Marks are proposed to be used. Developer shall not use the OpenPhone Marks in a manner that disparages OpenPhone or its products or services, portrays OpenPhone in a false, competitively adverse or poor light, or dilutes the OpenPhone Marks. Except as expressly provided for in this Section 3.3, OpenPhone reserves all right, title, and interest in and to the OpenPhone Marks. All goodwill arising from Developer’s use of the OpenPhone Marks shall inure to the benefit of OpenPhone. Developer hereby grants OpenPhone a limited, non-exclusive, non-transferable, non-sublicensable, royalty-free license to use Developer’s trademarks, service marks, and logos (collectively “Developer Marks”) on OpenPhone’s websites or promotional materials solely to advertise and promote the availability of access to the Service in the Integration and in accordance with Section 2.6. OpenPhone shall obtain Developer’s prior written approval of any material change in the style and manner in which any of the Developer Marks are proposed to be used. Developer shall not use the Developer Marks in a manner that disparages Developer or its products or services, portrays Developer in a false, competitively adverse or poor light, or dilutes the Developer Marks. Developer reserves all right, title, and interest in and to the Developer Marks. All goodwill arising from OpenPhone’s use of the Developer Marks shall inure to the benefit of Developer.

3.4 Feedback. Developer agrees that submission of any ideas, suggestions, documents, proposals or other feedback provided to OpenPhone (“Feedback”) is at Developer’s own risk and that OpenPhone has no obligations (including obligations of confidentiality) with respect to such Feedback. Developer represents and warrants that it has all rights necessary to submit the Feedback. Developer hereby grants to OpenPhone a fully paid, royalty-free, perpetual, irrevocable, worldwide, non-exclusive, transferrable, and fully sublicensable right and license to use, reproduce, perform, display, distribute, adapt, modify, re-format, create derivative works of, and otherwise exploit in any manner, any and all Feedback without restriction of compensation.

3.5 Content and Data.

3.5.1 End User Content. Developer represents and warrants that (i) before any End User may engage with the Integration or Service, Developer shall ensure that it provides all notices and obtains all consents required under applicable law to enable OpenPhone to process End User Content in accordance with OpenPhone’s privacy policy (currently available at [https://www.openphone.com/privacy](https://www.openphone.com/privacy)); (ii) it has sufficient rights, consents, and permissions to grant the licenses to OpenPhone set forth in Section 3.2 and to input the End User Content into the Service and (iii) the End User Content does not infringe, misappropriate, or otherwise violate any third party’s intellectual property rights, privacy rights, rights of publicity, moral rights, or other proprietary rights. Developer shall not (i) make representations or other statements with respect to End User Content that are contrary to or otherwise inconsistent with OpenPhone’s privacy policy or (ii) interfere with any independent efforts by OpenPhone to provide End User notice or obtain End User consent.

3.5.2 OpenPhone Data. OpenPhone Data shall only be used for the purpose of making the Service available to End Users in accordance with the OpenPhone Terms of Service and Developer shall delete all OpenPhone Data in accordance with the Documentation. Developer shall be responsible for obtaining consent directly from End Users for any other use of the End User’s information or data. To the extent that End User submits any information or data directly to Developer, Developer shall be solely responsible for ensuring that Developer’s use of that data is in compliance with any applicable laws and Developer’s own stated privacy policy.

3.5.3 DMCA. OpenPhone complies with the Digital Millennium Copyright Act (the “DMCA”) with regard to End User Content and all other content uploaded, submitted, transmitted, displayed, posted, stored, or otherwise made available on the Service that allegedly violates a third party’s copyright. OpenPhone reserves the right to delete or disable any content alleged to be infringing, and to terminate access to the Services for repeat alleged infringers. OpenPhone’s complete Copyright Dispute Policy is available at \[insert link].

3.6 Third Party Services. Developer acknowledges and agrees that: (i) the Service may incorporate certain information, data, and materials from third party providers (collectively, “Third Party Services”), including without limitation through integrations or connectors to such Third Party Services that are provided by OpenPhone; (ii) Third Party Services may only be used in conjunction with the Service; and (iii) Developer’s use of the Third Party Services hereunder shall be subject to (and Developer agrees it is bound by) the third party terms and conditions referenced at Third Party Terms [https://www.openphone.com/terms](https://www.openphone.com/terms) (the “Third Party Terms Site”), as they may be modified from time to time by OpenPhone and/or its third party licensors or suppliers at any time in accordance with this Section 3.6 (collectively, the “Third Party Terms”), and which are incorporated into this Agreement by reference. In the event that OpenPhone makes any update to the Third Party Terms, OpenPhone shall use reasonable efforts to notify Developer of such update (email to suffice) at least 2 weeks in advance, which notice shall describe the applicable update, as well as the effective date of such update (which shall be at least 2 weeks after the date of such notice). Provided that OpenPhone has followed the foregoing procedure, any use by Developer of the Service following the effective date of an update to the Third Party Terms shall constitute acceptance of such update. OpenPhone does not make any representations or warranties with respect to Third Party Services or any third party providers. OpenPhone cannot and does not guarantee that the Service shall incorporate (or continue to incorporate) any particular Third Party Services.

​
4\. Term and Termination
4.1 Term. This Agreement shall commence upon Developer’s first use of the API and/or Service and shall continue until terminated in accordance herewith.

4.2 Termination. OpenPhone may terminate this Agreement at any time for any reason or no reason at all upon ten (10) days’ written notice. Developer may terminate this Agreement at any time for any reason or no reason at all upon thirty (30) days’ written notice. Either party may terminate this Agreement immediately upon written notice to the other party (a) if the other party breaches any warranty, representation, covenant or obligation under this Agreement (or, in the case of Developer, the OpenPhone Terms of Service) and, if such breach is curable, fails to cure such breach within ten (10) days after receiving written notice of the breach from the non-breaching party; or (b) if the other party is subject to a dissolution, receivership, liquidation, insolvency, conservatorship, consolidation, reorganization, sale of substantially all of its assets, cessation of business, voluntary or involuntary bankruptcy. OpenPhone immediately may suspend Developer’s or any End User’s access to the API or Service or terminate this Agreement (i) if Developer monetizes the Integration without OpenPhone’s prior approval, (ii) if required to do so by law, or (iii) if OpenPhone determines such action is necessary to prevent a security risk or other creditable risk of harm or liability to OpenPhone, the Service, the API, or any third parties.

4.3 Effect of Termination; Survival\*\*.\*\* The provisions of Sections 1, 2.5, 3, 4.3, 5, 6.2, 7, 8 and 9 shall survive any expiration or termination of this Agreement. All other rights and obligations of the parties shall cease upon expiration or termination of this Agreement, and Developer shall cease use of the API, Service and OpenPhone Data as of the effective date of termination.

​
5\. Confidential Information
5.1 Confidential Information. Each party and their respective affiliates, directors, officers, employees, authorized representatives, agents and advisors (including attorneys, accountants, consultants, bankers and financial advisors) shall keep confidential all proprietary information concerning the other party’s business procedures, present and future products, services, operations, marketing materials, fees, technology, policies or plans of the other party that is received or obtained during the negotiation or performance of the Agreement, whether such information is oral or written, and whether or not labeled as confidential by such party (collectively “Confidential Information”).

5.2 Use of Confidential Information. For as long as Confidential Information of the disclosing party is in possession of the receiving party, the receiving party shall take reasonable steps, at least substantially equivalent to the steps it takes to protect its own proprietary information, to prevent the use, duplication or disclosure of Confidential Information other than in accordance with this Agreement. Each party may disclose Confidential Information of the other party to its employees or agents who are directly involved in negotiating or performing this Agreement and who are apprised of their obligations under this Section and directed by the receiving party to treat such information confidentially, or as required by law or by a supervising regulatory agency of a receiving party. Neither party shall disclose, share, rent, sell or transfer to any third party any Confidential Information of the other party except as expressly permitted by this Agreement. The receiving party shall use Confidential Information of the other party only as necessary to perform this Agreement.

5.3 Exceptions. Notwithstanding anything to the contrary, the obligations of the receiving party set forth in this Section 5 shall not apply to any information of the disclosing party that: (a) is or becomes a part of the public domain through no wrongful act of the receiving party; (b) was in the receiving party’s possession free of any obligation of confidentiality at the time of the disclosing party’s communication thereof to the receiving party; (c) is developed by the receiving party completely independent from the Confidential Information of the disclosing party; or (d) is required by law or regulation to be disclosed, but only to the extent and for the purpose of such required disclosure after providing the disclosing party with advance written notice if reasonably possible such that the disclosing party is afforded an opportunity to contest the disclosure or seek an appropriate protective order.

5.4 Remedies. Upon the request of the disclosing party following the termination of this Agreement, the other party shall promptly return all Confidential Information of the disclosing party in its possession, and shall promptly destroy such materials containing such information (and any copies, extracts, and summaries thereof) and shall further provide the other party with written confirmation of such return or destruction upon written request. In the event a party discovers that Confidential Information of the other party has been used in an unauthorized manner or disclosed in violation of this Section 5, the party discovering the unauthorized use or disclosure shall promptly notify the other party of such event. In addition, the non-disclosing party shall be entitled to all other remedies available at law or equity, including injunctive relief.

​
6\. Limited Representations and Warranties
6.1 General. Each party represents and warrants that (i) it is a duly incorporated or organized entity in its state of incorporation or organization and that it has the full power and authority to enter into and perform its obligations under this Agreement; (ii) the execution and performance by it of its obligations under this Agreement do not constitute a breach of or conflict with any other agreement or arrangement by which it is bound; (iii) this Agreement is a legal, valid and binding obligation of the party executing this Agreement; (iv) no consent or approval of any other party is required in connection with the execution, delivery, performance, or enforceability of this Agreement; and (v) it shall comply with all applicable laws, rules, and regulations in connection with performance of such party’s obligations under this Agreement.

6.2 Warranty Disclaimer. EXCEPT FOR THE REPRESENTATIONS AND WARRANTIES EXPRESSLY SET FORTH IN THIS SECTION 6, THE API, SERVICE, AND OPENPHONE DATA ARE EACH PROVIDED “AS IS” AND OPENPHONE AND ITS LICENSORS EXPRESSLY DISCLAIM ALL WARRANTIES AND CONDITIONS, EXPRESS, IMPLIED OR STATUTORY, INCLUDING THE IMPLIED WARRANTIES FOR TITLE, NON-INFRINGEMENT, MERCHANTABILITY, QUIET ENJOYMENT, FITNESS FOR A PARTICULAR PURPOSE, AND ANY WARRANTIES ARISING OUT OF COURSE OF DEALING OR TRADE USAGE. OPENPHONE DOES NOT REPRESENT OR WARRANT THAT (I) THE API, OR THE SERVICE SHALL MEET DEVELOPER’S REQUIREMENTS (SUCH AS THE QUALITY, EFFECTIVENESS, REPUTATION AND OTHER CHARACTERISTICS OF THE API AND SERVICE); (II) DEVELOPER’S OR ITS USERS’ USE OF THE API AND SERVICE SHALL BE UNINTERRUPTED, TIMELY, SECURE OR ERROR-FREE; OR (III) THE ADVICE, RESULTS, OR INFORMATION, WHETHER ORAL OR WRITTEN, OBTAINED FROM USE OF THE SERVICE OR API SHALL BE ACCURATE OR RELIABLE. DEVELOPER ACKNOWLEDGES THAT THE SERVICE MAY INCLUDE THIRD PARTY SERVICES AND THAT OPENPHONE IS NOT LIABLE, AND DEVELOPER AGREES NOT TO SEEK TO HOLD OPENPHONE LIABLE, FOR ANY THIRD PARTY SERVICES, AND THAT THE RISK OF INJURY FROM SUCH THIRD PARTY SERVICES RESTS ENTIRELY WITH DEVELOPER.

​
7\. Indemnification
Developer agrees to indemnify, defend and hold harmless OpenPhone, and parents, subsidiaries, affiliates, officers, employees, agents, partners, suppliers, and licensors, from and against any and all third-party losses, costs, liabilities, and claims (including reasonable attorneys’ fees) relating to or arising out of (a) Developer’s use or misuse of the API, Service, OpenPhone Data or intentional misconduct; (b) Developer’s violation of this Agreement; (c) Developer’s violation of any applicable law, rule or regulation; and (d) Developer’s violation of any other party’s right, including without limitation any right of privacy or intellectual property rights. Developer may not enter into any settlement or compromise of any such claim without prior written consent of OpenPhone. OpenPhone reserves the right, at its own cost, to assume the exclusive defense and control of any matter otherwise subject to indemnification by Developer, in which event Developer shall fully cooperate with OpenPhone in asserting any available defenses.

​
8\. Limitation of Liability
TO THE FULLEST EXTENT PROVIDED BY LAW, IN NO EVENT SHALL OPENPHONE BE LIABLE FOR ANY LOSS OF PROFITS, REVENUE OR DATA, INDIRECT, INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES, OR DAMAGES OR COSTS DUE TO BUSINESS INTERRUPTION, IN EACH CASE WHETHER OR NOT OPENPHONE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, ARISING OUT OF OR IN CONNECTION WITH THIS AGREEMENT, THE SERVICE, THE API, OPENPHONE DATA OR ANY COMMUNICATIONS, INTERACTIONS OR MEETINGS WITH OTHER USERS OF THE SERVICE OR THIRD PARTIES, ON ANY THEORY OF LIABILITY, INCLUDING TO THE EXTENT RESULTING FROM: (I) THE USE OR INABILITY TO USE THE SERVICE OR API; (II) ANY OTHER MATTER RELATED TO THE SERVICE OR API OR OPENPHONE DATA, WHETHER BASED ON WARRANTY, COPYRIGHT, CONTRACT, TORT (INCLUDING NEGLIGENCE), PRODUCT LIABILITY OR ANY OTHER LEGAL THEORY, OR (III) FOR ANY AMOUNT EXCEEDING THE GREATER OF (X) THE AMOUNT OF FEES PAID TO OPENPHONE DURING THE TWELVE MONTHS IMMEDIATELY PRECEDING THE CLAIM OR (Y) \$100 (ONE HUNDRED DOLLARS). NOTWITHSTANDING THE FOREGOING, THE LIMITATIONS SET FORTH IN THIS SECTION 8 SHALL NOT LIMIT A PARTY’S LIABILITY UNDER SECTION 5 (CONFIDENTIALITY) OR SECTION 7 (INDEMNIFICATION). OPENPHONE ASSUMES NO RESPONSIBILITY FOR THE TIMELINESS, DELETION, MIS-DELIVERY OR FAILURE TO STORE ANY END USER CONTENT.

​
9\. Miscellaneous
9.1 Assignment. Developer may not assign this Agreement without the prior written consent of OpenPhone. Subject to the foregoing limitation, this Agreement is binding upon and inures to the benefit of the successors and assigns of the respective parties hereto.

9.2 Independent Contractors. The relationship of the parties hereto is that of independent contractors. The parties hereto are not deemed to be agents, partners or joint ventures of the others for any purpose as a result of this Agreement or the transactions contemplated thereby. Nothing herein shall be deemed or construed as granting to either party or any right or authority to assume or to create any obligation or responsibility, express or implied, for, on behalf of, or in the name of the other party. All financial and other obligations associated with each party’s business are the sole responsibility of such party.

9.3 Third Party Beneficiaries. This Agreement is not intended and shall not be construed to create any rights or benefits upon any person not a party to this Agreement.

9.4 Force Majeure. Neither party shall be liable to the other in any way whatsoever for any failure or delay in performance of any of the obligations under this Agreement (other than obligations to make payment), arising out of any event or circumstance beyond the reasonable control of such party (including war, rebellion, civil commotion, terror, strikes, lock-outs or industrial disputes; fire, explosion, earthquake, acts of God, flood, drought or bad weather; acts of terror; epidemics, pandemics, or quarantine restrictions; or order by any government department, council or other constituted body).

9.5 Costs and Expenses. Unless specifically provided for elsewhere in this Agreement, each party shall bear its own costs and expenses, including legal fees, accounting fees and taxes incurred in connection with the negotiation and performance of this Agreement.

9.6 Compliance with Law. Developer shall at all times comply with all applicable international, federal, state and local laws and shall not engage in any illegal or unethical practices. Without limiting any of the foregoing, Developer agrees that it shall not permit the use of the Service or API or OpenPhone Data, export, or re-export the Service or API or OpenPhone Data, (a) into, or to or for the benefit of a national or resident of, any country to which the United States has embargoed goods, or (b) to anyone on the United States Treasury Department’s list of Specially Designated Nationals or the U.S. Commerce Department’s Table of Denial Orders, or license or otherwise permit use of the Service or API or OpenPhone Data for any activities involving nuclear materials or weapons, missile or rocket technologies, proliferation of chemical or biological weapons, or any other purpose prohibited by applicable law or in any jurisdiction where the Service is prohibited.

9.7 Notices. Except as otherwise provided, all notices under this Agreement shall be delivered by email, or physical mail to the other party at the address or number set forth in this Agreement. Notices to OpenPhone sent by physical mail shall also be sent via email to [support+developers@openphone.com](mailto:support+developers@openphone.com). Notices shall be deemed to have been given (i) at the time of delivery when delivered by email, (ii) at the time of delivery when delivered personally, or (iii) three (3) business days after having been sent by physical mail.

9.8 Entire Agreement; Modification. This Agreement, including any exhibits or other documents attached hereto or referenced herein, each of which is hereby incorporated into this Agreement and made an integral part hereof, constitutes the entire agreement between the parties relating to the subject matter hereof and there are no representations, warranties or commitments except as set forth herein. This Agreement supersedes all prior understandings, negotiations and discussions, written or oral, of the parties relating to the transactions contemplated by this Agreement. This Agreement may not be changed orally but only by an agreement in writing, signed by the party against whom enforcement of any waiver, change, modification, or discharge is sought.

9.9 Headings; Construction. The headings to the clauses, sub-clause and parts of this Agreement are inserted for convenience of reference only and are not intended to be part of or to affect the meaning or interpretation of this Agreement. The terms “this Agreement,” “hereof,” “hereunder” and any similar expressions refer to this Agreement and not to any particular Section or other portion of this Agreement. As used in this Agreement, the words “include” and “including,” and variations thereof, shall be deemed to be followed by the words “without limitation” and the word “discretion” means sole discretion.

9.10 Governing Law. This Agreement shall be governed by and construed in accordance with the laws of the State of California without giving effect to any conflict of law principles. The Federal and State courts located in San Francisco County, California shall be the exclusive venue for any disputes under this Agreement, and the parties hereby consent to the personal jurisdiction of those courts for such purposes.

9.11 Provisions Severable. If any provision of this Agreement shall be or become wholly or partially invalid, illegal or unenforceable, such provision shall be enforced to the extent that it is legal and valid and the validity, legality and enforceability of the remaining provisions shall in no way be affected or impaired. This Agreement shall be binding upon and inure to the benefit of the parties hereto and their respective successors, legal representatives and permitted assigns.

9.12 Waivers; Cumulative Remedies. No failure or delay by a party to insist upon the strict performance of any term or condition under this Agreement or to exercise any right or remedy available under this Agreement at law or in equity, shall imply or otherwise constitute a waiver of such right or remedy, and no single or partial exercise of any right or remedy by any party shall preclude exercise of any other right or remedy. All rights and remedies provided in this Agreement are cumulative and not alternative; and are in addition to all other available remedies at law or in equity.

9.13 Counterparts. This Agreement may be executed in two or more counterparts, each of which together shall be deemed an original, but all of which shall constitute one and the same instrument.