> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bindbee.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Logs

> Trace which API Bindbee called and what came back.

Every request between Bindbee and a source system is recorded here. Come to this page once [sync status](/guides/troubleshooting/sync-status) and the [error's source](/guides/troubleshooting/errors) have left the question open.

<Note>
  A model reported **Skipped** or **Not Supported** was never requested, so the logs hold no
  entry for it. [Sync status](/guides/troubleshooting/sync-status) settles both.
</Note>

## Where to find them

Open **Logs** in the dashboard for the whole account, or open a single connector to scope it to that customer. Scoping to the connector is faster.

<Frame>
  <img src="https://mintcdn.com/unifyx-56/NU46D4mywOWu_9HZ/images/platform/logs.png?fit=max&auto=format&n=NU46D4mywOWu_9HZ&q=85&s=f9985a0b7a7b1100cc13784677e882ea" alt="The Logs view in the Bindbee Dashboard, listing requests by connector" className="block" width="2582" height="1506" data-path="images/platform/logs.png" />
</Frame>

## What an entry holds

| Field              | Holds                                                    |
| ------------------ | -------------------------------------------------------- |
| Direction          | `READ` or `WRITE`                                        |
| Connector          | Which customer's connection the request belongs to       |
| Endpoint           | The path called, on Bindbee or on the source system      |
| Status             | The response code, and the error code where there is one |
| Request & response | The full bodies. Open an entry to expand them            |

<Tip>
  Read the upstream response body first. Bindbee keeps the source system's own answer
  verbatim, and that body names the permission or field at fault - see
  [Origin-system errors](/guides/troubleshooting/errors#origin-system-errors).
</Tip>

## Find an answer

| Question                                      | Where to look                                                                                      |
| --------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| Why is this connector not returning benefits? | `READ` entries for the benefits endpoint. A `403` means permissions. No entry means scope          |
| Why did my write fail?                        | The `WRITE` entry, then the source system's response body                                          |
| Why is a record I expected missing?           | The `READ` entries for that model - see [Missing records](/guides/troubleshooting/missing-records) |

## Connector logs are dashboard-only

There is no API for them. Anything your own monitoring acts on has to come from sync webhooks or the connector's `status` and `sync_status` fields.

### Webhook delivery logs are separate

They record Bindbee's attempts to reach *your* endpoint, so they answer why your handler stayed quiet. Those do have an API: [List Webhook Logs](/api-reference/webhooks/list-webhook-logs), and the dashboard keeps them on the [Webhooks tab](https://app.bindbee.dev/logs/webhooks) under Logs.

<Frame>
  <img src="https://mintcdn.com/unifyx-56/NU46D4mywOWu_9HZ/images/platform/webhook_logs.jpg?fit=max&auto=format&n=NU46D4mywOWu_9HZ&q=85&s=47a9eedcc6d80a5d2f6f5cac12d4affb" alt="The Sync info screen for a run marked Partial, listing Employee and Company as Synced, Employment as Skipped with no records, Dependent as Failed with an expanded Issue and Message showing User not authorized and a Permission issue found banner, and three models still Pending" width="1611" height="1182" data-path="images/platform/webhook_logs.jpg" />
</Frame>

## Limits

* **An empty field.** A `200` with the field absent leaves no error to find. That's scope, permissions, or the unified model - see [Scoping](/get-started/scoping).
* **An upstream deletion.** A record disappearing produces no request, so no entry.
* **Retention.** The window is unpublished, so treat logs as a recent-debugging tool rather than an audit trail.

## Related

* [Troubleshooting overview](/guides/troubleshooting/overview) - where this page sits in the flow
* [Sync status](/guides/troubleshooting/sync-status) - the first check, and the one that resolves most cases
* [Errors](/guides/troubleshooting/errors) - differentiating a Bindbee failure from an origin-system one