Instantly API Contract CI

Overview

Build a CI lane that catches request, scope, pagination, and response-shape drift before deployment. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• API keys are bearer tokens with endpoint-specific scopes.
• Default workspace limits are 100 requests per second and 6,000 per minute; endpoint overrides still apply.
• Live CI probes must use a non-production workspace and read-only scopes.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Inventory every Instantly call and map it to an API v2 operation and required scope.
2. Validate request fixtures offline against pinned OpenAPI-derived types.
3. Test 401, 403, 429, pagination, timeout, and redaction behavior.
4. Permit one bounded staging list request only when CI secrets and owner approval exist.
5. Fail on schema drift, secret output, unbounded pagination, or mutation attempts.
6. Publish the tested SDK/CLI version, fixtures, and rollback owner.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and contracts inspected, exact API v2 routes and required scopes, evidence collected, validation result, sensitive fields reda…

Instantly API Error Triage

Overview

Turn an observed failure into a bounded diagnosis and a verified corrective action. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• 401 means missing, invalid, or revoked authorization; 403 means the key lacks a required scope.
• 429 is workspace-wide unless the endpoint publishes a stricter override.
• API errors expose statusCode, error, and message; do not infer success from a JSON body alone.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Capture the method, route template, status, request ID, and redacted response shape.
2. Separate authentication, authorization, payment, validation, absence, conflict, and throttling failures.
3. Check the live endpoint reference and exact required scope.
4. Reproduce with a synthetic read-only request where possible.
5. Apply the smallest configuration or code correction.
6. Record evidence and stop before any destructive retry.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and contracts inspected, exact API v2 routes and required scopes, evidence collected, validation result, sensitive fields redacted, remaining risk, accou…

Governed Instantly Campaign Launch

Overview

Create a campaign from reviewed inputs, load approved leads, validate sending state, and require explicit activation approval. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• Campaigns use REST API v2 resources and scoped keys.
• Lead listing is POST /leads/list because filters are complex; bulk lead addition supports at most 1,000 leads per request.
• Campaign activation is a separate mutation and must not be implicit in creation.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Read the campaign specification, consent basis, suppression rules, sending accounts, schedule, and rollback owner.
2. Resolve workspace identity and use campaigns/leads scopes no broader than required.
3. Create or patch a draft campaign with bounded sequences and approved variables.
4. Import a small deduplicated synthetic or approved lead cohort and inspect rejected rows.
5. Validate campaign sending status, account health, schedule, and compliance gates.
6. Present the exact activation action and execute it only after explicit approval.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, fil…

Instantly Sending Account Onboarding

Overview

Onboard Google or Microsoft sending accounts without exposing credentials or assigning unhealthy accounts to live campaigns. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• Google and Microsoft connections use an OAuth session URL followed by status polling.
• OAuth sessions expire after 10 minutes.
• Warmup enablement may return a background job that must be polled.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Confirm account ownership, provider, workspace, allowed domains, and change owner.
2. Create a least-privilege OAuth session and give the authorization URL only to the account owner.
3. Poll the session within its expiry window without logging tokens.
4. Test account vitals and capture only non-sensitive status fields.
5. Enable warmup or campaign assignment only after an explicit change approval.
6. Poll background jobs and produce per-account success and failure evidence.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and contracts inspected, exact API v2 routes and required scopes, evidence collected, validation result, sensitive fields redact…

Instantly Cost and Capacity Governance

Overview

Produce an evidence-backed capacity and spend recommendation using live workspace billing and pricing sources. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• Pricing and entitlements are dynamic; never hard-code a monthly price or account allowance.
• Workspace billing endpoints require workspace_billing read scope.
• Some endpoints publish independent limits or credit costs, so general API throughput is not a spend model.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Define the billing period, business outcome, sending-account inventory, and cost owner.
2. Read current plan and subscription details with read-only billing scope when available.
3. Measure active versus idle accounts, campaign outcomes, verification, and enrichment consumption.
4. Fetch current first-party pricing and contract terms before making a recommendation.
5. Model keep, consolidate, and expand options with assumptions and sensitivity ranges.
6. Require owner approval for plan, account, domain, or paid-enrichment changes.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and contra…

Instantly Lead Data Governance

Overview

Map and constrain personal-data movement across lead ingestion, campaigns, webhooks, exports, logs, and deletion. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• Lead payload values may be scalar values; nested arrays are not a safe assumed contract.
• Webhook payloads can contain lead and full reply/email content.
• Deletion and export behavior must be tied to customer policy and signed terms, not generic assumptions.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Classify every input field, purpose, legal basis, retention owner, and downstream destination.
2. Map create, list, patch, export, webhook, and delete paths with exact scopes.
3. Minimize payloads and apply blocklist, consent, suppression, and deduplication controls before import.
4. Redact email bodies, reply text, API keys, and personal identifiers from logs and evidence.
5. Test access, correction, suppression, export, and deletion with synthetic records.
6. Require privacy and data-owner approval before production retention or deletion changes.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and c…

Redacted Instantly Diagnostic Bundle

Overview

Gather reproducible operational evidence without exporting credentials, lead data, or message bodies. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• Use documented list, sending-status, vitals, background-job, and webhook-event aggregates.
• Raw lead, email, and webhook payloads may contain personal or message content.
• Support sharing is an external disclosure that needs owner review.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Define the failing operation, time window, workspace, incident owner, and evidence destination.
2. Collect client version, route templates, statuses, request IDs, and timestamps.
3. Query only aggregate campaign, account, job, and webhook health needed for the incident.
4. Replace workspace, campaign, account, lead, and email identifiers with stable opaque labels.
5. Scan the bundle for bearer tokens, addresses, message text, and unrestricted environment output.
6. Present the manifest and obtain approval before transmitting it outside the team.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and contracts inspected, exact API…

Deploy an Instantly Integration

Overview

Promote a tested integration while separating deploy approval from campaign, account, and webhook mutations. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• API keys belong in server-side secret storage and require least-privilege scopes.
• The official SDK is beta and requires Node.js 22 or later; the CLI requires Node.js 18 or later.
• Deployment success does not authorize campaign activation or webhook replacement.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Pin runtime, official SDK or CLI version, OpenAPI assumptions, and release SHA.
2. Provision an environment-specific key through the approved secret manager.
3. Run offline contract tests and a read-only staging smoke test.
4. Deploy with health checks, bounded concurrency, and redacted logs.
5. Verify workspace identity, account/campaign reads, and webhook receiver health.
6. Record rollback criteria and seek separate approval for production data-plane mutations.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and contracts inspected, exact API v2 routes and required scopes, evidence collected, valid…

Instantly Workspace Access Governance

Overview

Review and change access with least privilege, explicit ownership, and tenant-boundary evidence. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• API v2 keys support granular resource/action scopes and can be revoked.
• Workspace groups let an admin key act for a sub-workspace through x-as-workspace.
• Only owners/admins can manage group membership, and only owners can leave a group.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Inventory members, roles, API keys, scopes, service owners, and last-use evidence.
2. Map each automation to the narrowest read/create/update/delete scope set.
3. Review audit logs and flag orphaned, broad, shared, or cross-workspace credentials.
4. For sub-workspace actions, validate the target ID and x-as-workspace header before execution.
5. Prepare member/key/group changes as a reviewed change set.
6. Apply only approved changes and verify both intended access and denied cross-tenant access.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and contracts inspected, exact API v2 routes and required scopes, evidence collected, val…

Instantly Bounded First Request

Overview

Prove a new Instantly integration with the smallest safe request and a redacted evidence handoff. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• The API v2 base URL is https://api.instantly.ai/api/v2.
• Authorization uses an API v2 key as a Bearer token.
• A 401, 403, or 429 must fail the smoke test rather than trigger mutation or broad retries.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Confirm the target workspace and create a read-only key with accounts:read or campaigns:read.
2. Store the key in a server-side environment variable and never print it.
3. Send one list request with a limit no greater than five.
4. Validate HTTP status and expected collection/pagination fields.
5. Capture latency, status, route template, and redacted item count.
6. Stop after the proof; do not create, patch, activate, or delete resources.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and contracts inspected, exact API v2 routes and required scopes, evidence collected, validation result, sensitive fields redacted, remaining risk, accountable owner, approval state, and rol…

Instantly Incident Response

Overview

Contain a production incident while preserving evidence, tenant boundaries, and reversible recovery actions. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• Campaign pause, account pause, webhook resume, and key revocation are state-changing actions.
• Sending-status, account vitals, background jobs, and webhook aggregates provide documented evidence surfaces.
• Workspace-wide 429s require coordinated throttling across every key.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Declare severity, affected workspace, owner, time window, and customer impact.
2. Preserve redacted request IDs, statuses, deploy SHA, campaign state, and aggregate health.
3. Classify identity, scope, quota, sending, account, job, webhook, or provider failure.
4. Propose the smallest containment action with blast radius and rollback.
5. Execute pause, resume, revoke, or rollback only after incident-owner approval unless a pre-approved runbook applies.
6. Verify recovery, monitor recurrence, and record follow-up ownership.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and contracts inspected…

Install and Authenticate Instantly Tooling

Overview

Establish a reproducible server-side client without leaking a key or granting unnecessary scopes. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• The official TypeScript SDK is @instantlyai/sdk beta and requires Node.js 22 or later.
• The official CLI is @instantlyai/cli and supports INSTANTLY_API_KEY for non-interactive use.
• API v2 keys are displayed once and are not compatible with API v1.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Inspect the repository runtime, package manager, lockfile, and existing Instantly client.
2. Choose HTTP, SDK, or CLI deliberately and verify current first-party installation guidance.
3. Pin a compatible version; use the SDK beta tag only while the first-party docs require it.
4. Create a key with only the exact endpoint scopes and store it in an approved secret manager.
5. Verify with one bounded read-only request and distinguish 401 from 403.
6. Record versions, workspace identity, scopes, evidence, rotation owner, and rollback.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and contracts inspected, exact API v…

Instantly Local Contract Loop

Overview

Develop safely without relying on an undocumented vendor mock endpoint or sending real outreach. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• The documentation exposes interactive examples but does not establish a durable public mock API contract.
• Use local fakes and captured synthetic schemas for deterministic tests.
• Live probes require a staging workspace, read-only scopes, and bounded requests.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Inventory routes and generate or pin types from the official OpenAPI surface.
2. Create local fake responses for success, 401, 403, 429, pagination, and malformed data.
3. Use synthetic leads and messages; never copy production payloads into fixtures.
4. Run unit and contract tests without network access.
5. Optionally run one owner-approved read-only staging probe.
6. Update fixtures only after reviewed schema evidence and record the source date.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and contracts inspected, exact API v2 routes and required scopes, evidence collected, validation result, sensitive fields re…

Instantly API v1-to-v2 Cutover

Overview

Move a production integration from deprecated API v1 to incompatible API v2 without silent behavior drift. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• API v1 was deprecated on January 19, 2026; new integrations use API v2.
• API v2 needs a new scoped bearer key and is not compatible with v1 keys.
• Methods, paths, field naming, pagination, and several asynchronous operations changed.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Inventory every v1 endpoint, key, consumer, schedule, owner, and failure policy.
2. Map each call to the official migration table and required v2 scope.
3. Build v2 request/response contract tests for methods, snake_case fields, cursors, and background jobs.
4. Issue separate v2 keys and dual-read only where privacy and consistency controls allow it.
5. Canary one workflow, compare outcomes, then cut over consumers in bounded phases.
6. Retire v1 credentials only after rollback expiry and verified v2 stability.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and contracts inspected, exact API v2 routes and required scopes, evidence …

Instantly Multi-Environment Isolation

Overview

Design environment isolation and promotion without fake vendor endpoints or accidental cross-workspace mutations. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• Use separate workspaces and keys where isolation requirements demand it.
• Workspace-group delegation uses x-as-workspace and increases cross-tenant risk.
• Environment names are not proof of identity; validate opaque workspace IDs and read-only probes.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Document environment-to-workspace IDs, owners, scopes, data classes, domains, and webhook URLs.
2. Use local fakes for development and synthetic records for staging.
3. Store one scoped key reference per environment; never use fallback production credentials.
4. Add startup guards that compare the expected opaque workspace ID before mutation.
5. Promote code and schemas separately from campaigns, leads, accounts, or webhooks.
6. Test denied cross-environment access and maintain a credential and webhook rollback plan.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and contracts inspected, exact API v2…

Instantly Integration Observability

Overview

Define actionable service signals without logging lead content, email bodies, or credentials. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• Use campaign sending-status rather than inferring health from aggregate counts alone.
• Webhook event aggregate endpoints expose success/failure evidence.
• Workspace-wide rate limits require shared client telemetry across keys.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Define service-level indicators for request success, latency, 429s, job age, sending state, and webhook failures.
2. Instrument route templates, status classes, retry counts, request IDs, and workspace-safe labels.
3. Poll documented health and aggregate endpoints at a bounded cadence.
4. Redact API keys, addresses, lead payloads, reply content, and email bodies.
5. Set alerts against measured baselines with owner-reviewed thresholds.
6. Link each alert to diagnosis, containment approval, and rollback steps.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and contracts inspected, exact API v2 routes and required scopes, evidence collected, validat…

Instantly Throughput Engineering

Overview

Increase throughput without violating workspace or endpoint-specific limits or duplicating mutations. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• The general ceiling is 100 requests per second and 6,000 per minute per workspace across v1/v2 and keys.
• Endpoint-specific limits override the general ceiling.
• Bulk lead addition accepts up to 1,000 leads per request; asynchronous jobs require polling.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Measure route mix, payload sizes, current latency, 429s, and shared workspace traffic.
2. Classify reads, idempotent writes, non-idempotent writes, bulk operations, and background jobs.
3. Implement a workspace-wide token bucket below both general ceilings.
4. Honor endpoint overrides, jitter retryable reads, and never blindly retry non-idempotent mutations.
5. Use cursor pagination and documented bulk endpoints with bounded page/job polling.
6. Load-test synthetic staging data and publish before/after evidence plus rollback thresholds.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and contracts inspected, exact …

Instantly Production Readiness Gate

Overview

Return a fail-closed readiness decision backed by test and approval evidence. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• A green deploy is not authorization to activate campaigns or connect accounts.
• Keys, workspace-group delegation, webhook delivery, background jobs, and endpoint limits need explicit owners.
• Dynamic plan and entitlement facts must be rechecked at launch.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Verify release SHA, runtime, SDK/CLI pins, schema source, and rollback artifact.
2. Verify workspace identity, least-privilege keys, rotation, audit, and secret storage.
3. Verify consent, suppression, minimization, redaction, retention, and deletion controls.
4. Verify workspace and endpoint limits, pagination, batching, idempotency, and job polling.
5. Verify dashboards, alerts, incident runbook, webhook recovery, and support evidence.
6. List every unresolved gate and require accountable approval for launch and each data-plane mutation.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and contracts inspected, exact API v2 routes and…

Instantly Workspace Rate Control

Overview

Coordinate traffic across clients and keys so retries do not amplify throttling or duplicate writes. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• General limits are 100 requests per second and 6,000 per minute across API v1/v2 for the whole workspace.
• GET /emails is limited to 20 requests per minute; other endpoints may publish independent limits.
• 429 is the authoritative throttling signal; retry timing must follow documented or observed response metadata.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Inventory every producer sharing the workspace and every endpoint-specific override.
2. Allocate a workspace request budget below both general windows.
3. Centralize token-bucket state and expose queue depth, wait time, and 429 telemetry.
4. Retry only operations proven safe, with bounded exponential backoff and jitter.
5. Do not assume a webhook retry count or timing absent a published contract.
6. Test burst, sustained, override, and retry-storm scenarios with synthetic traffic.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and contracts inspected, ex…

Instantly Integration Reference Architecture

Overview

Produce a repo-grounded architecture that separates control-plane approvals from outreach mutations. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• Use official API v2, the beta TypeScript SDK when appropriate, or the official CLI/MCP deliberately.
• Model workspace-wide throttling, cursor pagination, background jobs, and webhook delivery as first-class components.
• Keep campaign activation, account connection, key changes, and data deletion behind separate approvals.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Map callers, workspaces, data stores, queues, secret managers, webhook receivers, and owners.
2. Define a typed client boundary with scoped authentication, redaction, timeouts, and rate control.
3. Separate read models, command handlers, background-job polling, and webhook idempotency.
4. Define tenant/workspace identity checks and x-as-workspace safeguards.
5. Trace lead and email data through retention, suppression, audit, and deletion controls.
6. Deliver topology, failure paths, capacity assumptions, approval boundaries, and rollback.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Ou…

Instantly Official SDK Patterns

Overview

Adopt @instantlyai/sdk without inventing resource methods or hiding HTTP failure semantics. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• The official package is @instantlyai/sdk and remains beta before stable 1.0.0.
• The SDK requires Node.js 22 or later and throws ResponseError for non-success responses.
• Resource coverage is generated from the OpenAPI schema and may evolve during beta.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Inspect runtime and lockfile compatibility before installing the beta package.
2. Confirm the current beta version and pin the resolved lockfile.
3. Create Instantly with a server-side apiKey and no browser exposure.
4. Use generated resource methods and request types that exist in the installed version.
5. Handle ResponseError by status while redacting response bodies and authorization.
6. Add contract tests and a deliberate upgrade review for every beta change.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and contracts inspected, exact API v2 routes and required scopes, evidence collected, validation result, sensitive fiel…

Instantly Integration Security Baseline

Overview

Produce a verified security baseline with least privilege and explicit remediation approvals. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• Keys are bearer credentials displayed once; store them only in approved server-side secret systems.
• Scopes can be resource/action-specific and revoked through API-key controls.
• Webhook payloads can contain sensitive lead and message content; the public guide does not establish a signature secret.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Inventory secrets, scopes, members, service identities, workspace-group delegation, and webhook destinations.
2. Remove browser exposure, query-string keys, plaintext configs, and unrestricted environment logging.
3. Map each call to least-privilege scopes and validate denied operations.
4. Enforce TLS, request-size bounds, schema validation, idempotency, and payload minimization at webhook receivers.
5. Review audit logs and establish key rotation/revocation and incident ownership.
6. Prepare changes with blast radius, approval, verification, and rollback evidence.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Upgrade Instantly SDK and API Contracts

Overview

Handle ongoing tooling and schema evolution separately from the one-time API v1 cutover. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• The TypeScript SDK is beta and may receive refinements before stable 1.0.0.
• The CLI and SDK have different Node.js minimums and release cadences.
• Generated resources follow the live OpenAPI schema; method availability must be checked in the installed version.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Inventory current runtime, package pins, generated types, routes, fixtures, and consumers.
2. Read first-party release/package metadata and classify breaking, additive, and behavioral changes.
3. Update one component in an isolated branch and retain the previous lockfile for rollback.
4. Run offline type, contract, error, pagination, and redaction tests.
5. Canary a bounded read-only staging operation.
6. Promote only after owner review; record resolved versions, evidence, and rollback trigger.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and contracts inspected, exact API v2 routes and required scopes, evidenc…

Instantly Webhook Operations

Overview

Build a receiver for documented Instantly event types without assuming an unpublished signature or retry contract. Record assumptions, evidence, approval state, and rollback ownership so another operator can reproduce the result.

Prerequisites

• The target repository, Instantly workspace, environment, and accountable owner
• Current security, privacy, compliance, capacity, and change-control requirements
• An approved API v2 key only when a bounded live verification is necessary

Tool Discipline

Use Read, Glob, and Grep to inspect code, configuration, and evidence. Use WebFetch only for current first-party Instantly documentation and package metadata. Use Write or Edit only when implementation was requested and exact target files are known; never write credentials, lead data, email content, or unrestricted environment output.

Current Contract

• Events include workspace, campaign, timestamp, event_type, and optional lead/email/reply content.
• Custom labels may arrive as event_type values.
• The API supports list, create, patch, delete, test, resume, event-type discovery, and delivery-event observability.

Authentication

Use an API v2 key as Authorization: Bearer <key> against https://api.instantly.ai/api/v2. Grant only the endpoint-specific scopes needed, inject the key from an approved server-side secret manager, and never print, persist, commit, or place it in a URL. Treat key creation, rotation, revocation, member changes, workspace delegation, and production access as owner-approved actions.

Instructions

1. Fetch the live event-type list and select only required events.
2. Review the HTTPS destination, data classification, retention, and receiver owner.
3. Create the webhook with the exact documented fields and least-privilege scope.
4. Validate schema, workspace identity, timestamp bounds, payload size, and event-specific optional fields.
5. Deduplicate using a receiver-owned stable fingerprint and process asynchronously.
6. Use test, delivery-event aggregates, and resume only with explicit change approval.

Approval Boundaries

Do not create, rotate, reveal, or revoke keys; invite or remove members; delegate across workspaces; connect sending accounts; create or activate campaigns; import or delete leads; change suppression or retention; register, patch, resume, or delete webhooks; alter plans or paid capacity; transmit diagnostics; or perform another production mutation without explicit approval from the accountable owner. Keep diagnosis read-only unless implementation was requested.

Output

Return the workspace-safe scope, files and contracts inspected, exact API v2 routes a…