CALL-E developer integration

Help the developer finish their application using the current official contract and existing examples. Keep their language and framework; use direct HTTP when there is no suitable SDK. This skill adds no API or documentation MCP service.

Choose the integration and sources

For a new integration, read the quickstart and the relevant part of the SDK guide. Distinguish request-scoped Calls from running a published Goal; do not mix their inputs or identifiers. Use the documentation index to find additional topics, not to load the entire site.

Before writing or reviewing a request, inspect the relevant operation in the OpenAPI contract. For SDK code, also inspect the installed package version and its public types or source: TypeScript or Python. HTTP fields and SDK arguments are not interchangeable. For payload reviews, inspect the SDK's request-building code, including compatibility aliases and which arguments become headers rather than JSON fields; a README alone does not establish that mapping. The Calls idempotency key belongs in the Idempotency-Key header over HTTP. Cite the source used and record the package version when reporting verification. If sources are unavailable or conflict, identify the specific unverified behavior rather than inventing fields.

Read references/examples.md to choose an existing starting point. Reuse it before creating another client, receiver or schema copy. Read references/safety.md before implementing or running any live path.

Build the requested flow

• Keep credentials on the backend. Start with a preview or offline check; a code request is not authorization to place calls. Preserve the user's existing scoped authorization when live testing is requested.
• Check recipient inputs and both result-schema fields against the chosen contract. Use supported schema features and represent uncertain answers. Check the supported regions before choosing destinations, regions or locales.
• Save the business intent, complete request and stable idempotency key before submission, then save the returned Call ID. When resuming, fetch that ID; do not create a replacement just because waiting failed. For a lost create response, follow the current recovery and error guide with the saved request/key and stop automatic redial while acceptance is unknown.
• Distinguish transport errors, API rejection, terminal call status and the business outcome. A completed call is not proof of a booking or other requested result. Validate the returned structured result; preserve null or unknown for review. Apply business-state changes once, including after a process restart.
• For webhooks, read the current delivery and verification guide. Current event-ID matching is a consistency check, not sender authentication; do not invent a signing secret or signature header. Verify sensitive results through an authenticated API read and bind them to the saved call, workflow and recipient. Keep event receipts separate from completion of the business update so an acknowledged event does not hide unfinished work.

Verify the result

Run the checks relevant to the code actually changed: request serialization, schema/result handling, repeated delivery and recovery as applicable. Use the host's existing tools and tests; this skill requires no particular test framework. When authorized to validate the real-service flow, record the runtime/package version, steps and observed outcome. Keep simulated branches and untested paths distinct from live results. Do not call a generated integration verified merely because it compiles or its mocked request passes.

Return the changed code or concrete integration guidance, source links, checks performed and any remaining limitation. Keep raw credentials and private call data out of the answer.