On this page8 sections+
Define the business event first
An integration works only when both parties give each event the same meaning. Before discussing payloads, we define:
- what makes a lead eligible to enter the queue;
- which identifier stays attached to that lead;
- when a person counts as reached;
- what constitutes a confirmed order;
- which order changes the agent may return;
- which decline, callback and contactability reasons are required;
- how corrections and downstream delivery feedback are handled.
The definitions become the data contract. The transport comes next.
What can enter the calling operation
A project intake can include the fields needed to identify the lead, contact the customer, run the approved sale and preserve campaign context. The exact set depends on the offer and the client's authority to collect and share the data.
Typical field groups are:
| Field group | Why it is needed |
|---|---|
| Lead identity | Keep one record tied to one customer inquiry |
| Contact details | Reach the person who submitted the inquiry |
| Market | Route the lead to the correct in-country team |
| Offer and order | Show the product, quantity and current commercial terms |
| Source context | Preserve the permitted campaign, publisher or subID reference |
| Timing | Retain when the inquiry was created and received |
We agree how test records, duplicates, wrong-market submissions, missing fields and invalid contact data are treated before they affect reporting.
What returns
The result should tell the next team what happened and what, if anything, changed.
Define the status model before integration
Sample event model
This model is a starting structure, not a universal production taxonomy:
| Public example code | Minimum meaning |
|---|---|
accepted |
The record entered the calling queue after the project's technical and eligibility exclusions |
customer_reached |
The project-defined human-connection threshold was met |
callback_due |
The customer requested another permitted contact time |
confirmed |
The customer agreed the required order details |
order_updated |
An approved order field changed during the call |
closed_no_order |
The conversation ended without a confirmed order and with an agreed reason |
closed_unreachable |
The configured attempt path ended without a qualifying connection |
excluded |
The record cannot proceed under the project's intake rules |
Downstream delivered-and-paid feedback may also return to the calling operation when the client or fulfillment data source supplies it. TheCall does not create that delivery event; it uses the feedback to review what happened after confirmation.
Corrections are part of the design
Status data is not trustworthy if nobody knows how to correct it. During technical discovery, the parties decide:
- which system owns the lead identifier;
- whether an event replaces or appends to an earlier event;
- how repeated data events are recognized;
- how an order change is distinguished from a new order;
- when a status becomes final for reporting or billing;
- how a disputed or incorrectly mapped event is reconciled.
The exact implementation depends on the client systems and passes a feasibility review. TheCall does not claim a universal connector or compatibility with every CRM, tracker or store platform.
Real-time API or practical exports
A real-time API is available when it fits the project; email, Google Sheets, CSV or Excel can cover simpler reporting needs. The format, field set and reporting cadence are set for the project.
There is no default client dashboard and no advertised Shopify plug-in. If a custom integration or dashboard is needed, describe the system and use case in the project brief so feasibility can be reviewed.
What the technical brief should include
- the system that creates the lead;
- sample input and expected output fields;
- market and offer;
- daily lead volume and peak pattern;
- source, publisher or subID fields that must be preserved;
- required statuses and reasons;
- order fields an agent may change;
- correction and reconciliation needs;
- the downstream system or team receiving the result;
- test-data and launch dependencies.
Do not send customer lists or sensitive production records through the website form. Use the form to describe the systems and the required exchange.
Frequently asked questions
Do you provide a public API?
No. TheCall configures project data exchange after the commercial and technical requirements are understood. Agreed events and fields can move through a real-time API, but this is not a self-service developer product.
Can you integrate with our CRM or affiliate tracker?
Possibly. Custom integration requires technical discovery and a feasibility review. We do not promise compatibility with an unnamed system before examining the required events, fields and access method.
Do clients receive a live dashboard?
Not by default. Project reporting can use configured API events, email, Google Sheets, CSV or Excel. A custom dashboard may be considered for a project but is not part of a standard package.
Can affiliate source identifiers be preserved?
Where those identifiers are supplied, permitted and included in the project data contract, they can remain attached to the lead and returned outcome.
What to send before technical discovery
If the integration is still being designed, send the project stage, market, offer, current system and the decisions the returned data must support. We can use that brief to prepare the technical discussion.
Next step
Define the operating boundary.
Send the market, expected lead flow, required call work, current systems and the outcome or commercial event that must be defined.