Getting an Opsgenie API key takes about a minute once you know which of the two credentials you actually need and where each one lives. This guide covers both, including the GenieKey authorization format that trips up most first requests.

There is also a deadline you should factor into anything you build. Atlassian is shutting Opsgenie down on April 5, 2027, and unmigrated data will be deleted at that point. That does not mean your integration work today is wasted, but it does change how much of it is worth automating and how you should structure what you build. Both topics are covered below.

The two credentials called an Opsgenie API key

Like most alerting platforms, Opsgenie separates the credential that manages configuration from the credential that sends alerts in. Using the wrong one produces an authorization failure that does not explain itself.

API key, for configuration and data access

This is the account level credential, managed from the API Key Management tab in Settings. It is not tied to any integration. You use it to read and write configuration: users, teams, schedules, escalation policies, and alert data. Account owners and global admins can generate one.

This is what you want if you are building anything that reads on-call schedules, syncs users, or exports alert history.

Integration API key, for sending alerts in

This belongs to a specific API integration rather than the account. You create it under Settings, then Integrations, by searching for API and selecting it. Name the integration, save it, then expand the configuration steps to copy the key.

This is the credential your monitoring tools need. It sends alerts into Opsgenie and routes them according to that integration's rules. It cannot manage your account configuration.

The GenieKey header, which catches everyone

Opsgenie does not use Bearer and does not use a plain token. It expects its own prefix:

curl -H "Authorization: GenieKey YOUR_API_KEY" \
     "https://api.opsgenie.com/v2/alerts?limit=1"

If your first request returns an authorization error and the key is definitely correct, this is almost certainly why. The GenieKey prefix is unusual enough that people reflexively write Bearer and lose twenty minutes to it.

Note also that accounts provisioned in the EU region use a different API base host. If you are getting consistent failures on a key you know is valid, confirm which region your account lives in before you start regenerating credentials.

How to create an Opsgenie API key

You need account owner or global admin rights. If you do not see the tab described here, that is the reason.

Open Settings, then the API Key Management tab.
Add a new API key and give it a name you will recognise later. Name it after the system that will consume it, not after yourself.
Select the access rights the key should carry. This is the step most people rush, and it is the one that matters.
Save, then copy the key immediately and store it in your secret manager.

Scoping access rights properly

Opsgenie splits key permissions into configuration access plus a set of operation rights covering read, create and update, and delete. A key needs both the relevant configuration access and the matching operation right to do anything.

The practical guidance is the same as for any alerting platform. Grant read only unless you have a concrete reason not to. The large majority of integrations only read: on-call dashboards, Slack bots answering who is on call, schedule exports, reporting. Granting delete rights to a key that only ever runs GET requests buys you nothing and costs you a genuinely bad day if the key leaks.

Create one key per consuming system rather than one shared key for everything. Shared keys cannot be rotated safely, because nobody can enumerate what will break when you revoke one.

How to create an integration API key

Go to Settings, then Integrations.
Search for API and select the API integration type.
Give the integration a name that identifies the source system, for example "Prometheus prod" rather than "API integration 3".
Save, expand the configuration steps, and copy the API key.

One integration per source system, again. When a noisy source needs cutting off at 2am, you want to disable one integration rather than untangle a shared credential.

Errors you will actually hit

Opsgenie's error responses are more informative than most, but a few failure modes still look identical from the outside.

Authorization failure on a key you know is right: almost always a missing or wrong GenieKey prefix, or an account in the EU region being called against the default host.
Permission denied on a specific operation: the key has configuration access but not the matching operation right. Read access does not imply create or delete access, and they are granted separately.
An integration key rejected by a configuration endpoint: you used the per-integration key where an account API key belongs. They are not interchangeable.
Alerts accepted but not reaching anyone: the credential is fine and the alert was created. The problem is routing rules or the escalation policy attached to that integration, so check the alert exists in the UI before touching the key.
Rate limiting under bulk operations: Opsgenie throttles per key. If you are backfilling or running a bulk sync, add backoff rather than parallelising harder.

Rotating and revoking keys

Rotate with overlap, never by deletion. Create the replacement key first, deploy it everywhere, confirm it is working, and only then remove the old one. Deleting first and fixing forward is how teams discover at 3am that a key was doing something nobody documented.

User offboarding deserves a specific mention. Keys created by someone who has left do not stop working when their account is deactivated, and they are easy to miss because nothing surfaces them during an access review unless you go looking. Add a check of API Key Management to your offboarding runbook, and name keys after systems rather than people so an orphaned key is obvious at a glance.

The April 2027 deadline, and what it actually means

This is the part that should shape your decisions, so here are the confirmed specifics rather than the rumour version.

What Atlassian has stated

End of sale was June 4, 2025. New organisations can no longer sign up. Existing customers can no longer change Opsgenie edition (Essentials to Premium, or Premium to Enterprise) or add new sites. Buying additional seats remains possible until end of support.
End of support is April 5, 2027. At that point Opsgenie is shut down and the product is no longer accessible.
Unmigrated data is deleted. Any customer data still in Opsgenie at shutdown goes away. This is the detail worth circling.
The destination is Jira Service Management. Atlassian has moved Opsgenie's alerting and on-call capabilities there, and provides an automated migration tool.
You get 120 days of parallel access. After migrating, Opsgenie stays available alongside Jira Service Management so you can validate the setup before committing.
A demo migration is available. You can trial the migration workflow before moving any real data.

Opsgenie owners can find their recommended path under Settings, then Plan your move, which generates a recommendation from your actual usage. If you move before your existing subscription ends and have more than 30 days remaining, you are offered an equivalent extension on the destination product.

Data Center customers have a different path

If you run Jira Service Management Data Center, you cannot simply move Opsgenie across. The routes are either moving Jira Service Management Data Center to Cloud first and then moving Opsgenie, or moving your Opsgenie instance to a new Jira Service Management Cloud site. Both need to complete before the same April 2027 date, and both are meaningfully larger projects than a straight Opsgenie migration. If this is you, start scoping considerably earlier than you think you need to.

What this means for integrations you build today

A shutdown date does not mean stop working. It means be deliberate about what you invest in, because some of this work carries over and some of it evaporates.

Build the boring, portable version

Anything that reads schedule or on-call data and pushes it somewhere useful should be written against a thin internal abstraction rather than directly against Opsgenie's response shapes. One small module that knows how to answer "who is on call for team X right now" is straightforward to repoint at a different provider later. Two hundred lines of Opsgenie specific parsing spread across five scripts is not.

This is good practice regardless of the deadline. The deadline just converts it from good practice into scheduled work you have already been given the date for.

Do not over invest in deep configuration automation

Elaborate Terraform or scripted management of Opsgenie escalation policies and schedules has a known expiry. If you are choosing between building that now or waiting until you know your destination platform, waiting is usually correct. Migration will rewrite the underlying objects anyway.

Treat alert routing as the stable layer

The integration keys your monitoring tools use are the easiest part to repoint. Each source system has one URL and one credential. When you migrate, you swap those. Keeping one integration per source, as recommended above, is precisely what makes that swap a checklist rather than an archaeology project.

Your migration options, honestly assessed

There are broadly three directions, and the right one depends on what you were using Opsgenie for.

Move to Jira Service Management

The default, and genuinely the path of least resistance if you already live in the Atlassian ecosystem. The migration is automated, your data and configurations come across, and you get the parallel access window to validate. If your team already runs Jira and Confluence, and you want ITSM alongside alerting, this is the sensible choice and you should start with the demo migration.

Rethink the model rather than port it

A forced migration is an unusually good moment to ask whether you should be recreating what you had. Plenty of teams adopted Opsgenie for one capability, reliable phone and SMS paging, and then inherited a large surface of scheduling, escalation and configuration they never really wanted.

If that describes you, porting all of it to a new platform means carrying complexity you could have dropped. Worth auditing what you actually use before you migrate it.

Split paging from day to day on-call

This is the pattern more teams are landing on, and it is worth understanding even if you end up somewhere else. Keep a dedicated paging tool for the narrow job it does well, waking someone at 3am, and move the daily operational surface into the place your team already works, which for most engineering teams is Slack.

Rotations, handoffs, overrides, swaps, knowing who is on call, routing a ticket to whoever is currently on rotation: none of that needs a separate product with its own login. It needs to be where the conversation already is. That is the case for a Slack-native approach, and it is a genuinely different question from which paging vendor you pick.

A migration checklist worth running

Whatever destination you choose, these steps apply and most of them are easy to forget under time pressure.

Inventory your integration keys. List every source system sending alerts in, and which integration each uses. This becomes your repointing checklist.
Inventory your API keys. Check API Key Management for keys nobody recognises. Anything unidentifiable is either dead or an undocumented dependency, and you want to know which before you migrate.
Export your schedules. Even with an automated migration, having your own copy of who was on call when is worth the ten minutes. Historical on-call data is surprisingly hard to reconstruct later.
Document your escalation logic in plain language. Not the config, the intent. "Payments pages the primary, then the secondary after 10 minutes, then the engineering manager" survives any platform change. The exported JSON does not help you rebuild intent.
Run the demo migration first. It exists precisely so you can find surprises before they matter.
Use the full parallel access window. 120 days is enough to cover a real on-call cycle including a holiday period. Do not cut it short because the migration looked fine on day three.
Verify notification delivery specifically. Everything else can be checked visually. Whether a phone actually rings at 3am cannot, so test it deliberately on real devices.

If you are rethinking rather than just porting

Should the audit suggest you want alerts and paging in one place but rotations, handoffs and ticket routing in Slack, that split is straightforward to run. The paging tool keeps its integration keys and does its narrow job. A read-only API key bridges the schedule data out to Slack, where the on-call name lives in a channel topic, @oncall resolves to whoever is actually on rotation, and swaps happen in a conversation rather than a separate admin console.

Pagerly does that side of it, and our guide to retrieving an Opsgenie API key walks through generating the key and connecting it, which also works as a general reference for the steps above.

Key takeaways

Two credentials share the name. Account API keys live in Settings under API Key Management. Integration API keys belong to an individual API integration.
Opsgenie uses Authorization: GenieKey YOUR_KEY, not Bearer. This causes most first request failures.
Keys need configuration access plus the matching operation right. Grant read only unless you have a specific reason.
End of sale passed on June 4, 2025. End of support is April 5, 2027, after which Opsgenie shuts down and unmigrated data is deleted.
Migration to Jira Service Management is automated, with 120 days of parallel access and a demo migration available first.
Data Center customers face a longer path and should start scoping now, not in 2027.
Write integrations against a thin internal abstraction so repointing later is a small change.
Audit what you actually use before migrating it. A forced move is a good moment to drop complexity rather than carry it across.

The deadline is far enough away to plan properly and close enough that teams who ignore it until late 2026 will be doing it badly, in a hurry, with their alerting in the balance. Get your key inventory done now, because that part is useful immediately and it is the piece everyone wishes they had when the migration window opens.