Ingest
¶ Environment first
Call-log ingest depends on the production integration keys and environment variables being present on the component that actually handles call ingestion.
Configured
Ready
Calls guide
¶ Call logs are context, not a conversation record.
ReplyBox can ingest call logs when the relevant integration keys and production environment variables are configured. The guide separates what a call log proves from what requires a recording, transcript, or staff-authored note.
Call-log ingest
Provenance required
503 when misconfigured
Metadata
¶ Logs identify the event
A call log can establish that a call happened and carry operational fields such as parties, timestamps, duration, direction, and ingest status.
Allowed claim
Call happened
AI boundary
¶ No summary from metadata
Do not claim to summarise what was discussed from metadata alone. Summaries need a source that contains conversation substance.
Blocked claim
Conversation summary
Source ladder
¶ Use the strongest available source
Call summaries and customer follow-up automation require recording, transcript, or staff-authored notes with source provenance. If none exist, the UI should stay at call-log level.
1RecordingBest raw source when capture is enabled and permitted.
2TranscriptUsable for AI summaries when tied back to the call source.
3Staff noteHuman-authored context is acceptable when provenance is visible.
4Metadata onlyOnly supports call existence, routing, and operational status.
Operational behavior
¶ What the system should surface
¶ 503 means configuration
Call-log ingest may return 503 when production environment variables are unset or attached to the wrong component.
¶ Show provenance
Every generated call summary or follow-up should disclose whether it came from a recording, transcript, or staff-authored note.
¶ Refuse unsupported detail
When only metadata exists, AI should describe the log and avoid inventing topics, intent, sentiment, promises, or next steps.
¶ Follow-up needs substance
Customer automation can use call context only after the source includes conversation content that justifies the action.
Safe from metadata
¶ Call-log facts
- Whether the call record was ingested.
- Who the call is associated with, if the integration provided that mapping.
- Timing, direction, duration, status, and routing fields from the call provider.
Needs source content
¶ Conversation claims
- What the customer asked for or complained about.
- Whether an agent promised a follow-up, refund, callback, or escalation.
- Sentiment, intent, action items, and any AI-written call summary.
Missed inbound calls
¶ The server decides whether a call was returned
CallCallback on CallLogPublic is an optional { kind: 'none' | 'call' | 'message', at, minutes }, populated only for MISSED INBOUND rows. Older clients treat a missing field as unknown and fall back to deriving it themselves.
¶ How it is computed
The server looks for later OUTBOUND calls or OUTBOUND messages to the same peer, restricted to the peers shown on the page and floored at the page's earliest missed call.
¶ Which event wins
The earliest event after the missed call wins. A simultaneous call and message ties to call. Minutes are floored, so 1m59s reads as 1 min.
¶ peer_key
Mirrors the web derivation: a bare phone wins, @lid without a number is excluded, and group JIDs are not treated as callable peers.
¶ The pill reads the server fields
When present, the call-back pill displays the server-provided kind, at, and minutes. This is a UI change only: the pill prefers server-backed fields over local inference, so displays cannot disagree.
Troubleshooting
¶ When ingest fails
Start with deployment configuration before debugging product behavior. A healthy UI cannot compensate for missing provider keys on the wrong runtime component.
Verify production integration keys are set.
Confirm the env vars are attached to the ingest component.
Treat persistent
503 as configuration or service readiness failure.
Check whether any recording, transcript, or staff note exists before enabling summaries.