How can a university translate the information exchanged through 1EdTech Edu-API without changing student identity, course enrollment, academic status or the meaning of an official record? Edu-API is an emerging standard for connecting higher-education enterprise systems. It addresses a problem familiar to institutions worldwide: student information systems, learning management systems and campus services need to exchange information, while their human-facing labels operate in multiple languages.
People searching for Edu-API localization, multilingual student information system integration, higher-education API translation, course catalogue internationalization, university enrolment data exchange or campus interoperability should first distinguish presentation language from source data. A localized course description can help a student select a subject. An accidental change to a course code, academic period or learner identifier can instead send that student to the wrong resource or misstate official enrollment. These are different kinds of change and deserve different approval.
This guide is for university registrars, campus integration engineers, learning-platform suppliers, translation teams and student-services staff. As of October 2026, 1EdTech publicly describes Edu-API as Candidate Final Public rather than a fully final published release; detailed specification material may require sign-in. For that reason, the examples below explain defensible integration and localization principles without pretending to quote unverified endpoint names or final conformance rules. The goal is practical clarity for a global campus while respecting the live version, institutional policies and rights of individual students.
How to read the public Edu-API architecture responsibly
The public 1EdTech Edu-API overview describes an approach to core higher-education enterprise data exchange among SIS, LMS and related campus systems. It builds on experience with Learning Information Services, OneRoster and Learning Tools Interoperability. The published overview emphasizes reusable data semantics across different transport and integration architectures rather than prescribing a campus’s screen vocabulary. Since the public specification page may require sign-in and remains identified as Candidate Final, the exact production payload, integration profile and conformance claims must be checked by authorized implementers. The educational translation problem is already concrete: institutions need readable international information while keeping administrative facts, roles and access decisions reliable.
Thirty practical decisions in multilingual campus data exchange
A campus has several sources of truth
Universities rely on different systems for records such as student identity, course offerings, enrolments, learning activity and services. An API can exchange data among them, but translation cannot decide which system controls an official fact. Establish ownership before rewriting any interface.
A student changes a family name in the registrar’s record but not in the LMS. A localized portal displays conflicting names. The remedy is a governed identity update, not an editor choosing whichever spelling seems easiest.
The stable requirement is the authoritative owner for each data category. This is where translation stops being a matter of preferred phrasing and becomes part of safe institutional operation. A learner may make financial, academic or travel decisions based on these screens. The right words help only when they describe the actual state of the institution’s records and services.
Before approval, trace which system creates, changes and publishes the field. Use an ordinary case and an exceptional case, because apparently simple labels become ambiguous when a student is waiting for a decision or moving between institutions.
Candidate Final is not the same as a final release
1EdTech’s public overview identifies Edu-API as Candidate Final Public, with an initial version in development. A project should not describe that status as universally final or claim vendor certification that has not been checked. Localized documents need a clear as-of date.
A vendor brochure advertises a ‘fully final and universally certified Edu-API’ based on a candidate implementation. A university relies on the claim and expects exact interoperability. The translation should reflect the actual published status.
The local interface should explain the situation without altering the standard’s currently verified publication and implementation status. An institution can add glossaries, explanatory footnotes and familiar navigation, but those additions do not grant authority to change core records. The best international experience makes both the student’s options and the source of each statement clear.
A reliable review action is to recheck official 1EdTech materials and the vendor’s actual supported profile. Compare what the student can see with what the system actually sends and what the designated owner records.
Think of the record before its transport
The public Edu-API description emphasizes exchanging core academic enterprise data across different integration topologies. A translated integration narrative should explain the data’s meaning without promising a particular transport method where that has not been verified.
A campus runs event-based middleware while a partner uses a synchronous request. The visible student record may be the same kind of information, but a technical translation that assumes every exchange is an ordinary web page is unhelpful.
For an international learner, the record’s meaning and the actual integration architecture may be invisible until something goes wrong. That is exactly why it needs protection. A translation that overstates admission, enrollment or eligibility can mislead a student in ways that a cosmetic layout error cannot. Keep human-friendly explanations beside, not instead of, the authoritative value.
The validation step is to verify payload semantics and transport behavior separately. Have a registrar or service owner approve any wording that implies a formal academic decision.
Student information systems and registrars
A student information system commonly stores core academic and administrative records. Translation of its fields has consequences: admission, registration, official names and academic status are not marketing copy. Do not silently recategorize administrative decisions.
An application status is ‘under review’. The translated student portal says ‘admitted’. The result sounds positive but is false and may cause a student to make travel or financial commitments prematurely.
This distinction is easy to lose when different campus departments use the same everyday word. The correct meaning depends on the institution’s official decision and the status definitions, not on what the term would usually mean in a dictionary. Translators should seek clarification instead of choosing a stronger institutional claim. Engineers should avoid treating translated labels as primary database keys.
To test the result, test all admission and registration states with registrar approval. Both the technical integration and the student’s understanding must agree.
Learning management systems are not registrars
An LMS may hold course content, activities, grades and participation. It often relies on student and enrolment information from another system. Localized dashboards should disclose which results are provisional and which are the official academic record.
A teacher enters a provisional mark into the LMS. A translated student summary labels it the final university grade, although the registrar has not released results. The misunderstanding can affect appeals and progression.
A useful operating rule is to preserve the distinction between learning activity and official academic outcomes and expose uncertainty plainly when a downstream system has not yet confirmed a change. This is especially valuable for students moving across countries who may have no prior experience of the institution’s academic administration. A readable interface should tell them what is known and what remains pending.
Reviewers should compare source-system ownership for assessment and final-grade fields. Look for phrases that accidentally promise an outcome before the responsible office has made it official.
Stable learner identifiers
Student numbers and system identifiers identify a particular person or relationship. Translating them as ordinary text can break joins and create privacy risks. Names shown to students may use culturally appropriate scripts without modifying stable reference keys.
Two learners share a common name. A language-specific export substitutes names for IDs and accidentally joins their course information. The resulting portal reveals one student’s records to another.
The most robust multilingual systems separate a canonical data fact from its display language. In this example, identifier stability and authorized identity mapping is that fact. Better labels, examples or help text may all be valuable, but they must respect the original record and the institution that owns it. The same rule applies whether the student reads the page on a phone or through an assistive device.
As a final check, test duplicated names and legitimate name changes using synthetic accounts. Record the agreed interpretation so another system does not later translate the same status in a contradictory way.
Names across scripts and naming conventions
A campus may serve students whose names do not follow Western given-name and surname patterns. Display language can adapt respectfully, but an official name record should not be overwritten with an editor’s guess about a culturally expected ordering.
A student with a multi-part family name appears differently in admissions, library and housing systems. A translator reverses a component and creates inconsistent service records. The UI needs careful rendering, not invented identity data.
The stable requirement is the official name fields and authoritative corrections process. This is where translation stops being a matter of preferred phrasing and becomes part of safe institutional operation. A learner may make financial, academic or travel decisions based on these screens. The right words help only when they describe the actual state of the institution’s records and services.
Before approval, compare original names, display conventions and user-confirmed variants. Use an ordinary case and an exceptional case, because apparently simple labels become ambiguous when a student is waiting for a decision or moving between institutions.
Course catalogue description and code
A course description is human-facing and often suitable for translation. A course code and offering identifier are machine-relevant and should stay consistent. The title shown in a local language must still identify the particular course that can be enrolled in.
A student selects an economics course using its translated description. The label points to another course with a similar title and different prerequisites. The error is a resource mapping failure, not a vocabulary preference.
The local interface should explain the situation without altering the course code, catalogue identity and substantive academic content. An institution can add glossaries, explanatory footnotes and familiar navigation, but those additions do not grant authority to change core records. The best international experience makes both the student’s options and the source of each statement clear.
A reliable review action is to follow a target-language enrolment link back to the official catalogue entry. Compare what the student can see with what the system actually sends and what the designated owner records.
Catalogue courses versus offered sections
An institution may list a general course and offer multiple sections in different terms, locations or teaching formats. Translating a section label should not collapse distinct scheduled offerings into one generic course title.
A bilingual university teaches the same biology module in two campus sections. A translated timetable omits section and campus labels, leading learners to attend the wrong location.
For an international learner, the offering, section and campus identifiers may be invisible until something goes wrong. That is exactly why it needs protection. A translation that overstates admission, enrollment or eligibility can mislead a student in ways that a cosmetic layout error cannot. Keep human-friendly explanations beside, not instead of, the authoritative value.
The validation step is to test same-title courses offered in different sections and academic periods. Have a registrar or service owner approve any wording that implies a formal academic decision.
Enrolment status and actual access
Being enrolled, waitlisted, withdrawn, auditing or eligible to register can have distinct academic consequences. A localized button that says ‘Your place is confirmed’ is wrong for a waitlisted student even if the application appears friendly.
A learner accepts a waitlist position that the target-language screen describes as a completed enrolment. The student stops seeking alternatives and later discovers no seat was available.
This distinction is easy to lose when different campus departments use the same everyday word. The correct meaning depends on the actual enrolment state and effective date, not on what the term would usually mean in a dictionary. Translators should seek clarification instead of choosing a stronger institutional claim. Engineers should avoid treating translated labels as primary database keys.
To test the result, run end-to-end tests for confirmed, pending, waitlisted and withdrawn cases. Both the technical integration and the student’s understanding must agree.
Academic periods and calendars
Institutions divide the year into semesters, trimesters, quarters, blocks or other terms. The words are not interchangeable in every jurisdiction. A translated label must not turn an institutional term code into an inaccurate calendar period.
A university term called ‘Summer Session’ occurs during a different season for overseas participants. A literal seasonal translation without dates can mislead remote learners about when classes begin.
A useful operating rule is to preserve the official academic period and its actual start and end dates and expose uncertainty plainly when a downstream system has not yet confirmed a change. This is especially valuable for students moving across countries who may have no prior experience of the institution’s academic administration. A readable interface should tell them what is known and what remains pending.
Reviewers should show institution dates and local calendar context without altering the term identity. Look for phrases that accidentally promise an outcome before the responsible office has made it official.
Course credits and contact hours
Course credit values depend on the educational system. Converting a local unit into ECTS or another international framework without authorization can misstate workload and academic standing. The translation should retain original units and explain them.
A course carries three local credits. Its overseas brochure displays three ECTS credits without a valid institutional conversion. Students may use the number to plan a transfer that their receiving institution will reject.
The most robust multilingual systems separate a canonical data fact from its display language. In this example, the official credit value and unit in its system is that fact. Better labels, examples or help text may all be valuable, but they must respect the original record and the institution that owns it. The same rule applies whether the student reads the page on a phone or through an assistive device.
As a final check, require a registrar-approved conversion before stating equivalence. Record the agreed interpretation so another system does not later translate the same status in a contradictory way.
Prerequisites and corequisites
Prerequisite language sets conditions on enrolment and academic readiness. A mistranslation can create unauthorized pathways or discourage eligible students. Catalogues should distinguish recommended prior study from formally required conditions.
A program says ‘recommended: calculus’ and the translation says ‘calculus is required’. International applicants now think they are barred from a course they could take.
The stable requirement is the formal eligibility condition and its strength. This is where translation stops being a matter of preferred phrasing and becomes part of safe institutional operation. A learner may make financial, academic or travel decisions based on these screens. The right words help only when they describe the actual state of the institution’s records and services.
Before approval, test admission-rule wording against actual enrollment validation. Use an ordinary case and an exceptional case, because apparently simple labels become ambiguous when a student is waiting for a decision or moving between institutions.
Academic roles and privileges
Student, instructor, teaching assistant, adviser, registrar and administrator denote different responsibilities. Display translations can vary, but permissions should reflect the institution’s actual role model instead of presumed social status.
A visiting academic is labeled ‘administrator’ in a translation because the local word for senior instructor is similar. The visible status may imply access to private records that the account does not possess.
The local interface should explain the situation without altering the actual role assignments and granted privileges. An institution can add glossaries, explanatory footnotes and familiar navigation, but those additions do not grant authority to change core records. The best international experience makes both the student’s options and the source of each statement clear.
A reliable review action is to test role descriptions with both affected users and security owners. Compare what the student can see with what the system actually sends and what the designated owner records.
Multi-campus organization structures
A university may have faculties, schools, departments and affiliated institutes with historically specific names. Translation should preserve the organizational relationship, not flatten it into a generic ‘college’ label that changes institutional authority.
A research institute attached to a university is described as an independent degree-awarding school. International applicants could infer the institute issues awards that only the parent institution can confer.
For an international learner, legal organizational identity and delegated authority may be invisible until something goes wrong. That is exactly why it needs protection. A translation that overstates admission, enrollment or eligibility can mislead a student in ways that a cosmetic layout error cannot. Keep human-friendly explanations beside, not instead of, the authoritative value.
The validation step is to compare local-language names to institution-approved organizational records. Have a registrar or service owner approve any wording that implies a formal academic decision.
Class schedules and time zones
Students studying remotely need reliable schedules. Time zone conversions belong in presentation or an authorized scheduling service, not in arbitrary changes to the recorded start instant. Daylight-saving transitions make this especially important.
A seminar starts at 09:00 in the university’s local time. A translated email repeats 09:00 for an overseas student without identifying the zone, causing a missed live session.
This distinction is easy to lose when different campus departments use the same everyday word. The correct meaning depends on original scheduled instants and actual local display zones, not on what the term would usually mean in a dictionary. Translators should seek clarification instead of choosing a stronger institutional claim. Engineers should avoid treating translated labels as primary database keys.
To test the result, test cross-zone views across daylight-saving changes. Both the technical integration and the student’s understanding must agree.
Campus locations and physical access
Building names, room codes and accessibility information may be more useful when localized, but directional instructions must remain physically correct. A translated campus name should not be treated as a replacement for the registered location code.
A laboratory is in North Building, room N204. A translated timetable turns ‘North’ into a directional instruction to walk north, sending a learner away from the actual named building.
A useful operating rule is to preserve location identity, room identifier and authoritative wayfinding and expose uncertainty plainly when a downstream system has not yet confirmed a change. This is especially valuable for students moving across countries who may have no prior experience of the institution’s academic administration. A readable interface should tell them what is known and what remains pending.
Reviewers should walk-test or map-test instructions with campus services. Look for phrases that accidentally promise an outcome before the responsible office has made it official.
Student addresses and country codes
Global campuses collect addresses in different formats. A translation should not discard address components or infer a country from language. Structured country codes and postal information should be preserved according to the receiving system’s requirements.
An overseas student’s district and postal code are rearranged into a domestic address template and one required line disappears. Official mail is returned despite a readable localized form.
The most robust multilingual systems separate a canonical data fact from its display language. In this example, complete address elements and the actual country or territory is that fact. Better labels, examples or help text may all be valuable, but they must respect the original record and the institution that owns it. The same rule applies whether the student reads the page on a phone or through an assistive device.
As a final check, test country-specific examples and round-trip form submissions. Record the agreed interpretation so another system does not later translate the same status in a contradictory way.
Identity, authentication and account safety
A campus SSO integration may secure access to many services. Localizing account instructions must not suggest bypassing authentication or sharing credentials to fix access errors. An understandable message should explain the genuine next step.
An international student cannot launch a library service. The translated support text recommends giving a password to a teaching assistant. This compromises security and does not address the underlying integration issue.
The stable requirement is the approved authentication process and account-holder responsibilities. This is where translation stops being a matter of preferred phrasing and becomes part of safe institutional operation. A learner may make financial, academic or travel decisions based on these screens. The right words help only when they describe the actual state of the institution’s records and services.
Before approval, run failure scenarios without exposing passwords, keys or personal tokens. Use an ordinary case and an exceptional case, because apparently simple labels become ambiguous when a student is waiting for a decision or moving between institutions.
Authorized data sharing between services
Library, housing, disability support, finance and learning systems have different reasons to need information. A connected API does not justify sending every student attribute to every application. The language of permission must match the actual disclosure.
A campus app asks permission to view course enrollment but sends broad biographical details. A translated notice says only a timetable will be shared. The difference is material regardless of linguistic fluency.
The local interface should explain the situation without altering actual data minimization, access scope and lawful purpose. An institution can add glossaries, explanatory footnotes and familiar navigation, but those additions do not grant authority to change core records. The best international experience makes both the student’s options and the source of each statement clear.
A reliable review action is to compare permission text and privacy notices with transmitted payloads. Compare what the student can see with what the system actually sends and what the designated owner records.
Sensitive categories and student trust
Certain student records can be sensitive, including accommodations, financial status or personal circumstances. Translation may improve access to services, but institutions must preserve appropriate restrictions and avoid exposing sensitive data through generic dashboards.
A localized departmental view includes disability accommodation flags intended only for a designated support team. The translation is accurate, but the visibility rule is not.
For an international learner, field-level permission and privacy obligations may be invisible until something goes wrong. That is exactly why it needs protection. A translation that overstates admission, enrollment or eligibility can mislead a student in ways that a cosmetic layout error cannot. Keep human-friendly explanations beside, not instead of, the authoritative value.
The validation step is to review access under student, instructor, administrator and support roles. Have a registrar or service owner approve any wording that implies a formal academic decision.
Events, updates and eventual consistency
In distributed university systems, an update may take time to reach every service. A translated message should describe what has been submitted, acknowledged or confirmed rather than treating each intermediate state as final success.
A student drops a class and the LMS still shows it for an hour. The translated portal says the drop has failed; the actual system has accepted the request but has not synchronized the downstream view.
This distinction is easy to lose when different campus departments use the same everyday word. The correct meaning depends on the state of the source transaction and the synchronization window, not on what the term would usually mean in a dictionary. Translators should seek clarification instead of choosing a stronger institutional claim. Engineers should avoid treating translated labels as primary database keys.
To test the result, test pending and completed transitions across connected systems. Both the technical integration and the student’s understanding must agree.
Withdrawals, deferrals and historical records
An enrollment change must preserve what happened in the past as well as the student’s current status. Translation cannot rewrite previous activity to make it appear that a person never attended a course.
A learner withdraws after a midterm. The localized transcript removes all trace of the enrollment rather than showing the institution’s official record policy. That may change academic history improperly.
A useful operating rule is to preserve historical enrollment and the governing record-retention policy and expose uncertainty plainly when a downstream system has not yet confirmed a change. This is especially valuable for students moving across countries who may have no prior experience of the institution’s academic administration. A readable interface should tell them what is known and what remains pending.
Reviewers should compare before and after cases with the registrar’s rules. Look for phrases that accidentally promise an outcome before the responsible office has made it official.
Grades, assessments and release gates
A grade may be calculated in a course tool and later become official after moderation or approval. Multilingual systems must keep the release gate visible rather than describing a draft assessment as an issued academic result.
A student sees an English label ‘provisional grade’ that becomes ‘final grade’ in another language. The same underlying mark now communicates different rights and expectations.
The most robust multilingual systems separate a canonical data fact from its display language. In this example, grade status, approval state, units and scale is that fact. Better labels, examples or help text may all be valuable, but they must respect the original record and the institution that owns it. The same rule applies whether the student reads the page on a phone or through an assistive device.
As a final check, test grading before moderation, after moderation and after formal release. Record the agreed interpretation so another system does not later translate the same status in a contradictory way.
International language preferences
A student may prefer one UI language, a different course language and another language for official correspondence. Translation should respect these distinct settings rather than assuming one language choice governs all academic communication.
An international student selects an English portal but enrolls in a course taught in Japanese. A translation incorrectly changes the course’s instructional-language label to English based on the profile preference.
The stable requirement is the instructional language and actual communication settings. This is where translation stops being a matter of preferred phrasing and becomes part of safe institutional operation. A learner may make financial, academic or travel decisions based on these screens. The right words help only when they describe the actual state of the institution’s records and services.
Before approval, test mixed-language user preferences against course metadata. Use an ordinary case and an exceptional case, because apparently simple labels become ambiguous when a student is waiting for a decision or moving between institutions.
Accessibility and assistive technology
An API record can be structurally correct while its displayed terminology is inaccessible. Screen-reader labels, form validation and readable error messages are essential parts of international student access, especially at registration deadlines.
A student using a screen reader cannot distinguish the course-add button from the withdraw button because both were assigned the same translated accessible label.
The local interface should explain the situation without altering the functional meaning of every action and form status. An institution can add glossaries, explanatory footnotes and familiar navigation, but those additions do not grant authority to change core records. The best international experience makes both the student’s options and the source of each statement clear.
A reliable review action is to test keyboard access, reading order and assistive names for critical interactions. Compare what the student can see with what the system actually sends and what the designated owner records.
Error messages and support routing
A helpful local-language error should identify whether the issue is identity, enrollment, authorization, availability or synchronization. Vague messages lead staff to choose the wrong support team and may encourage unsafe workarounds.
An API permission failure appears as ‘course does not exist’ in a translated app. The student contacts the academic department when the fix belongs to account authorization.
For an international learner, the actual error category and safe remediation path may be invisible until something goes wrong. That is exactly why it needs protection. A translation that overstates admission, enrollment or eligibility can mislead a student in ways that a cosmetic layout error cannot. Keep human-friendly explanations beside, not instead of, the authoritative value.
The validation step is to map known error states to clear authorized next steps. Have a registrar or service owner approve any wording that implies a formal academic decision.
API version and documentation boundaries
Because Edu-API’s public status is Candidate Final Public, teams should confirm the exact version and actual implementation profile they are using. An article or translation must not invent required schema properties or promise compliance from an overview alone.
A procurement checklist quotes field names from an unofficial prototype as if they were mandatory final requirements. Vendors respond inconsistently, and the institution mistakes the difference for a localization defect.
This distinction is easy to lose when different campus departments use the same everyday word. The correct meaning depends on the exact adopted specification, access rights and supported vendor contract, not on what the term would usually mean in a dictionary. Translators should seek clarification instead of choosing a stronger institutional claim. Engineers should avoid treating translated labels as primary database keys.
To test the result, check authoritative documents, release notes and conformance evidence before technical sign-off. Both the technical integration and the student’s understanding must agree.
Cross-border institutional partnerships
Joint degrees, exchange programs and visiting-student arrangements involve more than a translated catalog. Different institutions may own admission, credit, assessment or record issuance. A localized integration should make each responsibility visible.
A student completes a partner-campus module. The host institution records attendance, while the home university decides credit recognition. A translated portal says credit has automatically transferred when the decision is still pending.
A useful operating rule is to preserve which institution makes each academic decision and expose uncertainty plainly when a downstream system has not yet confirmed a change. This is especially valuable for students moving across countries who may have no prior experience of the institution’s academic administration. A readable interface should tell them what is known and what remains pending.
Reviewers should test partnership scenarios with both registrars and actual approval records. Look for phrases that accidentally promise an outcome before the responsible office has made it official.
Long-term governance and change control
A multilingual campus integration evolves as catalogs, policies and software change. A sustainable approach records ownership of field meanings, authorized translations, version boundaries and acceptance tests so one change does not silently corrupt others.
A university renames a department and updates the prospectus but not its program interfaces. Different translated systems now imply different awarding authorities, causing confusion for applicants and graduates.
The most robust multilingual systems separate a canonical data fact from its display language. In this example, the current authoritative record and historical provenance is that fact. Better labels, examples or help text may all be valuable, but they must respect the original record and the institution that owns it. The same rule applies whether the student reads the page on a phone or through an assistive device.
As a final check, audit related services whenever names, programs or policy statuses change. Record the agreed interpretation so another system does not later translate the same status in a contradictory way.
A connected campus example from admissions to learning
Consider a student who applies to a joint program from another country, receives an offer, accepts a place, registers for a module and later uses an LMS and library service. The university’s record ecosystem may involve admissions, a student information system, the module catalogue, enrollment processes, identity management, a course LMS and service providers. Each system has legitimate reasons to show certain data. None should silently rewrite the authoritative decision made by another. The translated admissions screen must distinguish an offer from confirmed registration. The course catalogue must preserve the module code, actual instructional language, credit unit and prerequisites. The LMS should reflect enrollment according to the institution’s integration rules.
Now introduce two complications. First, the student changes their name after the admission offer. A robust system updates it through the authorized process and maintains the relationship with the same student identity; a translated web page does not invent new identifiers. Second, the student is waitlisted for a lab section while officially enrolled in the lecture section. The localized timetable must show those distinct states, not collapse both into ‘enrolled’. Even flawless machine integration can mislead when the interface erases the difference.
A sensible acceptance exercise follows the student from one system to the next. A registrar confirms official status words; a teacher confirms course activity and assessment labels; a privacy representative confirms which services may see which data; a multilingual student tester explains what each screen permits them to do. This is not merely checking whether a button fits the interface. It is checking whether connected campus information is understood correctly by the people whose decisions depend on it.
Frequently asked questions
Is Edu-API a final 1EdTech standard today?
As of the public overview checked in October 2026, 1EdTech identifies it as Candidate Final Public. Implementers should verify later status changes directly rather than relying on a permanently frozen label in an article.
Can a translator rename API keys?
Not as an ordinary language-editing task. Machine-facing fields, identifiers and contracts must match the adopted implementation. Human-readable labels and guidance should be localized at an appropriate display layer.
Does Edu-API replace the SIS or LMS?
The standard aims to support exchange among enterprise education systems. The actual systems of record, business rules and integration architecture remain institutional implementation decisions.
Can a multilingual student portal convert credits automatically?
Only where the institution has approved an actual conversion or equivalence. The source credit value and unit should remain clear, and the receiving authority decides credit recognition.
Should every campus service receive all student information?
No. API connectivity does not remove the need for authorization, data minimization, privacy review and an appropriate purpose for each disclosure.
What makes a translation test successful?
The same representative student, course, enrollment and result should retain the same substantive identity and status in every language. A user should understand what action is available, what is provisional and who owns the official decision.
Official sources and connected education infrastructure
Refer to the 1EdTech Edu-API public overview and the 1EdTech Edu-API specification portal (sign-in may be required). For related but distinct responsibilities, read LTI 1.3 learning-tool launches, Common Cartridge course packages, CASE competency frameworks and CLR 2.0 learning credentials. These standards address related parts of an education ecosystem, but none authorizes changing official institutional records through translation.