MYLO Call API: How to Place and Track a Business Call

A useful calling integration does more than submit a phone number. It creates one authorised business action, receives a durable MYLO call identifier, and follows the resulting events until the outcome is known. The current MYLO API catalogue and backend contract are authoritative for exact fields and allowed values. This guide explains the operating pattern without encouraging developers to invent parameters or treat an accepted request as a completed conversation.

Own the Customer Experience Around the API

The application that requests a call should show the operator whether the request is being prepared, accepted, active, completed, failed, or still uncertain. Disable duplicate submission while an idempotent request is unresolved and provide a supported way to open the MYLO record. If the business workflow sends a message, schedules a callback, or assigns a lead after the call, trigger it from the correct confirmed outcome rather than the initial HTTP response. Clear state protects both the customer and the agent from duplicate or contradictory follow-up.

Plan Timeouts and Uncertain Results

An HTTP client timeout describes what the client observed, not what MYLO did. The appliance may have accepted the operation just before the connection closed. Mark the result uncertain, retain the idempotency key and request correlation data, and use the documented retrieval path to determine whether a call exists. Do not issue a new business request until that uncertainty is resolved.

Use bounded network retries with backoff only for conditions the contract identifies as safe. Validation, authentication, authorisation, and policy failures require correction rather than repetition. Capacity or provider failures may need operational intervention. Surface the distinction to the business user so “retrying” never becomes an invisible loop of customer calls.

Verify With a Controlled Production Readiness Test

Use approved test identities and destinations to prove each supported connection flow. Confirm request validation, caller-ID selection, leg order, ringing, answer, two-way audio, hangup, event delivery, call retrieval, recording behaviour when approved, and the source application’s final update. Test no-answer and agent-unavailable outcomes as deliberately as the happy path.

Record the call ID and expected versus observed result without storing secrets. A passing internal extension test does not prove an external provider journey. Production readiness requires the actual authorised trunk and business route, a controlled destination, and acceptance by the operational owner.

Define the Business Journey First

Write down who should be connected first, who the second party is, which approved business number should be presented, what the customer should experience, and what result the source application needs. “Call this number” is incomplete when the flow also involves an agent extension, agent mobile, IVR, recording decision, schedule, consent, or retry policy.

Use the appropriate MYLO connection flow. A customer-first call and an agent-first call have different customer experience and failure semantics. The API request must represent a supported flow; it should not reproduce dialplan logic in the CRM or guess how Asterisk channels should be built.

Retrieve the Current Contract

Use the API page and controlled catalogue to confirm POST /api/v1/calls/outbound, its Bearer authentication, required request variables, allowed values, response schema, errors, and idempotency requirement. Use GET /api/v1/dids where supported to select an outbound identity the authenticated customer is allowed to use.

Do not paste a provider trunk identity into a customer-facing field unless the contract explicitly calls for it. Authentication identity, business DID, and presented caller ID can be different concepts. MYLO should validate the supported relationship; the calling application should send business intent using exact documented fields.

Validate the Request Before Sending

Normalise the destination according to the current contract, verify that it belongs to the intended customer record, and reject obviously missing or malformed data before requesting a call. Confirm time-zone and contact-policy rules in the source workflow. Calling authority and consent remain business responsibilities; a technically accepted API request does not prove lawful or appropriate contact.

Choose only supported connection and caller-ID options. Treat recording as an explicit pre-call decision where the flow supports it. Do not let a default silently turn recording on or off, and do not rely on an agent to resolve an ambiguous compliance choice after the call has begun.

Use Authentication and Idempotency

Send the protected access token in Authorization: Bearer <ACCESS_TOKEN>. Keep it out of application source, request URLs, command history, and ordinary logs. The integration identity needs only the permission required to place and inspect its supported calls.

For a mutating call request, supply Idempotency-Key where the current endpoint specifies it. Generate one key for one intended business call and retain the relationship in the source system. If a network timeout makes the result uncertain, retry with the same key or query the resulting record as documented. A new key represents a new action and can create another call.

Accepted Does Not Mean Answered

An HTTP success response means MYLO accepted or created the requested operation according to its contract. It does not prove that an endpoint rang, a customer answered, both call legs connected, DTMF arrived, audio worked, or the business objective was completed. Store the returned call identifier and any initial state rather than converting “accepted” into “successful call.”

Validation errors mean the request needs correction. Authentication and permission failures need an identity or access review. Capacity, provider, endpoint, or temporary service failures need operational handling. Respect documented status and error semantics; do not parse human-readable messages as stable program logic.

Track the Call by Its MYLO Identifier

Use the supported call reporting endpoint, including GET /api/v1/calls/{call_id} where that is the current contract, to retrieve the call’s business record. Correlate the MYLO identifier with the CRM activity or application job that initiated it. Never use a phone number and approximate timestamp as the only join key when several calls can overlap.

Expect an ordered lifecycle rather than one final Boolean. Submission, dispatch, leg creation, ringing, answer, bridge, completion, and failure evidence can arrive at different times. A two-leg flow may show a successful customer leg and a failed agent leg. Preserve that distinction because it affects customer experience and safe retry decisions.

Use Events for Timeliness, Retrieval for Confirmation

Where the supported integration exposes call events, process them as notifications that a business record changed. Verify event authenticity and scope according to the current contract, store the event identifier, and make consumers idempotent. Events may be delayed, delivered more than once, or observed after the retrieving client has already seen the new state.

Use the call retrieval API to reconcile uncertain or missed notifications. Do not let event arrival order alone rewrite a later final state with an older intermediate state. Record source timestamps and ingestion timestamps, and define a bounded reconciliation process for calls that remain unresolved beyond normal operating time.

Model Outcomes for Business Use

The source application should keep both the MYLO outcome and its own business meaning. No answer, busy, provider rejection, unavailable agent, abandoned customer leg, completed bridge, and completed IVR are different outcomes. “Failed” is too broad for reliable follow-up, reporting, or customer care.

Do not automatically retry a customer merely because an agent leg or downstream application failed. Determine whether the customer was already contacted or answered. Apply the approved retry policy, contact limits, schedule, consent rules, and human review where the outcome is uncertain.

Keep Reporting and Recordings Controlled

A call record may reference a recording, but the event history and audio are different resources. Retrieve a recording only through the authorised endpoint, such as GET /api/v1/recordings/{recording_id} when present in the catalogue. Do not construct filesystem paths or expose server storage locations to the client.

Phone numbers, agent identities, timings, results, and recordings are sensitive operational data. Store only what the business needs, restrict it by role and customer, define retention, and redact ordinary logs. The application should never log the Bearer token, provider credentials, or full request and response bodies by default.

Production Call Checklist

1. Define the supported customer and agent connection flow.
2. Retrieve the current endpoint contract and approved DID options.
3. Validate destination, schedule, consent, recording decision, and caller identity.
4. Send the Bearer token securely and use the documented idempotency control.
5. Store the returned MYLO call ID beside the originating business record.
6. Track leg-aware events and reconcile through the supported call endpoint.
7. Interpret outcomes before retrying or updating customer workflow.
8. Protect call details and verify the complete journey with authorised test calls.

The production pattern is request, identify, observe, reconcile, and interpret. MYLO owns the supported call operation and reporting relationship; Asterisk remains authoritative for live telephony evidence; the provider owns service on its network; and the business application owns the customer reason for the call.