Why you’re reading this
You’ve been given an API key to access one or more University of Oregon APIs. This short agreement covers what you can do with it, what you’re responsible for, and what happens if something goes wrong. It’s written for developers, not lawyers — if anything here is unclear, reach out (contact info at the bottom).
By requesting, accepting, or using an API key issued by UO Information Services, you agree to the terms below. If you’re requesting a key on behalf of your department or organization, you’re confirming you have the authority to agree to this on their behalf too.
1. This key is scoped to your specific use case
Your API key gives you access to a specific set of endpoints, for a specific application or integration — the one you described when you requested it. It’s not a general-purpose credential.
- Use it only for the use case it was approved for.
- If you want to use it for something new (a different app, a new integration, a broader scope), ask us first. It’s a quick conversation, not a big process — we’d just rather know what’s touching our APIs.
- Don’t assume access to an endpoint implies access to related or similar endpoints you weren’t explicitly granted.
2. Keep it inside your use case — don’t expose it more broadly
Whatever you build with this key should stay within the boundaries of what you told us you were building.
- Don’t repurpose data pulled through the API for a different product, report, or audience than what was approved.
- Don’t make the underlying data more widely available than it already is (for example, don’t take restricted data and republish it somewhere public or less controlled).
- If your use case is going to grow beyond what you originally requested, let us know so we can make sure the access level still makes sense.
3. Don’t share your key for other applications
Your key is tied to your specific application, not to you as a person and not to your team in general.
- Don’t reuse the same key across multiple unrelated apps or scripts. If you’re building something new, request a new key for it.
- Don’t hand your key to a teammate to use in their own project, even if it’s a similar one — they should request their own.
- Don’t hardcode it into client-side code, commit it to a public repo, paste it into a shared doc/Slack channel, or otherwise leave it somewhere someone else could grab it.
- If a key does leak or get exposed, tell us right away so we can rotate it. This happens — we’d much rather hear about it fast than find out later.
4. You own this key — including keeping it current
Whoever requests a key is the person responsible for it. That means:
- Annual check-in. Once a year, we’ll reach out to confirm you’re still using the key and still need it. Please respond — it helps us keep things clean and avoid orphaned access sitting around unused.
- If your role changes. If you’re moving to a new position, leaving the team, or otherwise handing off the project this key supports, let us know who’s taking over responsibility for it. We’ll transfer ownership rather than leave it in limbo.
- If you no longer need it. Tell us and we’ll deactivate it. Unused keys are a security risk for everyone, so don’t just let one sit idle “just in case.”
5. A note on sensitive data
Some UO APIs return data that’s more sensitive than others — student records, HR data, financial data, and so on (generally anything covered by FERPA or similar privacy rules). If your key includes access to endpoints like these:
- Only use that data for the approved purpose — don’t repurpose it for something else without checking with us first.
- Don’t store, export, or pass it along to systems or third parties we haven’t approved.
- Take reasonable care to keep it secure (don’t leave it in unsecured logs, spreadsheets, unencrypted backups, etc.).
- If you think there’s been a breach or unauthorized access involving this data, tell us immediately — within 24 hours if at all possible.
- When your project wraps up, or you no longer need the data, delete it.
If you’re not sure whether the data behind your key falls into this category, just ask — we’ll tell you.
6. Playing nice with our systems
- Stay within any rate limits or usage thresholds we’ve documented for your key. If you’re consistently hitting limits, talk to us about adjusting them rather than working around them.
- Don’t do anything designed to get around authentication, monitoring, or security controls.
- Don’t hammer our systems with excessive traffic, scraping, or bulk extraction beyond what your use case actually needs.
7. Things we don’t allow
To keep this simple: don’t use your key to access data or endpoints beyond what you were granted, don’t try to disguise or misrepresent what application is making requests, and don’t use UO data to build something that competes commercially with UO services without talking to us first.
8. We’re watching (in a good way)
We log and monitor API traffic for security, performance, and troubleshooting purposes. This isn’t about distrust — it’s how we catch problems (compromised keys, runaway scripts, capacity issues) quickly. We may also periodically check in on how a key is being used, similar to the annual review above.
9. We can pause or revoke access
We may suspend or revoke your key if:
- It looks compromised or is being misused.
- It hasn’t been used or confirmed in a long time (see the annual check-in above).
- Your use case is discontinued, or your role/affiliation with UO changes and no one takes over ownership.
- The underlying API is being changed, deprecated, or retired.
Where we can, we’ll give you a heads-up first. In urgent situations (like a suspected security issue), we may need to act immediately and follow up after.
You can also deactivate your own key any time — just let us know.
10. Service availability
We do our best to keep APIs up and running, but we don’t guarantee zero downtime, and we may need to do maintenance from time to time. We’ll try to give notice for planned changes, especially anything that could break your integration.
You should craft your application to handle API outages and errors gracefully, since they will occur regularly due to maintenance and infrastructure upgrades.
11. The standard legal disclaimer
APIs and data are provided “as is,” without warranties of any kind. UO isn’t liable for indirect or consequential damages arising from your use of the APIs, to the extent allowed by law. Nothing here overrides any protections the University of Oregon or the State of Oregon has under Oregon law (including the Oregon Tort Claims Act). This agreement is governed by Oregon law.
12. Questions or issues?
Reach out any time — for new access requests, questions about scope, or to report a lost/exposed key.