UJAT API

A backend service built with Carlos Burelo to give student apps a stable JSON interface over legacy university academic systems.

Snapshot

Overview

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.

The problem

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.

• Students had no official API to integrate with personal or academic tools.
• Client apps would need to depend on brittle, page-oriented flows if they talked to the portal directly.
• Any solution had to respect session-based access and the constraints of a legacy ASP.NET environment.
• We needed a thin backend layer that could normalize data without rewriting the institution's systems.

Who it was for

• University students who wanted academic information in a mobile-friendly format
• Student developers building side projects or coursework apps around campus life
• Our team, as a practical exercise in API design and backend integration

My role

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.

What the project does

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.

• Accepts student credentials and establishes an authenticated session for downstream requests
• Returns normalized student profile data, including enrollment, faculty, career, and academic progress fields
• Exposes schedule data filtered by enrollment and academic cycle
• Exposes grade data with ordinary and extraordinary results where available
• Keeps controllers separated by domain so each endpoint stays focused and easy to extend

Key features

Session-based login endpoint

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.

Student profile aggregation

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.

Schedule retrieval

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.

Grade retrieval

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.

Lightweight HTTP routing

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.

Technical approach

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.

Design decisions

We designed the API around what student clients actually needed: a few clear endpoints, predictable JSON, and session reuse after login.

• Chose REST-style GET endpoints so mobile or web clients could consume the service with minimal setup
• Split controllers by domain instead of building one large handler file
• Returned JSON only, even when the source system was page-based and table-driven
• Kept the service stateless at the application layer and pushed session handling to request headers
• Avoided adding a database because the source system remained the system of record

Challenges and tradeoffs

• The official portal was not built for third-party integration, so every feature depended on how stable the upstream pages remained.
• Session-based access added complexity for clients and made error handling more important than in a typical public API.
• Normalizing inconsistent or partially structured page data required careful field mapping and defensive parsing.
• There was no institutional approval process for this prototype, which meant the project had to stay academic in scope and avoid presenting itself as an official service.
• Legal and policy risk was real: exposing integration details publicly could create problems for us and for users, so the project should be understood as a learning exercise rather than a reusable production integration.

What I learned

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.

• I learned to design small APIs that do one job well instead of trying to mirror an entire legacy portal.
• I learned how much effort goes into turning page-based institutional data into stable JSON contracts.
• I learned to treat compliance, terms of use, and institutional boundaries as part of the architecture, not an afterthought.

Current status

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.

If I revisited this today

• I would not rebuild this as an unofficial scraper-backed API without written approval from the institution.
• I would start by asking whether the university offers sanctioned access, exports, or partner integrations before writing custom integration code.
• I would replace brittle page parsing with contract-driven APIs, official feeds, or documented institutional endpoints if those exist.
• I would add clearer rate limiting, audit logging, and security review if any similar service were ever authorized for production use.
• I would document data retention and privacy expectations explicitly for any student-facing academic product.
• I would keep the domain modeling lessons, but separate the portfolio story from any implementation that could create legal exposure.