# Use the API Explorer

The [API Explorer](/api-explorer) sends requests to Apideck from your browser through the documentation site's server. Use it to check a connection, inspect a response, and work out which parameters your integration needs before writing code.

Requests use your connected account. Creating, updating, or deleting records changes data in that account. Start with a read request and use a test connection when experimenting with writes.

## Before you start

Follow [Get started](/get-started) to create an application and connect a consumer through Vault. Have these values ready:

| Value | What to use |
| --- | --- |
| API key | Your Apideck application API key, not the connector's access token. |
| Application ID | The application that owns the API key and connection. |
| Consumer ID | The same consumer ID used when connecting the account in Vault. |
| Service ID | The connector to call, such as `xero` or `quickbooks`. Set it explicitly when choosing between connections. |

You can also open the Explorer from the [Apideck dashboard](https://platform.apideck.com) with temporary credentials. If the Authorization section says it is using temporary credentials, leave that mode enabled for the session. From [Make your first API call](/first-api-call), choose **Try this read in Explorer** in the same browser tab to reuse those credentials and select the API, operation and connector. Review the consumer and connection before clicking Run; opening Explorer does not send a request. If the temporary session has expired, reopen Explorer from the dashboard. Standalone SDK and cURL examples still require your own API key.

## Make your first request

Open **Try in explorer** from the endpoint you want to call. The link selects its API and operation and carries the connector and use case when available. The walkthrough below uses Accounting invoices; the [first-call workspace](/first-api-call) also provides CRM contacts, HRIS employees, and Ecommerce orders.

1. Open the [Accounting API Explorer](/apis/accounting/api-explorer?operation=invoicesAll).
2. Choose **Accounting** and the **GET List invoices** endpoint. The endpoint selector supports searching by endpoint name and path.
3. In **Authorization**, keep temporary credentials enabled if present. Otherwise, paste the API key without the `Bearer ` prefix; the Explorer adds it.
4. Under **Headers**, set `x-apideck-app-id`, `x-apideck-consumer-id`, and `x-apideck-service-id` to the values for your connection.
5. Leave optional filters empty for the first request. If a `limit` field is available, use a small page size, such as `10`.
6. Review the request preview and click **Run Request** (or **Run** on narrower desktop layouts).

The Explorer remembers your API and endpoint selections. Header values are stored in browser session storage so you do not need to re-enter them for every request. Treat screenshots of the request preview as sensitive: they can include credentials and customer identifiers.

## Inspect the response

The response panel shows the HTTP status, request method and path, elapsed time, body size, and content type. Timing includes the documentation site's proxy and network travel; it is not a measurement of the connector's processing time alone. Body size measures the decoded UTF-8 response, not compressed network transfer size.

Use **Formatted** to read JSON or XML, **Raw** to inspect the body before Explorer formatting, and **Copy response** to copy the selected view. Raw here means the body received by the Explorer; it does not enable Apideck's [downstream raw mode](/guides/using-raw-mode).

For a successful invoice list, inspect `data` for records. An empty list can be a valid response: check the connected company, filters, and available records before treating it as a failure. One page is not a complete sync. Consult the [invoice reference](/apis/accounting/reference/invoices/invoicesAll) for pagination parameters and response metadata.

## Change parameters and request bodies

Select a different endpoint to see its parameters and, when applicable, its request body editor. Path parameters identify a specific record; query parameters filter or paginate a list. Required fields are marked in the form.

For writes, use IDs returned by the same connection. Check [connector coverage](/apis/accounting/coverage) before assuming that a connector supports an operation or field. A field appearing in the unified schema does not guarantee that every connector supports it.

File operations show a file picker when the endpoint accepts an upload. Follow the [file upload guide](/guides/file-upload) for the relevant endpoint and prerequisites.

## Trace downstream calls

The Explorer shows the Unified API response. To inspect the requests Apideck sent to the connector, open the corresponding parent request in [Logs and follow its child requests](/logs#follow-parent-and-child-requests). Compare the child response with the normalized result to investigate [field mapping](/logs#compare-downstream-data-with-the-unified-model). The Explorer’s Raw tab only changes response formatting.

## Troubleshoot a request

| Symptom | What to check next |
| --- | --- |
| The linked operation is unavailable | Check the selected API, then choose an endpoint or follow the reference link. Explorer leaves Run disabled until you choose; it does not substitute another operation. |
| Endpoints could not be loaded | Use **Retry loading endpoints** or choose another API. A specification-loading error does not mean your connector request failed; no connector request has been sent. |
| `400` or `422` | Read the response details, then check required parameters, field types, and request body. |
| `401` or `403` | Check credentials and application access. For a downstream authorization error, check the connection and permissions in Vault. |
| `404` | Check the resource ID and whether it belongs to the selected consumer and connector. |
| `429` | Consult the [rate-limit guide](/guides/unified-rate-limits) and avoid repeatedly clicking Run. |
| `5xx` | Inspect the error details and [API logs](/logs) to identify whether the failure came from Apideck or the connected provider. |
| JSON could not be parsed | The original response body remains visible. Inspect it for an upstream or proxy error. |
| No response could be read | Check your connection and API logs. A write may have reached the provider even if its response did not reach the Explorer; verify its outcome before retrying. |

Use [API Logs](/logs) to investigate requests across your integration. The Explorer's response panel is a view of the current request, not a saved request history.

## Use Postman or Insomnia

Prefer a desktop API client? Open **Developer tools → View OpenAPI spec (YAML)** from your API reference and copy the specification URL. The [OpenAPI repository](https://github.com/apideck-libraries/openapi-specs) contains the specifications for all APIs.

- **Postman:** [import the specification URL](https://learning.postman.com/docs/integrations/available-integrations/working-with-openAPI/) and generate a request collection.
- **Insomnia:** choose **Import → URL** and paste the specification URL. See the [Insomnia import guide](https://developer.konghq.com/insomnia/import-export/).

Importing a specification creates request definitions; it does not connect a customer or supply credentials. Configure the API key and the `x-apideck-app-id`, `x-apideck-consumer-id`, and `x-apideck-service-id` headers for your connection. Start with a read request and keep credentials out of shared collections and exports.

## Move into your application

Once the request behaves as expected, use the endpoint's [API reference](/apis/accounting/reference) and an [official SDK](/sdks) to implement it server-side. Keep API keys out of frontend application code. Add pagination, error handling, and a consumer ID for each customer before turning an Explorer experiment into a production integration.

For a runnable read with Accounting, CRM, HRIS, or Ecommerce, continue with [Make your first API call](/first-api-call).

For a complete example, [investigate a failed request](/guides/investigate-failed-request) from parent/child evidence to a verified recovery.

## Frequently asked questions

### Does the API Explorer use sample data or my connected account?

The API Explorer sends real requests using the credentials and connection you select. A create, update, or delete operation can change that account’s data. Start with a read and use a test connection for writes. The [guided playground](/playground) is a separate simulation.

### Why does a successful list request return no records?

An empty list can be valid. Check that the consumer, connector, company and filters match the records you expect, then verify visibility with a known record in the source system. Do not treat an empty result alone as proof of failed authentication. See [Inspect the response](#inspect-the-response).

### Can I share an Explorer link containing credentials?

Do not share credential-bearing URLs, request previews, or exports. Share an endpoint’s reference URL and have each teammate authorize their own Explorer session. The Explorer can retain header values in browser session storage; that does not make them suitable for sharing.

### Should I rerun a write if the Explorer receives no response?

First determine whether the write succeeded. Inspect [API Logs](/logs) and read back the affected record where possible. A lost response does not prove the provider rejected the request; repeating it may create a duplicate. See [Troubleshoot a request](#troubleshoot-a-request).