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

# Developers

> API keys, integration logs, and API status for technical teams.

The **Developer** page (header: "Developer", description "Technical integration workspace for API keys, audit-backed logs, and API health.") is where technical teams manage credentials and check on the health of their integration.

<Note>
  Everything here is a thin layer over the same API your own services use. API keys created here work identically to keys created via [Create an API key](/api-reference/integrations/create-an-api-key).
</Note>

A banner on this page notes the current launch scope:

> Outbound webhook setup is hidden for launch because delivery workers and retry handling are not enabled yet. Launch scope is limited to API keys, integration logs, and core API health.

Three tabs are available: **API keys**, **Integration logs**, and **API status**.

## API keys

Backed by the API key endpoints:

* [List API keys](/api-reference/integrations/list-api-keys) — `GET /v1/api-keys`
* [Create an API key](/api-reference/integrations/create-an-api-key) — `POST /v1/api-keys`
* [Update an API key](/api-reference/integrations/update-an-api-key) — `PATCH /v1/api-keys/{keyId}`
* [Revoke an API key](/api-reference/integrations/revoke-an-api-key) — `DELETE /v1/api-keys/{keyId}`

The table lists each key's name, prefix, scopes, status, creator, and last-used time. Managing keys requires the `api_keys_manage` permission.

### Creating a key

<Steps>
  <Step title="Choose a name">
    A human-readable label, e.g. "Production integration".
  </Step>

  <Step title="Select scopes">
    Pick one or more scopes for the key:

    | Scope                       |
    | --------------------------- |
    | `payment_intents:write`     |
    | `payment_intents:read`      |
    | `reconciliation_cases:read` |
    | `imports:write`             |
    | `imports:read`              |
    | `exports:read`              |
    | `api_keys:manage`           |

    By default, new keys are pre-selected with `payment_intents:read` and `reconciliation_cases:read`.
  </Step>

  <Step title="Set an expiry">
    Specify how many days from now the key should expire. The dashboard converts this to an absolute `expiresAt` timestamp before calling the API.
  </Step>

  <Step title="Save the plaintext key">
    On creation, the API returns the key's plaintext value exactly once in the response. The dashboard shows it in a "Save your API key" step with a copy button and a warning:

    > This key will only be shown once. Copy it now and store it securely. After closing this dialog, only the prefix is visible.

    After this point, only the key's `prefix` is ever shown again — the plaintext cannot be retrieved later through the dashboard or the API.
  </Step>
</Steps>

### Editing and revoking

Selecting an existing key opens an edit modal where you can change its `name` and `scopes` ([Update an API key](/api-reference/integrations/update-an-api-key)). Revoking a key ([Revoke an API key](/api-reference/integrations/revoke-an-api-key)) is irreversible — a revoked key's `status` changes and it can no longer authenticate requests.

<Warning>
  Revocation is permanent. There is no "unrevoke" — create a new key if a service needs to be reconnected.
</Warning>

## Integration logs

This tab shows a paginated list (five per page) of recent activity, sourced from [List audit events](/api-reference/dashboard/list-audit-events) (`GET /v1/audit-events?limit=100`). Each entry shows:

* A formatted timestamp (from `occurredAt`)
* The `actor` that performed the action, shown as the log's source
* A message — either the event's `message` field, or its `eventType` if no message was recorded

This gives developers a lightweight activity feed without needing to build their own audit viewer. For full filtering (by event type, actor, related case, or related payment intent, plus date range), use the [Audit](/dashboard/audit) page or call `GET /v1/audit-events` directly.

## API status

This tab shows the operational status of the ReconLayer API your organization is calling, derived from [Get API health](/api-reference/health/get-api-health) (`GET /health`). The dashboard reports the service as **Operational** when the health check returns `status: ok`, along with the timestamp of the last successful check.

<Note>
  This tab reflects the live result of a health check against the API at request time — it is not a historical incident log. For build-your-own status pages or alerting, poll the health endpoint directly.
</Note>

## Outbound webhooks (not yet enabled)

The API includes a full set of outbound webhook endpoints for registering endpoints and inspecting delivery attempts:

* [List outbound webhook endpoints](/api-reference/outbound-webhooks/list-outbound-webhook-endpoints) — `GET /v1/outbound-webhook-endpoints`
* [Create an outbound webhook endpoint](/api-reference/outbound-webhooks/create-an-outbound-webhook-endpoint) — `POST /v1/outbound-webhook-endpoints`
* [Update an outbound webhook endpoint](/api-reference/outbound-webhooks/update-an-outbound-webhook-endpoint) — `PATCH /v1/outbound-webhook-endpoints/{endpointId}`
* [Delete an outbound webhook endpoint](/api-reference/outbound-webhooks/delete-an-outbound-webhook-endpoint) — `DELETE /v1/outbound-webhook-endpoints/{endpointId}`
* [List outbound webhook events](/api-reference/outbound-webhooks/list-outbound-webhook-events) — `GET /v1/outbound-webhook-events`
* [Queue an outbound webhook event](/api-reference/outbound-webhooks/queue-an-outbound-webhook-event) — `POST /v1/outbound-webhook-events`
* [Record an outbound webhook delivery attempt](/api-reference/outbound-webhooks/record-an-outbound-webhook-delivery-attempt)

These endpoints exist in the API but the dashboard does not yet surface a configuration screen for them, since the delivery worker and retry handling are still being built out. Managing webhook endpoints currently requires calling these endpoints directly and requires `webhooks_manage`.

## From here

<CardGroup cols={2}>
  <Card title="Authentication" icon="key" href="/api-reference/authentication">
    How to use API keys created here to authenticate requests.
  </Card>

  <Card title="List audit events" icon="list" href="/api-reference/dashboard/list-audit-events">
    Query the same activity feed shown in Integration logs, with full filtering.
  </Card>

  <Card title="Get API health" icon="heart-pulse" href="/api-reference/health/get-api-health">
    Check API status directly, for example from a status page or monitor.
  </Card>

  <Card title="Audit" icon="terminal" href="/dashboard/audit">
    The full, filterable audit trail across cases, imports, and admin actions.
  </Card>
</CardGroup>