# Debug your integrations with API Logs

An invoice failed to sync. A bill was rejected. A customer’s connection stopped working. Start with the request that failed, then follow it through to the accounting platform.

[Open Logs in the dashboard](https://platform.apideck.com/logs) · [Logs API reference](/apis/vault/reference/logs#logsAll)

## Worked example: a rejected bill

Fictional IDs and excerpts; no requests are sent.

### 1. Your request: Find the account reference in the bill

Sample: consumer account:12345 is connected to QuickBooks. This bill uses ledger account 64, copied from another company. IDs below are fictional; the payload is an excerpt, not a complete runnable request.

- **Consumer**: account:12345
- **Connector**: quickbooks
- **Operation**: POST /accounting/bills

```text
{
  "bill_number": "DEMO-1042",
  "supplier": {
    "id": "21"
  },
  "line_items": [
    {
      "description": "Hosting",
      "quantity": 1,
      "unit_price": 100,
      "ledger_account": {
        "id": "64"
      }
    }
  ]
}
```

### 2. Connector response: Trace the rejection to the downstream account

Open the parent log, then View child. In this illustrative failure, the downstream account reference is 64 and the connector rejects it. Compare that value with line_items[0].ledger_account.id in the parent request; do not assume every validation error has this cause.

- **Downstream reference**: 64
- **Example diagnosis**: Account reference is unavailable in this company
- **Next check**: Read ledger accounts using the same consumer and connector

```text
Parent: POST /accounting/bills
  line_items[0].ledger_account.id = "64"
    → Child request: inspect the account reference sent to QuickBooks
    → Child response: inspect the actual validation detail
    → Confirm which company owns the referenced account
```

### 3. Correct the mapping: Resolve an account from the connected company

Read ledger accounts with account:12345 and quickbooks, following pagination if needed. Confirm the appropriate expense account with your customer. In this example its ID is 82. Save that mapping under the consumer and connector, not as a global account ID.

- **Read**: GET /accounting/ledger-accounts
- **Replace**: 64 → 82 in the bill line
- **Keep unchanged**: Consumer, connector, supplier, and bill number

```text
{
  "description": "Hosting",
  "quantity": 1,
  "unit_price": 100,
  "ledger_account": {
    "id": "82"
  }
}
```

### 4. Verify the result: Check the outcome before retrying the write

A timeout is not proof that creation failed. Inspect the original result and reconcile any uncertain outcome in the source company before creating again. After a confirmed rejection and correction, submit once; use the actual returned bill ID to read it back.

- **Before retry**: Establish whether DEMO-1042 already exists
- **After success**: GET /accounting/bills/{RETURNED_BILL_ID}
- **Verify**: Supplier 21, the intended amount, and ledger account 82

```text
Same consumer: account:12345
Same connector: quickbooks
Bill number: DEMO-1042
Supplier: 21
Ledger account on the line: 82
Persist: actual returned bill ID + consumer + connector
```

Follow the [worked failure investigation](/guides/investigate-failed-request) for a synthetic permission failure, an explicit correction and a verified rerun.

## Find the request

1. Open **Logs** in the [Apideck dashboard](https://platform.apideck.com/logs). Confirm you are in the application where the request was made.
2. Filter by connector, then match the consumer, operation and timestamp to your application’s failed job. Include the timezone when comparing timestamps.
3. Open the request to inspect its status and request/response details. Follow related connector requests to see what the downstream platform returned.

The dashboard exposes both the call to Apideck and its related connector calls. See the [dashboard walkthrough](https://help.apideck.com/en/articles/4232578) for the current controls.

## Follow parent and child requests

The **parent request** is your call to the Unified API. A **child request** is a related call Apideck makes to the downstream service. Inspect both sides to see what was sent to the connector and how its response became the unified result.

```text
Your application
  → Parent: request to Apideck + unified response
      → Child: request to the connector + connector response
```

In the dashboard, open the request details and use **View child** to inspect the connector exchange. Use **View parent** to return to the Unified API call. These controls are shown in the [Logs walkthrough](https://help.apideck.com/en/articles/4232578).

In the Logs API, `child_request: true` identifies a child log, and `parent_id` points to its parent’s `id`. Group related records by these IDs, rather than assuming one Unified API request always corresponds to one downstream call. A connector can require more than one call to complete an operation; investigate the recorded calls for the specific request.

## Compare downstream data with the unified model

For a record that looks wrong, inspect the parent and child payloads together:

| Compare | What it helps establish |
| --- | --- |
| Parent request → child request | Which values and references were sent to the connector. |
| Child response → parent response | How the connector’s fields appear in the unified result. |
| Selected consumer and service | Whether you are looking at the intended customer and accounting company. |
| Connector field coverage | Whether a missing field is supported by that connector. |

For example, when an invoice’s customer or currency is unexpected, first find that invoice in the child response. Compare its customer reference and currency with the parent’s normalized record. For writes, also compare the submitted parent payload with the actual child request. Do not assume matching field names or IDs across providers.

On operations that support it, [raw mode](/guides/using-raw-mode) returns the downstream response in `_raw` alongside normalized `data`. It helps compare responses; it is not a complete trace of outgoing child requests. Use Logs for the request sequence. Payload availability depends on retention and the information recorded for that call.

If a needed provider field is absent from the unified model, check [custom field mapping](/guides/field-mapping) and the connector’s coverage before changing your integration. Logs reveal the observed exchanges; they are not a published specification of every internal transformation rule.

## Understand where it failed

| What you find | What to check next |
| --- | --- |
| The request is rejected before reaching the connector | Check the Apideck credentials, consumer ID, selected service and request format. |
| The connector rejects the request | Inspect its response for the missing field, invalid reference, permission or accounting rule. |
| The request succeeds but the record looks wrong | Compare the submitted values with the returned record and your field mappings. |
| A write times out or the outcome is unclear | Reconcile with the destination before retrying to avoid creating a duplicate bill or payment. |

For example, if bill creation fails because a supplier or account reference is invalid, verify both IDs against the **same connected company**. Correct the mapping, confirm whether the original write created a record, and read back the bill after a successful request. The walkthrough above illustrates this sequence; it does not send API requests.

## Retrieve logs from your backend

Use the Vault API’s [Get all consumer request logs](/apis/vault/reference/logs#logsAll) operation to retrieve logs for an application and consumer. Keep the API key on your server.

```bash
curl --get 'https://unify.apideck.com/vault/logs' \
  --header "Authorization: Bearer ${APIDECK_API_KEY}" \
  --header "x-apideck-app-id: ${APIDECK_APP_ID}" \
  --header "x-apideck-consumer-id: ${APIDECK_CONSUMER_ID}" \
  --data-urlencode 'limit=20'
```

Set these environment variables to your API key, application ID and the consumer you are investigating. This read-only request lists log metadata; inspect request and response payloads in the dashboard.

Use each log’s `id`, `timestamp`, `path`, `status_code` and `service` to locate the relevant call. `parent_id` and `child_request` describe related requests. To continue through the results, pass `meta.cursors.next` as the next request’s `cursor` until there is no next cursor. See the reference for available filters.

## Turn the diagnosis into a fix

- **Authentication or permissions:** inspect the connection in [Vault](/guides/vault), confirm the connected account and scopes, and reconnect when required.
- **Unsupported operation or field:** check [Accounting coverage](/apis/accounting/coverage) for the selected connector before changing your payload.
- **Validation errors:** use the [error reference](/errors) and connector response to fix the input. Repeating the same invalid request will not resolve it.
- **Rate limits or service failures:** check [connector status](/status/connectors) and apply bounded retries with backoff. Reconcile uncertain writes first.

## Share useful debugging context

When escalating an issue, include the request ID, UTC timestamp, application and consumer IDs, connector, operation, observed status and the expected result. Attach only the relevant, redacted request/response excerpt. Remove credentials and customer-sensitive content before sending logs to support or a coding agent.

Ask an agent to explain the evidence and propose the smallest fix first. Have it distinguish a confirmed root cause from a hypothesis, and keep write retries subject to your application’s duplicate-prevention checks.

## Continue building

- [Accounts payable automation](/guides/accounts-payable-automation) — create a bill, record its payment and verify the result.
- [Error reference](/errors) — understand API error responses.
- [Vault Logs API](/apis/vault/reference/logs#logsAll) — integrate log retrieval into your backend.
- [Zero Data Retention](/guides/security-and-data-handling#zero-data-retention-and-its-boundaries) — review the distinction between business records, optional logs and connection credentials.
- [Dashboard overview](https://help.apideck.com/en/articles/7772994) — find connections, configuration and logs.