Use this checklist before a customer integration pilot starts. It separates what TutorFlow can support now from the information the customer should confirm before production integration.
Confirmed integration scope
| Item | Current support | Customer input needed |
|---|---|---|
| Input method | POST /v1/content/integrations/expansions accepts customer-owned JSON. | Provide the latest production JSON for one small content group. |
| Source structure | Category, level, and ordered lessons are supported. Unknown fields are preserved in prompt context. | Confirm the final names and required fields for the source lesson types. |
| Output priority | TutorFlow creates outputs in this order: interactive_module, summary_video, expanded_quiz. | Confirm whether all three outputs are needed for pilot review or only the first priority. |
| Result retrieval | Poll status and result endpoints with the returned job id. | Store the TutorFlow job id in the external system. |
| UI-authored content control | /v1/content/classrooms/{classroomId}/modules, /v1/content/classrooms/{classroomId}/courses, /v1/content/classrooms/{classroomId}/videos, /v1/content/classrooms/{classroomId}/slides, and /v1/content/classrooms/{classroomId}/tests expose direct content control. | Confirm which resources should be synced first. |
| Authentication | Expansion and resource endpoints use a dedicated Content Integration API key. Key and webhook management use the signed-in TutorFlow admin session. | Confirm key owner, rotation policy, and environment separation. |
| Rate limits | Rate limits follow Content Integration API key settings. | Provide expected pilot and production request volume. |
| Webhooks | content.completed and content.failed events are available after polling is verified. | Provide callback URL and retry expectations for production use. |
| Copyright | TutorFlow stores the submitted source payload and generated output metadata. | Confirm the customer owns or can process the submitted content. |
| Billing | Generated modules, videos, and quizzes use existing TutorFlow billing meters for those content types. MP4 rendering is separate. | Confirm who owns pilot cost approval and whether video rendering should be enabled after review. |
| Pilot scope | One small content group can be validated first. | Provide the source JSON and expected review criteria. |
Pilot acceptance checks
- The source JSON is accepted without pre-conversion.
- The job status endpoint moves through
queued,processing, and a terminal status. - The result manifest includes one entry per requested output.
- The interactive module is usable inside TutorFlow.
- Summary video output creates editable video structure before MP4 rendering.
- Expanded quiz output preserves answer intent from source quiz content.
- Authentication, rate limit behavior, and billing expectations are understood before production rollout.
Customer handoff checklist
Before production automation, confirm that the customer can provide or store each item below.
| Handoff item | Owner | Required for pilot | Required for production |
|---|---|---|---|
| Test Content Integration API key | Customer admin | Yes | No |
| Production Content Integration API key | Customer admin | No | Yes |
| One source JSON sample | Customer | Yes | Yes |
| Source content version or hash | Customer | Recommended | Yes |
| Idempotency key format | Customer | Yes | Yes |
| Job id storage field | Customer | Yes | Yes |
| Result manifest storage field | Customer | Yes | Yes |
| Webhook callback URL | Customer | No | Recommended |
| Billing approver | Customer | Yes | Yes |
| Copyright confirmation | Customer | Yes | Yes |
Readiness questions
- Which source object should map to one TutorFlow job: a level, a lesson group, or another content bundle?
- Which output should block pilot approval if it fails?
- Should the external system store every output manifest or only approved outputs?
- Who reviews generated modules, video structures, and quiz items before they are reinserted?
- What request volume should the production key allow per minute?
- What retention period should the customer use for source payloads and result manifests?
Production readiness
- A production key has been created and stored in a secret manager.
- Test keys and production keys are separate.
- The external system can rotate the key without code changes.
- Result manifests are stored with source content ids.
- Webhook signatures are verified before event processing.
- Support logs include key prefix and job id, not full secrets.