# API Playground

Source: https://neondeerdata.com/docs/api/testing/

Send a request, view the response, and copy the code.

## Open the Playground

In **Settings → Integrations**, select a key and open **Playground**. You need an organization admin account. The available API families and operations depend on the organization's access and the key's saved permissions.

Choose **Who am I** to inspect the key and organization. Then select the API family and operation you want to test. For a lookup-table example, follow [Test lookup-table requests](https://neondeerdata.com/docs/api/lookup-tables/testing/).

## Enter the request

Fill in the IDs and parameters shown for the selected operation. Where a **Request body** editor is offered, enter the JSON object the operation expects. The body is sent as written. Other operations provide dedicated field and value controls.

Read the resource first when a write requires its current version, plan revision, workflow version, or ownership details. Use the exact values returned by that read. The [endpoint reference](https://neondeerdata.com/docs/api/) describes the required inputs; [writes, versions, and retries](https://neondeerdata.com/docs/api/requests/) explains how to handle changes between requests.

Check **Generated request** before choosing **Send request**. It shows the request the Playground will send, including inputs derived from the form.

## Send reads and writes

Start with a read of the resource you intend to use. When testing a write, use disposable data and check its effect before sending. Depending on the operation, a request can change lookup rows or settings, start a real Attio workflow, register or contact a webhook receiver, cancel work, or merge CRM records.

A sample response labeled **Example** has not changed anything. **Send request** runs the selected operation against the actual organization with the key's saved access. Confirmation behavior varies by operation; do not rely on an extra prompt before every write.

For work accepted in the background, follow the returned operation or status resource until it finishes. An accepted request is not confirmation that every item succeeded. Inspect each outcome before trying failed or uncertain work again.

## Read the response

After **Send request**, the panel shows the actual HTTP status, response, and time taken. Changing the operation or inputs replaces the previous result with an example. Send the changed request to get new results.

Where offered, switch between **JSON** and **Table**; **Copy** copies JSON. An error response may identify a parameter to correct and a request ID for support. See [errors](https://neondeerdata.com/docs/api/errors/) and [rate limits](https://neondeerdata.com/docs/api/rate-limits/).

Webhook creation and signing-secret rotation can return a secret in the response. Store it securely before leaving the result, and do not share that response in a conversation or screenshot.

## Copy a code sample

**Generated request** provides **cURL**, **JavaScript**, and **Python** examples. On a narrow screen, choose **View generated code** to show them. Set `NEON_DEER_API_KEY` securely on your server before using a copied sample.

The Playground uses your admin session with the key's saved permissions. It does not send your application's secret or count against the key's request allowance. To verify the credential your application actually uses, send [Who am I](https://neondeerdata.com/docs/api/meta/self/) from that application. The Playground identifies the newest working secret, which may differ from one still configured on your server.

## Check the behavior your integration needs

Test a successful read, a key with restricted access, a permitted write, and a stale-version response where relevant. Then check the API family's specific outcomes:

- **Lookup tables:** compare matches with the table, query empty cells, read every page, and inspect each add-or-update result. See the [lookup-table walkthrough](https://neondeerdata.com/docs/api/lookup-tables/testing/).
- **Duplicate Detection:** inspect the configuration and scan selection, follow scan or assessment operations, and read a merge or recovery plan before executing it.
- **Scheduled runs:** read the current workflow version, check the batch's scheduled time and time zone, and verify that cancellation affects only pending work.
- **Email Notifications:** compare delivery activity and settings, then inspect the result of permitted settings changes or waiting-alert cancellation. Delivery reports are not read receipts.
- **Webhooks:** test verification and signature handling on a receiver you control, including repeated deliveries. A verification or replay request can send traffic to that receiver.

Use the operation's own filter and pagination schema. Lookup-row conditions, duplicate-set filters, and scan selections are different formats; the lookup query builder is not a universal filter editor.