Authentication and scopes
Start with how the integration proves who it is. Read whether the API uses a client credential, an API key, a signed request or a user token. Check how tokens expire and how they are refreshed. A token that expires during a long import can leave a partial record behind.
Look at scopes next. The integration should ask for the permissions it needs and no others. If the documentation lists one broad scope for every action, ask whether read and write can be separated. Record which person or system owns the credential.
Endpoints and rate limits
List the endpoints the workflow needs. For each endpoint, confirm the request shape, the required fields and the response shape. Check whether the API returns the full record or only an id that needs a second call.
Read the rate limit section before you plan a bulk action. Note the limit, the window and the response when the limit is reached. Build a queue with a backoff instead of retrying in a tight loop. If the documentation does not state a limit, ask support for the production value.
Idempotency and duplicate events
Networks retry. A webhook can arrive again, and an import can run again after a timeout. An idempotent write uses a stable key so the second request updates the same record instead of creating a new one. Ask whether the API supports an idempotency key, and send the same request again in the sandbox.
For events, store the event id and ignore an event you have already processed. That small table prevents a duplicate stage change from reaching a candidate record.
Webhooks, retries and replay
Check which events exist and what the payload contains. A payload with only an id forces a second call, so confirm that the follow-up endpoint is available. Read the retry schedule and the signature method. Verify the signature before you trust a payload.
Ask how to replay an event that was missed while your service was down. A replay path is part of the design, not an emergency feature. Log every event id, the response code and the time so you can compare notes with the vendor.
Schema, versioning and field changes
Ask how the API handles a new field or a renamed value. A version header and a deprecation notice give you time to update. Without a policy, a small change can break a mapping that worked yesterday.
Keep your own copy of the field map with the version of the API it targets. When the vendor announces a change, compare the map, update the sandbox and test the affected handoff before production.
Errors, logs and deletion
Define what your system does with each error class. A validation error needs a person, a temporary server error needs a retry, and an authentication error needs a new token. Write those rules down and show them in the integration log.
Ask how a deletion request reaches the API and what the response confirms. Check whether the deletion covers recordings, transcripts and derived summaries. Document the path from the candidate request to the vendor and back, so the team can answer a question without guessing.
Sandbox and support
Ask for a sandbox with sample data and a way to simulate a failed call. Test the happy path, a duplicate event, an expired token and a rejected field. Keep the test records separate from production.
Finally, ask who supports the integration and how to reach them. A clear escalation path with named contacts belongs next to the endpoint list. The checklist does not remove every risk, but it shows which parts the team has actually agreed on.