All integrations

Mixmax

MESSAGING · MESSAGING

Sequences, snippets, messages, and meeting summaries under their own login.

Connecting Mixmax in practice

Mixmax counts its 120 requests per 60 second window per IP address and user, so several agents sharing one egress IP throttle each other even with separate tokens. The credential is a developer token in an X-API-Token header, and a number of endpoints are only available on the paid Small Business, Growth and Enterprise tiers.

Rate limits

  • 120 requests per a 60 second window, counted per IP address and user.
  • Overage is HTTP 429 with a Retry-After header.
  • X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset report the window, the last as a UTC epoch timestamp.

Worth knowing

  • The token can also be passed as an apiToken query parameter, which puts the credential into URLs and any log that records them.
  • Tokens are shown once at creation in Settings > Integrations, so rotation means re-pasting rather than reading the old value.
  • Collections return 50 results by default and page with opaque cursor strings in next and previous, so page numbers cannot be resumed from.
  • Endpoint availability is plan-dependent, the Calls endpoints are a limited beta behind an allowlist, and the contact groups endpoints are deprecated.

Checked against Getting started with the Mixmax API (2026-09-29), Mixmax developer documentation index (2026-09-29)

Acts as the person, not as itself

Each user connects their own account. Every call carries both identities — the agent and the person it is acting for — so the agent can never reach past what that individual can already do.

Credentials never touch the agent

Tokens live in the vault and attach server-side at call time. The agent holds a session, not a secret, and revoking access does not mean rotating a key.

Every call on the record

Who asked, which agent acted, which action ran, and the verdict that let it through — one audit trail across every integration, not one per vendor.

What an agent can do

Each action is granted on its own. An agent allowed to read is not thereby allowed to write, and the scope beside each row is what the acting user must have connected for it to run at all.

mixmax_delete_v1_contactgroups_by_id_contacts_by_contactidWRITE

/contactgroups/:id/contacts/:contactId [deprecated] via DELETE /v1/contactgroups/{id}/contacts/{contactId}

api
mixmax_delete_v1_snippettags_by_idWRITE

/snippettags/:id via DELETE /v1/snippettags/{id}

api
mixmax_get_v1_callsREAD

/calls via GET /v1/calls

api
mixmax_get_v1_calls_by_id_transcriptREAD

/calls/:id/transcript via GET /v1/calls/{id}/transcript

api
mixmax_get_v1_contactgroupsREAD

/contactgroups [deprecated] via GET /v1/contactgroups

api
mixmax_get_v1_filerequestsREAD

/filerequests via GET /v1/filerequests

api
mixmax_get_v1_meetings_summaries_searchREAD

/meetings/summaries/search via GET /v1/meetings/summaries/search

api
mixmax_get_v1_meetings_transcripts_by_idREAD

/meetings/transcripts/:id via GET /v1/meetings/transcripts/{id}

api
mixmax_get_v1_messages_by_idREAD

/messages/:id (GET) via GET /v1/messages/{id}

api
mixmax_get_v1_rulesREAD

/rules (webhooks) via GET /v1/rules

api
mixmax_get_v1_sequencesREAD

/sequences via GET /v1/sequences

api
mixmax_get_v1_snippetsREAD

/snippets (aka Templates) via GET /v1/snippets

api
mixmax_patch_v1_contactgroups_by_idWRITE

/contactgroups/:id [deprecated] via PATCH /v1/contactgroups/{id}

api
mixmax_patch_v1_messages_by_idWRITE

/messages/:id (PATCH) via PATCH /v1/messages/{id}

api
mixmax_post_v1_messages_by_id_sendWRITE

/messages/:id/send via POST /v1/messages/{id}/send

api
mixmax_post_v1_reports_data_tableWRITE

/reports/data/table via POST /v1/reports/data/table

api
mixmax_post_v1_teamsWRITE

/teams via POST /v1/teams

api

Put Mixmax behind one governed endpoint.

Same permissions, same audit trail, whatever else you connect next.