How to export Opsgenie schedules, escalation policies and users with the API

Atlassian stopped selling Opsgenie to new customers on 4 June 2025. Support ends on 5 April 2027. On that date access shuts off and unmigrated data is deleted.

The Opsgenie REST API keeps working until then. Everything below is a GET request. Nothing is modified. Exporting takes about ten minutes and de-risks every later decision, whether you move to Jira Service Management, another pager, or folding paging into monitoring.

Create the right API key first. Then dump users, schedules, escalation policies, and integrations. Keep the JSON files with your runbooks.

Create an API key with configuration access

You need a valid API key before running any export commands. The key determines what data you can read. A standard read-only key is not enough for schedules, escalations, or users.

Go to Settings -> App settings -> API key management -> Add new API key.

Opsgenie keys have four access rights:

• Read
• Create/Update
• Delete
• Configuration Access

Schedules, escalations, users, and integrations fall under Configuration Access. A key with only Read permission returns HTTP 403 on those endpoints. Tick Read and Configuration Access. Leave Create/Update and Delete unticked.

Do not use an integration API key. These are the keys inside an “API” integration. They are often restricted to alert data only. A team integration key only sees that team’s objects. You need the global API key from the settings page.

The header for all requests is Authorization: GenieKey <key>.

You must send the key to the correct host. US accounts use https://api.opsgenie.com. EU accounts use https://api.eu.opsgenie.com. A key sent to the wrong host returns 401. Check your account region before proceeding.

Paste the key into the YOUR_KEY placeholder in the commands below.

Dump users and check for blocked accounts

Run the following command to fetch the first page of users. The API returns a maximum of 100 records per request.

curl -s 'https://api.opsgenie.com/v2/users?limit=100&offset=0' \
  -H 'Authorization: GenieKey YOUR_KEY' > users-0.json

The response contains a data array. Each object includes id, username (the email address), fullName, role, timeZone, blocked, verified, and createdAt.

Pagination uses offset and limit. The response body includes totalCount and a paging.next URL if more pages exist. Repeat the request with offset=100, then 200, and so on. Stop when the data array is shorter than the limit value.

Check the blocked field for every user. A value of true means the person can no longer log in. These accounts still appear in active schedules. Note them immediately. You will need to remove or replace these entries in the new tool to avoid stale assignments.

Save the JSON file. You will need the id and username fields when mapping users to the new platform.

Export schedules and note rotation layers

Schedules define who is on call and when. Export them with the expand=rotation flag. This flag includes the rotation details in the response. Without it, the list omits the rotation data you need to rebuild the schedule.

curl -s 'https://api.opsgenie.com/v2/schedules?expand=rotation' \
  -H 'Authorization: GenieKey YOUR_KEY' > schedules.json

The list endpoint has no pagination. The response contains all schedules in one payload. Each schedule object includes id, name, timezone, enabled, ownerTeam, and rotations. The timezone field uses an IANA name like Europe/London.

Each schedule can have multiple rotations. Rotations are layered. The last rotation in the list wins where they overlap. Write down the order of rotations for each schedule. This order determines who gets the alert.

Each rotation has a name, type, length, startDate, and participants. The type is daily, weekly, or hourly. The length is a hand-off multiplier. A weekly rotation with length 2 hands off every two weeks. Participants can be users, teams, escalations, or none. A none participant is a deliberate gap in the rotation. User participants carry username (the email) and id.

Rotations can have a timeRestriction. This restricts when the rotation is active. The type is time-of-day or weekday-and-time-of-day. Each restriction has startDay, startHour, startMin, endDay, endHour, and endMin.

Overrides are not in this payload. They live in the schedule timeline. Fetch them with GET /v2/schedules/{id}/timeline. Overrides are temporary. Most teams recreate them by hand in the new tool. Focus on the base rotations first.

Save the JSON file. You will need the schedule id and rotation details when mapping to the new platform.

Pull escalation policies and delay rules

Escalation policies define the sequence of notifications when an alert fires. They link users, schedules, and teams into a repeatable loop. Export them before the API closes.

Run this command to fetch all policies:

curl -s 'https://api.opsgenie.com/v2/escalations' \
  -H 'Authorization: GenieKey YOUR_KEY' > escalations.json

Each policy object contains id, name, description, ownerTeam, rules, and repeat. The rules array defines the notification sequence. Each rule has a condition (if-not-acked or if-not-closed), a notifyType, a delay, and a recipient.

The recipient type can be user, schedule, or team. The delay object specifies timeAmount and timeUnit (minutes). Delays are absolute. They count from alert creation, not from the previous rule firing. A rule with timeAmount 0 fires immediately. A rule with timeAmount 25 fires 25 minutes after the alert was created.

The repeat object controls how the policy loops. It has waitInterval (minutes to wait before running the rules again), count (how many times to repeat), resetRecipientStates, and closeAlertAfterAll.

Map these rules to your new platform. Note the absolute delays. If you move to a system that calculates delays relative to the last step, you must adjust the numbers. Record the ownerTeam for each policy. You will need to assign ownership in the new tool.

Check the repeat settings. If count is high, the new tool might handle retries differently. Document the intended behavior.

Save the escalations.json file. You will need the rule sequence and delay values when configuring the new on-call workflow.

List integrations to find live webhooks

Every enabled integration in Opsgenie is a webhook, email address, or API key that some monitoring tool or script sends alerts to. When Opsgenie shuts down, every one of them breaks at once. List them now so you know what to repoint.

Run the following command to export the full list of integrations:

curl -s 'https://api.opsgenie.com/v2/integrations' \
  -H 'Authorization: GenieKey YOUR_KEY' > integrations.json

The response contains an array of integration objects. Each object includes id, name, enabled, type, and teamId. Filter on the enabled field. Enabled integrations are live. Disabled integrations are usually dead tools or old configurations that no longer receive traffic.

Review the enabled entries against your current monitoring stack. For each live integration, note the source system (e.g., Prometheus, Datadog, AWS CloudWatch, or a custom script). You will need to update the webhook URL in those source systems to point to your new on-call platform.

Filter by type or teamId if you need to narrow the scope. For example, add ?type=Prometheus to the API URL to see only Prometheus integrations. Add ?teamId=<team-id> to see integrations specific to a team.

Disabled integrations are generally safe to ignore. They do not receive alerts and do not need immediate action. Keep the full integrations.json file anyway; it is the only list of what was ever wired in.

Save the integrations.json file. You will need the list of live webhooks to configure the new on-call workflow. Update the webhook URLs in the source monitoring tools before the Opsgenie API closes.

Sanity check the JSON exports

Run the jq commands against the downloaded files. This catches pagination errors, missing fields, or silent failures before you close the Opsgenie window.

Check users first. The command below prints the username, full name, and blocked status as tab-separated values. Look for rows where the blocked column is true. These accounts can no longer log in but may still be active in your schedules. Mark them for cleanup in the new tool.

jq -r '.data[] | [.username, .fullName, .blocked] | @tsv' users-0.json

Verify the schedule list. The command outputs the schedule name, timezone, and enabled status. Confirm that the timezone matches your team’s location and that the enabled flag is true for the schedules you still use. The API response does not paginate the schedule list, so a single file should contain all of them.

jq -r '.data[] | .name + " (" + .timezone + ", enabled=" + (.enabled|tostring) + ")"' schedules.json

Review the escalation policies. The command lists each policy name followed by its rules. Check the delay times and recipient types. Delays are absolute from alert creation, not from the previous rule. A delay of 0 means immediate notification. Check that the recipient types (user, schedule, team) are what you expect.

jq -r '.data[] | .name + ": " + ([.rules[] | (.delay.timeAmount|tostring) + "m " + .recipient.type] | join(", "))' escalations.json

Finally, list the enabled integrations. This command filters for only the active integrations and prints the type and name. These are the webhooks you need to repoint in your monitoring tools. Disabled integrations are likely dead tools and can be ignored for now.

jq -r '.data[] | select(.enabled) | .type + "\t" + .name' integrations.json

Import into AlertKick or store for later

You have four JSON files and a text note. Store them with your runbooks. Do not leave them in a personal download folder. This data de-risks the migration whether you end up on Jira Service Management, another pager, or fold paging into your monitoring. The background on that decision is in the Opsgenie end-of-life guide.

If you choose AlertKick, the import path is Admin -> Import. The importer reads the same three endpoints you just queried: users, schedules, and escalations. It shows a preview of what it would create before writing anything.

The preview maps Opsgenie users to AlertKick users by email. It maps schedules to rosters, including the hand-off length. It maps escalation policies to escalation policies and converts the absolute delays to per-level timeouts. Every item that cannot map one to one carries a note. Review the mapping, then press Import.

If you do not use AlertKick, the JSON files serve as the source of truth. Keep the rotation layer order in your text note. The API does not return the effective rotation order; it returns the raw layers. The last rotation in the list wins where they overlap. Write down which layer is on top for each schedule. You will need this when you rebuild rotations in the new tool.

Keep the integrations list. Every enabled integration is a webhook in a monitoring tool that must be repointed. Disabled integrations are usually dead tools. Ignore them for now.

The API keeps working until 5 April 2027. At that date, access shuts off. Atlassian’s guidance says unmigrated data is deleted. Exporting now takes about ten minutes. It buys time to decide on the next platform. It buys time to rebuild the rotations by hand if needed.

The related guide on what the deadline means is at /blog/opsgenie-end-of-life-migration-guide/. The migration tool is at /migrate/.