Skip to main content
Use this checklist for the workflows your integration implements. Record the owner and evidence for each applicable item before enabling production traffic.

​
Access and configuration

  • REST requests use https://api.protodesk.io/v1; MCP clients use https://mcp.protodesk.io/mcp.
  • API keys are stored server-side and excluded from source control, browser bundles, URLs, and logs.
  • The connection has only the permissions required by the workflow.
  • A connection check verifies the intended workspace before writes begin.
  • An operator knows how to revoke or replace a credential and reconnect an OAuth client.

​
Reliable requests

  • Lists follow cursor pagination, including the empty-list case.
  • Concurrency is bounded and rate-limit headers are handled.
  • Timeouts and retries have an attempt limit and an elapsed-time deadline.
  • Supported writes retain the same idempotency key and exact request across retries.
  • Uncertain write outcomes are reconciled before creating a new action.
  • Conflicts and permission errors reach an operator with useful context.

​
Customer-facing actions

  • Message recording and customer sending use the correct, separate operations and scopes.
  • The recipient, channel, and configured sender have been checked with a controlled delivery test.
  • The integration distinguishes queued, sent, delivered, failed, and canceled outcomes where available.
  • Scheduling and cancellation respect the documented limitations; the interface does not promise message recall.
  • AI-generated replies and Help Center proposals have the review process your team intends to use.
  • AI credit usage and failure handling have been checked for workflows that call Evelin.
See Send replies and MCP use case examples for the relevant flows.

​
Events and operations

  • Webhook signatures are verified against the raw body before processing.
  • Event IDs are deduplicated durably, and out-of-order events are handled.
  • Accepted webhook work is stored durably before returning success.
  • Logs include status, error code, request ID where available, and relevant resource IDs without secrets or unnecessary customer content.
  • Alerts or an operational review catch repeated failures, throttling, and delivery problems.
  • A named owner can pause background work, investigate a failure, and resume safely.
Follow the webhook guide for verification and delivery history.

​
Release and recovery

  • Integration tests have passed, including duplicate requests and timeout cases.
  • Temporary keys, OAuth connections, subscriptions, and synthetic data have been cleaned up as appropriate.
  • A small initial rollout can be observed before increasing traffic.
  • Your rollback procedure stops new actions and accounts for already queued or scheduled work.
Revoking a key blocks future authenticated requests; do not use it as a substitute for canceling a pending message. Inspect queued work separately and cancel supported pending sends before their delivery worker claims them.