> For the complete documentation index, see [llms.txt](https://docs.nullify.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nullify.ai/configuration/configuration-api.md).

# API Configuration

## Overview

Dynamic Application Security Testing (DAST) produces API findings by testing your running applications. Manage applications, targets, and credentials from the Nullify dashboard or through the API — there is no config file checked into your repository.

A pentest runs against an application's resolved context. Start one with `POST /dast/pentest/start` (body `{"applicationId":"<id>","configOverrides":{...}}`; `applicationId` is required) and review results with `GET /dast/pentest/scans/{scanId}/findings`. Lighter bug-hunt scans run at `low`, `medium`, or `high` intensity via `GET,POST /dast/bughunt/scans`.

When you run a pentest with the [CLI](/capabilities/pentests/engagement-workflow.md#cli), you can supply multi-role authentication as a local file with `--auth-config`. That file is a CLI input, not a checked-in platform config — the dashboard remains the source of truth for stored applications and credentials.

## Service account tokens

CLI and API access outside a browser session uses a service-account token. Manage service accounts through the admin API — `GET`, `POST`, and `DELETE` on `/admin/service_accounts` — which requires the **Admin** role. Creation accepts one built-in role: `builtin:viewer`, `builtin:editor`, or `builtin:admin`. It does not accept individual permission grants; omitting `role` defaults to `builtin:admin`.

Choose the least-privileged built-in role that covers the task:

| Task                                                       | Minimum role     |
| ---------------------------------------------------------- | ---------------- |
| Start or stop a scan, allowlist a finding, create a ticket | `builtin:editor` |
| Read scans, findings, and reports                          | `builtin:viewer` |
| Create or update applications and credentials              | `builtin:admin`  |
| Read stored credentials                                    | `builtin:admin`  |

Pass the token as `NULLIFY_TOKEN` in the environment, or with `--nullify-token`.

## Credentials

Credentials are stored per tenant, encrypted at rest, and returned masked. Manage them with:

```
GET    /dast/credentials
POST   /dast/credentials
PUT    /dast/credentials/{credentialId}
DELETE /dast/credentials/{credentialId}
POST   /dast/credentials/{credentialId}/validate
```

Validate a credential before using it in an engagement. A pentest stops at the login stage if any attached credential fails to authenticate.

## Source IP addresses

Pentest and exploit-validation traffic originates from a static set of IPs for your tenant's region. Retrieve them and allowlist them on any WAF or gateway in front of your targets:

```
GET /dast/sourceips
```

## Ignore findings

Suppress an API finding by allowlisting it per-finding from the dashboard or via the API, e.g. for a pentest finding:

```
POST /dast/pentest/findings/{findingId}/allowlist
```

Request body:

```json
{
  "allowlistReason": "Endpoint is internal-only and not reachable in production",
  "allowlistType": "UserAssumeRisk"
}
```

`allowlistType` is one of `AI`, `UserFixed`, `UserAssumeRisk`, `UserFalsePositive`, or `UserOther`.

## Pull request gate and notifications

Whether findings fail CI and where alerts are delivered is managed centrally — see [Configuration – General](/configuration/configuration-general.md) for the **Configure → Pull Requests** and **Configure → Notifications** settings.