Apideck
Apideck · Logs
Schedule a demo
Request logs

Tracing a call end to end

Every call through Apideck is logged and viewable per consumer. Each entry is a linked pair: the unified request you made, and the raw request Apideck made downstream.

Interactive

The parent, and the child. Both kept.

Jump between the two with View child and View parent to trace any call end to end. Pick a call, then pick a half.

One entry, two halves
View child| View parent

Nothing to debug — but note the shapes. You wrote a REST call against a unified model; NetSuite was asked in SOAP for a vendor payment search. Neither of those facts is in your code.

GET/accounting/bill-payments200 412ms
unify.apideck.com·parent

The unified request you made, and the normalized response — identical across every connector.

{
"status_code": 200,
"status": "OK",
"service": "netsuite",
"resource": "BillPayments",
"operation": "all",
"data": [
{
"id": "12345",
"downstream_id": "PYMT-9981",
"currency": "USD",
"total_amount": 1250.00,
"reference": "Bill payment - March",
"payment_method": "check",
"transaction_date": "2026-03-04T00:00:00.000Z",
"updated_at": "2026-03-04T11:22:08.114Z"
}
]
}
Why it matters

The abstraction stays inspectable.

A unified API is a layer between your code and a system you don't control. The moment something goes wrong, the useful question is which side of the layer it went wrong on — and that's a question you can only answer if both sides were recorded.

The parent is your contract

What you sent, and the normalized response you got back. If this looks wrong, the problem is in your call or in the mapping.

The child is the truth

Exactly what the connector received and returned, in its own format. If this looks wrong, the problem is downstream — and you have the evidence.

Nobody has to guess

Support conversations become a link to a log entry instead of a description of what you think happened.

In practice
When a downstream system rejects a write, the child call is usually the fastest path to the answer: connectors are specific about which field they didn't like, even when their error format is nothing like ours. Read the child, fix the payload or the field mapping, retry.