Build powerful custom apps with Cypher LM APIs

Use the Cypher LM REST API and signed webhooks to bring calls, bookings, task calls and follow-ups into your own systems.

Cypher LM TeamCypher LM Team
October 16, 202512 min read

Every business that uses Cypher LM eventually wants its call data somewhere else as well. A sales team wants new callers in its own systems. An operations team wants bookings on a wall display. A finance team wants a nightly report. A developer wants an agent to call a customer whenever an order is delayed. The dashboard covers the day-to-day; the Cypher LM APIs cover everything you want to build around it.

This guide introduces the Cypher LM developer platform: a REST API for reading calls, bookings, customer history and follow-ups and for starting task calls; signed webhooks that notify your systems when something happens; and an MCP server for AI assistants. It explains how authentication, rate limits and errors work, walks through each endpoint and event with practical uses, and ends with a build checklist.

It is written for developers and technical leads, but the first sections are useful for anyone deciding what to build. One note before we begin: the developer platform is built and currently in beta. API keys and webhooks are being opened to accounts gradually, and if you want access for your account, contact our team at team@cypherlm.com.

What you can build

The developer platform is designed around three kinds of integration, and most projects use more than one.

The first is reading your data into other systems. The REST API returns your agents, calls with transcripts and recordings, bookings, a customer's full history and open follow-ups. Typical projects include a nightly export to a data warehouse, a dashboard on an office screen showing today's bookings, or a report that combines call volume with sales figures.

The second is reacting to events as they happen. Webhooks send a signed message to your URL when a call's recap is ready, a booking is made or changed, a task call finishes or a meeting is summarised. Typical projects include creating a lead in your CRM when a new caller's recap arrives, alerting a team channel when a booking is cancelled, or updating an order system when a task call confirms a delivery address.

The third is asking an agent to do something. The task calls endpoint lets your software ask one of your agents to contact a customer with a specific goal and questions to ask, then retrieve the outcome. Typical projects include confirming orders, collecting missing information, and following up on overdue items, triggered by events in your own systems.

The MCP server, covered in our post on the Cypher LM MCP server, exposes the same operations to AI assistants such as Claude, so people can ask questions about your business in plain language.

Whatever you build, start from the question you want answered or the job you want done, not from the endpoints. "Our sales team should see every new caller in the CRM within a minute" points straight to the call.completed webhook and the customer history endpoint. "Our operations manager wants tomorrow's bookings on a screen" points to GET /bookings on a schedule. Clear goals keep integrations small, which keeps them reliable.

Authentication, limits and errors

All requests go to the base URL https://api.cypherlm.com/api/v1 and are authenticated with an API key. Keys are created in the dashboard under Automations › Webhooks & API keys, start with "clm_", and are sent on every request in the Authorization header as a Bearer token.

Keys are shown once, when you create them, and are stored by Cypher LM only as a SHA-256 hash, so a lost key cannot be recovered; create a new one instead. Revoking a key takes effect immediately. Give each key a name that records where it is used, and create one key per integration so you can revoke them independently.

Each key can make 120 requests a minute. Beyond that, requests receive HTTP 429 with a Retry-After header telling your client how long to wait. For most integrations, this is generous; if you are polling, prefer webhooks, which remove the need to poll at all.

Errors always use the same shape: an error object with a machine-readable code and a human-readable message. The codes you are most likely to see are:

  • 401 UNAUTHORIZED: the key is missing, wrong or revoked.
  • 402 PRODUCT_NOT_IN_PLAN: the account's plan does not include the API. The developer platform is available on Trial, Premium and Enterprise plans.
  • 403 ACCOUNT_SUSPENDED: the account is suspended, for example for billing reasons.
  • 404 NOT_FOUND: the call, task or other resource does not exist or belongs to another account.
  • 429 RATE_LIMITED: too many requests; wait for the time given in Retry-After.

The REST endpoints

The API is deliberately small. Each endpoint maps to something you can see in the dashboard, and each returns JSON.

Method and pathWhat it returnsTypical use
GET /meBusiness name, plan and included productsChecking a key and its plan at start-up
GET /agentsVoice agents with id, name, status, purpose and bookingsMapping calls to agents in reports
GET /callsRecent calls, newest first, excluding test callsExports, dashboards, syncing new calls
GET /calls/:idOne call with transcript and recording URLArchiving, quality review, analysis
POST /tasksStarts a task callAsking an agent to contact a customer
GET /tasks/:idTask status and outcomeReading the result of a task call
GET /bookingsBookings, upcoming by default, filtered by date range and statusSchedules, displays, capacity reports
GET /contacts/:contact/historyOne customer across calls, bookings, meetings, task calls and open follow-upsCRM enrichment, account views
GET /followupsFollow-ups agreed on calls and meetings, filtered by statusTask lists, accountability reports

GET /calls accepts a limit, an agentId filter and a "before" timestamp. Each page includes a nextBefore value; pass it as "before" to fetch the next, older page. This cursor-style pagination is stable even while new calls arrive.

GET /contacts/:contact/history takes a phone number, an email address, or an explicit form such as phone:923001234567. It returns everything Cypher LM knows about that customer in one response, which makes it the most useful single endpoint for CRM integrations.

Starting task calls from your systems

Task calls are the one place where the API takes action. A POST to /tasks asks one of your agents to contact a customer about something specific, and the agent handles the conversation and reports back.

A task request includes these fields:

  • agentId: which of your agents should make the call.
  • goal: what the call should achieve, in plain language, such as "Confirm the delivery address for order 1042".
  • customer: the customer's name, phone number and email.
  • questions: a list of answers to collect, such as "Is the address still correct?" and "Best time to deliver?"
  • channel: "phone" to call the customer, which needs a connected phone number, or "web_link" to email the customer a personal link that opens a call in their browser.
  • scheduledFor: an optional time to start the task; omit it to start now.

If you choose the phone channel on an account without a connected number, the task is created with the status not_configured; use web_link instead until a number is connected. Our team connects numbers on request.

When the call ends, GET /tasks/:id returns the outcome: a result (achieved, partly achieved, not achieved or unreachable), a summary, the answers collected and the next steps. Rather than polling, subscribe to the task.completed webhook, which carries the same outcome the moment it is ready.

Task calls work well as the final step of an automated process. An order system can start one when a delivery fails, a clinic system when a test result needs a follow-up appointment, a subscription system when a renewal is due. Keep the goal to a single, clear outcome, list only the questions you need answered, and let the outcome feed straight back into your system.

Webhooks: reacting to events

Webhooks are the most efficient way to keep another system in step with Cypher LM. You add an endpoint, a public https address, in Automations › Webhooks & API keys, choose which events to receive, and Cypher LM sends a signed POST request to that address each time one happens.

  • call.completed: a call's recap is ready.
  • booking.created, booking.rescheduled, booking.cancelled, booking.no_show: changes to Cypher S bookings.
  • task.completed: a task call has finished, with its outcome.
  • meeting.summarized: a Copilot call or meeting note has been summarised.

Each delivery has a JSON body with an id, a type, a createdAt timestamp and a data object, and three headers: X-Cypher-Event, X-Cypher-Delivery and X-Cypher-Signature. The signature header has the form t=timestamp,v1=signature, where the signature is an HMAC-SHA256 of the timestamp, a full stop and the raw request body, using your endpoint's signing secret. To verify a delivery, recompute the HMAC with your secret, compare it to v1 using a constant-time comparison, and reject deliveries whose timestamp is more than five minutes old.

Answer with any 2xx status within eight seconds. If your endpoint fails or times out, Cypher LM retries after 1 minute, 5 minutes, 30 minutes, 2 hours and 6 hours, six attempts in all. An endpoint that fails 20 times in a row is paused automatically, and you can switch it back on in the dashboard. Event ids are stable across retries, so de-duplicate on them. Send test posts a ping event, which is the quickest way to check your endpoint and signature code.

How this works in Cypher LM

The developer platform reads and writes the same data your team uses in the dashboard, so what you build stays consistent with what people see.

Calls come from your Cypher V agents, with recaps written by Cypher N. Bookings come from Cypher S, whether made on a call, from your booking link or by hand. Customer history comes from Cypher C, which groups calls, bookings, meetings, task calls and follow-ups by phone number or email. Follow-ups come from call recaps and meeting notes. Task calls use the same Calls & tasks feature available in the dashboard, and appear there alongside tasks your team creates.

Management happens in Automations › Webhooks & API keys: creating and revoking keys, adding and editing webhooks, rotating signing secrets, sending tests, reviewing recent deliveries with their attempts and status, and retrying failed deliveries. The Endpoints section shows the REST and MCP addresses for your account.

If you would rather not build integrations yourself, much of the common work is already automated inside Cypher LM, including recap emails, booking confirmations and reminders, receipts and a Google Sheets log of calls, bookings and payments. Our post on Cypher LM automations explains what runs without any code.

Plan for change from the start. Treat unknown fields in responses and webhook payloads as something to ignore rather than an error, so your integration keeps working as Cypher LM adds information. Log the event ids and delivery ids you receive, which makes it easy to trace any problem back to a specific delivery in the dashboard's recent deliveries list.

A build checklist

Most integrations follow the same path from idea to production. Working through it in order avoids the common mistakes.

  1. Request developer access for your account from team@cypherlm.com, and confirm your plan includes the API by calling GET /me.
  2. Create a dedicated API key for the integration, named after it, and store it in your secret manager rather than in code.
  3. Read before you write. Start with GET /calls and GET /bookings to understand the data, using small limits.
  4. Add a webhook endpoint for the events you need, verify signatures from the first delivery, and use Send test to check your code.
  5. Make handlers idempotent by recording event ids and ignoring repeats, because retries are part of normal operation.
  6. Respond quickly with a 2xx and do slow work in the background, so deliveries never time out.
  7. Handle 429 responses by waiting for the Retry-After period, and avoid tight polling loops.
  8. Test task calls with your own details using the web_link channel before sending them to customers.
  9. Monitor the recent deliveries list in the dashboard, and alert on paused endpoints.

Frequently asked questions

Is the API available on every plan?

The developer platform is available on Trial, Premium and Enterprise plans, and is currently in beta while it is opened to accounts gradually. Contact team@cypherlm.com to request access.

Can the API create bookings or change settings?

No. The API reads calls, bookings, customer history and follow-ups, and starts task calls. Bookings are made by your agents, your booking link or your team in the dashboard.

How do I know a webhook really came from Cypher LM?

Verify the X-Cypher-Signature header: compute an HMAC-SHA256 of the timestamp, a full stop and the raw body with your signing secret, compare it to v1, and reject old timestamps.

What happens if my endpoint is down?

Cypher LM retries after 1 minute, 5 minutes, 30 minutes, 2 hours and 6 hours. After 20 consecutive failures, the endpoint is paused until you switch it back on.

Can I place real phone calls through the API?

Yes, if a phone number is connected to your account. Otherwise, use the web_link channel, which emails the customer a personal link to a call with your agent.

Conclusion

The Cypher LM APIs give developers a small, predictable surface: a handful of REST endpoints for reading what your agents and team have done, task calls for asking an agent to act, signed webhooks for reacting in real time, and an MCP server for AI assistants. Together they let you bring every call, booking and follow-up into the systems your business already runs on.

If you are ready to build, write to team@cypherlm.com for developer access. If you are still evaluating Cypher LM, book a demo and bring your integration questions, or compare plans to see what is included.