Integration checklist

Use this checklist as the release gate for a third-party Waspito integration. It is intentionally operational: each item should have an owner, evidence, and a clear pass or fail result before production traffic is enabled.

Recommended review: Include engineering, security, product, support, and the person responsible for patient-data governance in the final readiness review.

1. Application ownership

• The application has a clear technical owner and business owner.
• The Developer Console app name identifies the integration and environment.
• Production and non-production workloads do not share credentials.
• The team knows how to disable the application and who is authorized to do so.
• Support has the application ID and internal escalation path, but never the client secret.

2. Credential security

• Client credentials are stored in a managed server-side secret store.
• Secrets are absent from Git history, build output, logs, analytics, screenshots, and support tickets.
• Browser and mobile bundles contain no Waspito client secret or developer token.
• Access to production secrets follows least privilege and is auditable.
• The team has a tested process for replacing a compromised application credential.
• Authorization headers are redacted by HTTP logging and observability tools.

3. Token management

• The backend caches the token with an expiry derived from data.expires_at.
• A safety window renews the token before it expires during a protected request.
• Concurrent workers cannot repeatedly replace each other's token.
• A protected request is retried no more than once after token renewal.
• Persistent 401 responses trigger an operational alert instead of an infinite retry loop.

Review Generate an access token for the supported lifecycle.

4. Request construction

• Every request uses HTTPS and the assigned environment host.
• Accept: application/json and Content-Type: application/json are sent consistently.
• Protected calls use the standard Authorization: Bearer ... header.
• Request timeouts are explicitly configured.
• Patient phone numbers are normalized before being submitted.
• Optional fields are omitted when unknown instead of populated with misleading placeholder data.

5. Response and error handling

The integration handles both the HTTP status and Waspito's application-level response fields.

6. Retry design

• The system distinguishes connection failures from application rejections.
• Validation and authentication errors are not retried with unchanged data.
• Backoff has a maximum attempt count and maximum elapsed time.
• Retries for link generation are serialized per patient where practical.
• The product can recover when the original request succeeded but its response was lost.
• Support can identify a workflow by session_id without using a signed URL.

7. Patient data and privacy

• Only the minimum approved patient fields are sent.
• Product copy explains why the information is required.
• Retention periods are defined for phone numbers, dates of birth, consultation IDs, and operational logs.
• Sensitive values are encrypted in transit and at rest.
• Signed consultation URLs are not stored in analytics or exposed in notification previews.
• Access to patient and consultation data is role-based and reviewable.
• The incident-response process covers accidental credential or patient-data exposure.

8. Patient-facing experience

• Loading, success, expiry, unavailable-doctor, and retry states are designed.
• Error messages give users a next step without revealing internal API details.
• Link expiry is communicated in readable local time.
• Keyboard and screen-reader users can complete the workflow.
• Color is not the only indication of success, warning, or failure.
• The link delivery channel is approved and controlled by the intended patient.
• Support contact information is available when self-service recovery is not possible.

9. Observability

Monitor outcomes without recording secrets or unnecessary health information.

Recommended signals include:

• Request count by endpoint and environment.
• Latency and timeout rate.
• Success rate by Waspito response code.
• Token-renewal failures.
• Unavailable-doctor responses.
• Link-generation failures and patient-visible recovery rate.
• Retry count and exhausted-retry count.

Alerts should identify the application, environment, endpoint category, HTTP status, and response code—not the Authorization header or patient payload.

10. Test matrix

Complete these tests with non-production credentials and synthetic patient data:

11. Launch and rollback

• Production credentials are provisioned through the approved channel.
• The release begins with limited traffic or a controlled partner group.
• Dashboards and alerts are active before traffic starts.
• Engineering and support coverage is confirmed for the launch window.
• A rollback can stop outbound requests without requiring a full application deployment.
• The team knows when to disable the Waspito developer application.
• Post-launch review is scheduled using error, latency, retry, and patient-recovery data.

Definition of ready

The integration is ready when:

1. Every checklist section has an accountable owner.
2. The complete test matrix passes with evidence.
3. No Waspito credential or sensitive patient value appears in client code or logs.
4. Failure states have safe user experiences and bounded operational recovery.
5. Monitoring and rollback are active before the first production request.

Return to the API overview or begin with Getting started.