Register students in bulk with the API

Colleges that enrol large cohorts do not want to create registrations one at a time in the interface. The Section Registration API creates them from a script, one student or a whole batch at a time. Read on for both calls, and for how to confirm what was actually created.

Before you start

• Your college needs DualEnroll API credentials. These are the same credentials used for the rest of the DualEnroll API. If your college doesn't have them yet, contact your DualEnroll representative. Requests authenticate with HTTP Basic authentication.
• Your college needs a registration workflow configured for the courses you're registering into. These endpoints start the same workflow a manual registration would; if no workflow matches, the registration is refused.
• Each student must already have a completed application at your college. This API registers existing applicants into sections. It does not create students or applications.
• You need DualEnroll's own student and course section IDs. Both are available from your reports. They are not your SIS identifiers and not the student's college ID number.
• Full request and response details live in the API reference at /api-docs on your DualEnroll site. This article covers how to use the endpoints well; the reference covers every field.

Registering one student

Use this when you want immediate confirmation. The response contains the registration that was created.

1. Send a POST to /college/api/section_registrations with the student and section:

   json{
     "sectionRegistration": {
       "studentId": 12345,
       "courseSectionId": 67890
     }
   }

2. A success returns 201 Created with the new registration. Its DualEnroll registration ID, the course number and title, the section number, the term, and the creation timestamp.
3. A rejection returns an error listing every reason the registration couldn't be made. For example that the section is full, or that the student hasn't completed the application required to register. All reasons are returned together, not one at a time, so you can fix them in one pass.

Registering a batch

Use this for volume. The batch endpoint checks every registration immediately, then creates the valid ones in the background.

1. Send a POST to /college/api/section_registrations/batch with an array:

   json{
     "sectionRegistrations": [
       { "studentId": 123, "courseSectionId": 456 },
       { "studentId": 124, "courseSectionId": 456 },
       { "studentId": 125, "courseSectionId": 457 }
     ]
   }

2. Send no more than 50 registrations per request. This limit is not negotiable and it is not announced, see the warning below. Split a larger list into chunks of 50 or fewer and send them in sequence.
3. The response reports every item. Items that passed validation come back marked queued with a job reference; items that failed come back with their reasons. A summary line gives the totals.

Confirming what was created

This step is not optional for batch submissions.

A queued registration is not a created registration. Each queued item is re-checked at the moment it is actually created, and conditions can change in between. A section that had one seat left when you submitted may be full by the time the twentieth registration runs. When that happens the registration is not created, and the failure is not reported back to you. The only way to know is to check.

Two endpoints tell you what landed:

• One student and section. GET /college/api/section_registrations/status?studentId=123&courseSectionId=456. Both parameters are required. This returns the actual registration if one exists, and any still-waiting job for that pair, so you can tell "not created" apart from "not created yet". Waiting jobs take a few seconds to appear or disappear, so allow a short delay before treating an empty result as final.
• Everything in a term, GET /college/api/section_registrations?termId=222. termId is required; the request fails without it. You can narrow further by student, section, or creation date range, and results are paginated at 50 per page. This endpoint reads created registrations only. It does not show waiting jobs.

A practical pattern: submit a chunk, wait a short time, then query the term for registrations created since you started, and compare that list against what you sent.

What success looks like

If this doesn't work

A student comes back as "not found" but you can see them in DualEnroll. The check is not just whether the student exists. It's whether they have an application at your college. A student who exists but hasn't applied to your college, or whose application isn't complete, is reported as not found. Check the student's application before checking the ID.

Items you submitted in a batch never turn into registrations. First confirm you sent 50 or fewer in that request; anything beyond 50 was discarded silently. If you were within the limit, the registration was queued and then refused at creation time. Most often because the section filled up, the student was already registered, or a restriction that passed at submission no longer did. Query the section's remaining capacity and the student's existing registrations, then resubmit the ones you still need. Your DualEnroll representative can look up exactly why a specific one failed.

The query endpoint returns an error before you get any results. termId is required on GET /college/api/section_registrations, and both studentId and courseSectionId are required on the status endpoint. A request missing them is rejected outright rather than returning everything.

A registration comes back with no status value. An empty status means the registration exists and is still working through its workflow. It is not an error and not a failure. Values only appear once the registration reaches an end state such as complete, dropped, withdrawn, or abandoned. Treat "exists with no status" as the normal healthy result immediately after creating one.

Every registration is refused with a message about no matching registration workflow. Your college has no registration workflow configured for those courses, so DualEnroll has nothing to start and won't create a registration it can't process. This is a configuration question for your DualEnroll representative, not something to retry.

One submission produced several registrations for the same student. If the section is set up as a linked group (a lecture with its required lab, for example) registering into it registers the student into every component section. That's intended.

A registration you expected to be blocked went through, or one you expected to work was refused. Any registration rules specific to your college apply through the API exactly as they do in the interface. The API is not a bypass, and it isn't a stricter path either.

Contact your DualEnroll representative. They can confirm your API credentials, check whether a specific registration was created, and read back why one was refused.