Application Setup

New applications use a multi-step setup wizard. Existing applications reopen in the application editor, where you can maintain the same setup. Completed, continued, and saved steps persist so you can return later when a blocker needs another team. Cancel exits without saving unsaved edits on the current step.

The wizard shows the steps that apply to the application and selected testing. Its visible order is:

1. Basics
2. AI provider, when your organization AI or BYOK setup requires it
3. Access & login
4. Test identities, only when authenticated testing is enabled
5. Optional inputs
6. Review

Steps are conditional. Follow the steps and fields shown in the UI; not every application sees every step.

#BasicsCopy link

Enter the application name and App URL. API URL is optional: if it is blank, Tahr uses the App URL when an assessment needs an API target. Add an API URL when the API is hosted at a different origin. Use URLs that represent the real assessment scope. Tahr checks that each hostname is allowed by your organization before an assessment can run.

If the target sits behind a WAF, firewall, or IP allowlist, answer Do you have a WAF?. Configure or prepare a reserved IP only if assessment traffic must be allowlisted or Tahr requires one. See Reserved IPs for the organization-level operation. Use a staging, test, preproduction, or other dedicated non-production target; review the Security Notices before continuing.

Add testing context only when it helps the selected assessment: important workflows, out-of-scope areas, role or tenant boundaries, unusual behavior, and actions to avoid. Never put passwords, API keys, recovery codes, or other secrets in free-text fields.

#Access & loginCopy link

Enable authenticated testing only when protected functionality is in scope. Add the full public HTTP(S) Login URL and an Authentication Check URL on the configured application or API origin that returns user-specific data. Authenticated Testing is canonical for login flows, roles, tenants, ownership boundaries, second factors, SSO accounts, and sign-in automation; do not duplicate those procedures here.

#Test identitiesCopy link

When authenticated testing is enabled, add the required test identities. Use the identities, roles, tenants, and ownership boundaries that the assessment is authorized to exercise.

#Optional inputsCopy link

Configure only the optional inputs required by the assessment. For private source review, choose Repository access, select the connected provider integration, then enter the Repository URL and Branch. Leave the default branch unless another branch is in scope. Provider connection and repository browsing are documented in Integrations.

For API-focused testing, add an API file: use an OpenAPI definition for REST or a GraphQL schema or introspection artifact for GraphQL. Custom HTTP headers may supply an approved staging or tracking header; do not use free-text fields for long-lived secrets. GitLab targets may also require provider-specific custom headers in the integration setup.

#Android Pentest prerequisitesCopy link

Select the APK option only when Android Pentest is in scope. Readiness requires APK support, an uploaded non-empty APK, and an application URL. Upload the artifact in the application flow and resolve the blocker shown by Tahr before launch.

iOS application testing is not currently supported.

#Application documentsCopy link

When the document area is available, save the application draft and choose Upload. Supported formats include PDF, Markdown, text, DOCX, JSON, YAML, and PNG or JPEG images. Documents are optional context for eligible workflows, especially Threat Modeling; do not imply that every assessment reads them or that an upload changes all assessment types.

If a workflow needs a repository, ticketing destination, or another provider, connect it through Integrations. Application setup should contain the application-level URL, branch, file, header, and context choices, not provider connection procedures.

For every optional input, check that it belongs to the intended application and environment. A repository from the wrong product or a schema from another API can make otherwise valid results misleading. Use the same branch, API definition, headers, and test identities that the assessment is authorized to exercise, and remove stale artifacts when the target changes.

#Readiness blockersCopy link

Tahr lists the blockers that apply to the selected setup. Common examples are:

• The application or API domain is missing, pending, or outside the verified scope.
• Private repository access, the repository URL, or the selected branch is missing.
• An API definition required by the selected workflow is missing or invalid.
• Authenticated testing is enabled without a login URL, user-specific Authentication Check URL, or required test identity.
• Roles, tenants, ownership details, or second-factor setup are incomplete for authorization testing.
• Android Pentest is selected without APK support, a non-empty uploaded APK, or an application URL.
• Threat Modeling is selected without the repository access it needs.

Resolve blockers from top to bottom because later checks can depend on earlier choices. For a domain blocker, verify the hostname, organization domain entry, DNS status, and any WAF or reserved IP requirement. For a conditional input, configure it only when the chosen assessment needs it.

Some blockers are deliberately conditional. A public unauthenticated assessment may not need login users, while an authenticated authorization assessment may need several roles and tenants. Similarly, an API file, repository, APK, or document is relevant only when its selected workflow supports or requires it. Do not bypass a blocker by adding unrelated data; correct the input or change the assessment scope intentionally.

#ReviewCopy link

The review step summarizes the target, access, authentication, and conditional inputs. If blockers remain, Tahr saves the application as a draft. If none remain, Tahr marks it ready for eligible assessments; readiness does not mean every assessment type is configured.

Before finishing, confirm the scope, credentials, repository branch, API artifact, and test-user boundaries. Tahr's readiness status is the source of truth: follow the blockers it lists instead of assuming that every setup item applies to every workflow.