The SIS sync endpoint

SIS sync is how a student information system pushes a cohort's roster into First Six. It is the production path for getting students in, and it is what SSO links against at login time.

The endpoint

POST /api/sis/sync
Authorization: Bearer <your-sync-secret>
Content-Type: application/json

Authentication is a shared secret in the Authorization header, not a user session. We issue you the secret; it is machine-to-machine. If the secret is not configured on our side the endpoint returns 503, and a missing or wrong secret returns 401.

The payload

{
  "cohort_id": "0e0f...uuid",
  "students": [
    {
      "first_name": "Alex",
      "last_name": "Connor",
      "email": "alex.connor@student.example.edu.au",
      "student_id_ext": "U2025001",
      "program_code": "BUSI",
      "campus_name": "Sunshine Coast",
      "first_in_family": false
    }
  ]
}

cohort_id and a students array are required. For each student, email and student_id_ext are required; the rest are optional. If you send a program_code or campus_name, it must match one already configured for the institution.

A batch is capped at 5000 students. Larger batches return 413; page them.

The response

{
  "received": 42,
  "imported": 40,
  "details": { "imported": 20, "updated": 20 },
  "errors": [{ "row": 5, "message": "email required" }]
}

Idempotency and partial data

The sync is idempotent. Re-sending the same students updates the existing rows in place rather than duplicating them, so a nightly full-roster push is safe to run as often as you like.

Bad rows do not sink the batch. A row missing a required field is rejected and reported in errors, while every valid row still imports. A push of 100 with 10 bad rows imports 90 and returns 10 errors.

A typical integration

Run a nightly job that pulls the current roster from your SIS and POSTs it in pages of up to 5000. Because the sync is idempotent, you do not need to compute deltas; push the full current state and let First Six reconcile.