ProjectUJAT API
UJAT API
A backend service built with Carlos Burelo to give student apps a stable JSON interface over legacy university academic systems.
Snapshot
| Field | Details |
|---|---|
| Type | Backend API Prototype |
| Context | University Project |
| Role |
A backend service built with Carlos Burelo to give student apps a stable JSON interface over legacy university academic systems.
| Field | Details |
|---|---|
| Type | Backend API Prototype |
| Context | University Project |
| Role |
| Co-developer |
| Year | 2022 |
| Status | Academic Prototype |
| Main focus | Scraping, session auth, and REST endpoints for student academic data |
UJAT API is a Node.js backend I built with Carlos Burelo during our university work for Google Developer Student Clubs. The goal was to give mobile or web clients a predictable JSON interface instead of forcing them to work directly with the university's older academic portal.
The project was an academic prototype, not a production service endorsed by the institution. It explored how to bridge a modern client experience with systems that were never designed to offer public APIs. I keep it in my portfolio because it shows early backend integration work, API design, and the practical limits of building on top of institutional platforms.
University students often need the same information repeatedly: profile details, class schedules, and grades. The official academic portal was built for browser use, not for apps that expect structured data and simple authentication flows.
Carlos Burelo and I worked as a two-person team on this backend. I contributed to the overall API structure, endpoint design, request handling, and the integration layer that connected authenticated sessions to structured responses.
We split implementation work across login, student profile, schedules, and grades. I helped shape how responses were normalized into JSON and how the service stayed small enough to run as a focused integration backend rather than a full platform.
The service exposes a small REST surface for academic data. After a student authenticates, clients can request profile information, schedules for a given enrollment cycle, and grade reports without parsing institutional HTML themselves.
The API provides a login route that validates student credentials against the official academic portal and returns the session context client apps need for later requests. This kept authentication in one place instead of duplicating it across every client.
The student endpoint gathers profile fields from the academic system and returns them as a single JSON object, including available academic cycles. That made it much easier for frontends to render a dashboard without chasing multiple page fragments.
The schedules endpoint accepts enrollment and cycle parameters and returns class schedules as structured rows with subject, group, weekday slots, and instructor information. This was one of the most useful outputs for any student-facing app.
The scores endpoint returns grade rows for a selected cycle, including ordinary and extraordinary results and related metadata when present. Normalizing this data was important because the source pages were table-oriented and awkward for mobile layouts.
The service uses a minimal HTTP framework and a small set of route modules. That choice kept the prototype easy to read, deploy locally, and reason about during development.
The backend is a Node.js service organized around route controllers for login, student data, schedules, and grades. Each controller handles validation, calls into a shared integration layer, and returns JSON responses.
Authentication depends on the same session model the official portal uses. Rather than inventing a separate identity system, the API translates portal access into something client apps can reuse through headers on later calls. Data retrieval reads institutional pages and maps the relevant fields into stable response shapes.
We used lightweight HTTP tooling for routing and requests, browser automation where the portal required interactive sign-in, and HTML parsing to transform page output into structured objects. The architecture stayed intentionally small: no database, no admin panel, and no attempt to replace the source system.
Because of the sensitive nature of working with an institutional academic website, I am keeping implementation details out of this portfolio page. The focus here is on the problem, the API shape, and what the project taught us, not on the internal integration mechanics.
We designed the API around what student clients actually needed: a few clear endpoints, predictable JSON, and session reuse after login.
This project pushed me to think like a backend engineer working inside someone else's system. I learned that a useful API is not only about clean routes, but about understanding upstream constraints, normalizing messy data, and being honest about what you should and should not expose.
This project is no longer maintained and should be understood as an academic prototype from 2022. It was never deployed as an official university service, and it is not something I would recommend running against live institutional systems without explicit authorization.
I keep it in my portfolio because it shows how Carlos and I approached a real integration problem under academic constraints, even though the sensitive details of the implementation remain private.