​

Testing, Deployment, and Support

Every custom integration needs an implementation plan agreed by Avoca and the integration partner. The plan should identify environments, test data, owners, acceptance criteria, rollout stages, monitoring, and escalation routes.

​

Test Environment

When the partner provides a sandbox, document:

• Sandbox base URL and authentication method
• Test customers, services, locations, and availability
• How to reset or recreate known test data
• How to trigger webhook and failure scenarios
• Differences between sandbox and production behavior

Use synthetic or approved test data. Never copy production customer data into a sandbox unless the security and privacy owners for both organizations have approved it.

​

Validation Scope

Test at least:

• Customer lookup and identity matching
• Availability and booking happy paths
• Validation errors and unavailable-slot behavior
• Duplicate requests and idempotency
• Authentication failure and credential rotation
• Timeouts, retries, and partial dependency failure
• Webhook signing, delivery, retry, and deduplication
• Cancellation, rescheduling, and reconciliation when supported
• Expected behavior when a dependency is unavailable

Performance and security testing should match the expected production volume and risk. Agree on rate limits and load-test windows before generating high traffic against either party’s environment.

​

Implementation Phases

A typical integration progresses through:

1. Discovery and design — confirm workflows, data ownership, API contracts, and security requirements.
2. Development — establish credentials, implement the contract, and add unit and contract tests.
3. Integration testing — validate end-to-end behavior and failure handling in non-production environments.
4. User acceptance — confirm the workflows with representative customer scenarios.
5. Production rollout — release to a limited scope, monitor, and expand after acceptance criteria are met.

Timing depends on partner readiness, workflow complexity, available environments, and unresolved contract questions. Treat any estimate as project-specific rather than a standard Avoca SLA.

​

Production Readiness

Before go-live, record:

• Production endpoints and credential owners
• Approved IP or network controls, if any
• Timeout, retry, and idempotency behavior
• Logging and correlation identifiers
• Dashboards, alerts, and on-call ownership
• Rollback, disablement, and data-reconciliation procedures
• Customer-support and engineering escalation contacts
• Maintenance and incident-notification expectations

​

Support

Use support@avoca.ai or Settings → Support in the Avoca dashboard for the initial Avoca support route unless the implementation plan names a dedicated partner channel. For an integration issue, include:

• The affected environment and workflow
• Approximate occurrence time and time zone
• A safe request, event, or correlation identifier
• Expected and observed behavior
• Whether the issue is ongoing

Do not include API keys, webhook secrets, complete customer payloads, or other sensitive data in the initial report. Response targets, severity definitions, deprecation notice, and after-hours escalation are governed by the applicable customer or partner agreement. Do not infer them from this guide.

​

Change Management

Maintain the OpenAPI specification and implementation guide with the integration. For a breaking change, agree on migration guidance, notice, testing, and any dual-version period before rollout. Release history is maintained in Avoca’s separate release-notes system, not this help center.

​

Provider-Specific Tooling

The integration can use the partner’s preferred CI/CD, monitoring, API-management, and work-tracking tools. During discovery, document how correlation identifiers, structured logs, health checks, and alerts map into those tools.