Plan a custom Zintara integration around supported contracts

Define the decision

The existence of an API key and webhook screen does not establish support for every desired entity or event. A small proof of concept should expose missing capabilities before production data or sending decisions depend on them.

Work through the procedure

1. Describe the business action and its source of truth.
2. Map required reads, writes and events to reviewed supported routes.
3. Record scope, workspace identity and field availability.
4. Define retries, duplicate handling and reconciliation.
5. Test a synthetic happy path and a deliberate failure before estimating rollout effort.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Requirement: create a CRM task after a positive reply
Available event: reply.received with email, subject and leadId
Missing evidence: positive sentiment and complete reply body
Design decision: human review or an additional supported context path is required

Read the result

The brief makes the gap visible before developers implement an assumption. A subject containing yes is not a safe substitute for a reviewed positive-reply classification.

Check before moving on

1. Include operational ownership and secret rotation.
2. State what happens when a notification never arrives.

Limits and next action

Do not sell a custom integration as a native product feature. Confirm the deployed contract and keep unsupported requirements in the delivery scope.

Source: Zintara implementation and product context