The Reactor API (formerly the Adobe Launch API) is Adobe's REST interface for managing every resource inside Adobe Experience Platform Tags, properties, rules, data elements, extensions, libraries, and publishing environments, without touching the UI. It lives at reactor.adobe.io, authenticates through Adobe I/O OAuth Server-to-Server, and exposes roughly 20 resource types that match what you see in the AEP Tags console.
What if every rule in your AEP Tags property could be version-controlled, peer-reviewed in a pull request, and deployed by a CI pipeline, the same way you already ship application code?
That's what the Reactor API lets you do. If you've ever clicked through 47 rules to change one Data Element reference after a site redesign, you already know why this matters. The UI is fine for low-volume work. It breaks down the moment you have 100-plus rules, three properties, or a migration deadline.
Below I'll cover what the Reactor API actually does in 2025, how authentication works after Adobe's JWT sunset, which resources you need to understand, and the use cases where this API pays for itself in the first engagement. I've used the Reactor API on audits, Adobe Launch to AEP Tags migrations, and tag management CI/CD setups for European mid-market teams since 2022.
Key Takeaways
The Reactor API is the same API as the old Adobe Launch API, renamed when Adobe rebranded Launch to AEP Tags in 2021. The endpoint (reactor.adobe.io) and most resource shapes stayed identical, so existing integrations didn't break
As of early 2025, JWT authentication is fully deprecated. All Reactor API integrations must now use OAuth Server-to-Server credentials from the Adobe Developer Console
Rate limit is 120 requests per minute per integration, with a 10-second retry-after header on 429 responses. The official @adobe/reactor-sdk Node.js client handles throttling automatically
Typical use cases that justify the API investment: property backup and restore, bulk rule migration (200-plus rules), CI/CD publishing pipelines, automated audits across multiple brand properties
The API costs nothing extra, it's included with any Adobe Experience Platform Tags license. What it costs is engineering time to set up authentication, error handling, and testing against a non-production property
What the Reactor API Actually Is
AEP Tags, the tool formerly known as Adobe Launch, is a tag management system with a three-environment publishing workflow (Development, Staging, Production), an extension marketplace, and a rule engine built on Data Elements and Rule Components.
The Reactor API is the REST interface behind that UI. Every click you make in the AEP Tags console eventually becomes an API call to reactor.adobe.io. When you create a rule, you're POSTing to /properties/{id}/rules. When you publish a library, you're PATCHing a Build resource. The UI is a client. The API is the source of truth.
From Adobe Launch API to Reactor API
Adobe launched the tool as "Launch by Adobe" in 2018. The API was always internally called "Reactor", you can see it in the endpoint and in the official Node.js SDK (@adobe/reactor-sdk), both of which predate the rebrand. In 2021, Adobe moved Launch under the Experience Platform umbrella and renamed the product to "Tags in Adobe Experience Platform", usually shortened to AEP Tags.
The API name didn't change. Documentation, SDKs, and endpoints all still say Reactor. If you inherit a codebase that imports @adobe/reactor-sdk, that's a Reactor API (AEP Tags API) integration.
The practical implication: searching for "Adobe Launch API documentation" today will send you to outdated forum posts. Search for "Reactor API" to find current Adobe docs at developer.adobe.com.
What You Can Actually Do With It
The API exposes every AEP Tags resource type you see in the UI, plus a few administrative ones:
- Properties: the top-level container for a site or app. One property per domain is typical.
- Rules: the if-this-then-that logic (events + conditions + actions).
- Data Elements: reusable variable definitions (page name, user ID, cart value).
- Extensions: installed modules (Adobe Analytics, Web SDK, Google Analytics 4, custom extensions).
- Rule Components: the individual events, conditions, and actions attached to a rule.
- Libraries: the deployable bundle of rules, data elements, and extensions.
- Environments: Development, Staging, Production per property.
- Builds: the compiled artifact that gets deployed to an environment.
- Hosts: where libraries are served from (Adobe-managed or self-hosted on your CDN).
- Callbacks: webhooks for build status notifications.
You can list, create, update, delete, and in most cases revise any of these. That covers 95% of what you would want to automate.
How Reactor API Authentication Works
This is the section that trips up most teams, because Adobe changed the authentication model in 2024-2025.
Old way (deprecated): JWT-based Service Account credentials. If you had a Reactor API integration built before 2024, it almost certainly used JWT. Adobe sunset JWT authentication for all Experience Platform APIs as of January 1, 2025. If your integration broke silently in early 2025, this is the most likely cause.
Current way: OAuth 2.0 Server-to-Server credentials, issued from the Adobe Developer Console.
The setup flow:
- Go to console.adobe.io and create a Project.
- Add the Adobe Experience Platform Tags API to the project (still labeled with the Reactor icon).
- Choose OAuth Server-to-Server as the credential type.
- Assign the integration to a Product Profile that has AEP Tags access in your Adobe Admin Console organization.
- You receive a Client ID, Client Secret, Organization ID, and scope list.
- Exchange these for a short-lived access token (24 hours) at ims-na1.adobelogin.com/ims/token/v3.
- Include the access token, Client ID, and Organization ID in every Reactor API request header.
A production integration refreshes the access token before each batch of API calls, or on demand when it gets a 401 response. The official SDK handles this automatically if you pass in the OAuth credentials.
Important permissions note: the user or service account attached to the integration must have access to the specific Property you're calling. "Developer" role on the Property is enough for read and most write operations. "Approver" role is required to publish to Staging or Production.
Core Reactor API Resources You Will Actually Use
Most real-world Reactor API work touches four or five resources, not all twenty. Here is what you need to know about each.
Properties
GET /properties/{PROPERTY_ID} returns the metadata for a single AEP Tags property. You will use this to confirm your integration has access, and to list the Extensions installed on the property.
Properties have a platform field (web or mobile), a domains array (the sites this property serves tags on), and a rule_component_sequencing_enabled flag (important for race condition debugging).
Rules
GET /properties/{id}/rules returns all rules in a property, paginated. The Reactor API paginates by 25 results per page by default, 100 maximum. For properties with 100-plus rules, always include pagination logic.
A rule has a name, description, and enabled flag at the top level. The actual trigger and action logic lives in the attached Rule Components, which are a separate resource.
Rule Components
GET /properties/{id}/rules/{rule_id}/rule_components returns the events, conditions, and actions for a single rule. This is where you'll spend the most API time if you're auditing or migrating.
A rule component has a delegate_descriptor_id (which references an Extension), a settings field (the configured values, as a JSON string), and a rule_component_type of events, conditions, or actions.
Data Elements
GET /properties/{id}/data_elements returns all Data Elements. Each has a settings JSON blob that depends on the Data Element type (DOM attribute, JavaScript variable, Local Storage, etc.). Updating Data Element settings is the single most common bulk operation I run through the API.
Libraries and Builds
A Library is a collection of rules, data elements, and extensions you want to deploy together. A Build is the compiled output of a Library.
POST /properties/{id}/libraries creates a library. You then attach resources to it via /libraries/{id}/relationships/rules (and similar endpoints). Then POST /libraries/{id}/builds to compile. Then transition the library through the states: development → submitted → approved → published.
This is how a CI/CD pipeline triggers a publish. No UI click required.
Want to see if API automation makes sense for your AEP Tags setup? Get in touch for an honest assessment. If the answer is "you're fine with the UI", I'll tell you straight.
Practical Use Cases That Justify the API
The Reactor API is powerful, but it's not always the right tool. Here are the four use cases where the API investment has paid off for teams I've worked with.
Use Case 1: CI/CD for Tag Management
When Marek, a lead developer at a Polish fintech, took over his company's AEP Tags property in March 2025, the publishing workflow was pure chaos. Any analyst with "Approver" role could push directly to Production. There was no changelog, no peer review, and no way to roll back a bad rule except to revert manually.
We set up a Reactor API pipeline over three weeks. Every rule change now lives in a Git repository as a JSON file. A GitHub Actions workflow validates the rule structure, diffs it against the current property via API, runs a dry-run build against a Staging environment, and opens a pull request with the results. A second analyst reviews the PR. On merge, the workflow PATCHes the live rule and publishes a Staging library. A human still clicks the Production promotion button in the UI, we intentionally kept that gate manual.
Six months in, the team has had zero Production incidents from bad tag deploys. Before the pipeline, they averaged one bad deploy per quarter.
Use Case 2: Mass Migration (Launch to AEP Tags, or Between Properties)
Agnieszka, a martech architect at a European retail group, needed to migrate a 340-rule property from one Adobe Organization to another after a corporate restructuring in 2025. The AEP Tags UI doesn't support cross-organization property cloning. Agencies quoted EUR 40,000 for a manual rebuild.
We wrote a 200-line Node.js script using the Reactor SDK. It exported all rules, data elements, rule components, and extensions from the source property to JSON. Then it re-imported them into a freshly created property in the target organization, translating delegate_descriptor_ids between the two Extension installations. The whole migration took 4 days of engineering time plus 2 days of data validation. Total cost: under EUR 6,000.
The same pattern works for duplicating a property across multiple brand sites, or for backing up a property before a risky change.
Use Case 3: Automated Cross-Property Audits
If you manage AEP Tags across 5-plus properties (common in enterprise organizations with multiple brand sites), the UI becomes useless for quarterly audits. You can't answer "which rules fire on checkout page load across all our properties" without an API.
A Reactor API audit script can query all properties, dump their rules and rule components, and build a spreadsheet answering exactly that question. For Tomasz, an analytics lead at an insurance group I worked with in summer 2025, the script flagged 23 rules across 7 properties that were still firing on a deprecated event name nobody had cleaned up after the 2024 site redesign. Fixing them reduced phantom Adobe Analytics beacons by 11% group-wide.
Use Case 4: Webhook-Driven Integrations
The Callbacks resource lets you register a webhook that fires when a Build succeeds, fails, or when a Library transitions state. This is how you integrate AEP Tags publishing into Slack notifications, Jira ticket automation, or downstream deployment systems.
A typical setup: when a Production Build completes, the webhook posts a formatted message to the team's #martech-deploys Slack channel, including the library name, who approved it, and a link to the build logs.
Thinking through a specific automation? I do one-off Reactor API projects and ongoing support. See my GTM and AEP Tags services for scoped engagements.
Rate Limits, Errors, and Best Practices
The Reactor API has a soft rate limit of 120 requests per minute per integration. In practice I've seen bursts up to 200 RPM go through without throttling, but you should plan for 120.
When you hit the limit, you receive a 429 Too Many Requests response with a Retry-After header in seconds. The official SDK backs off automatically. If you're writing raw fetch calls, implement exponential backoff with jitter.
Other response codes you'll meet:
400: malformed request body, usually a JSON schema violation. The response body includes the specific field.401: expired or missing access token. Refresh the token and retry once.403: your integration or user doesn't have the required role on the Property.404: wrong property ID, rule ID, or the resource was deleted.409: concurrent modification conflict. Common when two processes update the same rule at once. Re-fetch and retry.500: Adobe-side error. Retry with backoff. If it persists, check status.adobe.com.
Best practice 1: always test against a non-production property first. Create a sandbox Property in your Adobe Organization specifically for Reactor API development. Assign your integration to it. Break things there.
Best practice 2: revisions are your friend. Rules, data elements, and rule components all support revisions (version history). Before a bulk update, list the current revisions as a backup. If something goes wrong, PATCH each resource back to its previous revision_number.
Best practice 3: use the SDK, not raw fetch, for anything non-trivial. The @adobe/reactor-sdk Node.js client handles pagination, authentication token refresh, retries, and response shape normalization. The time you save in the first week of development pays for learning the SDK.
Best practice 4: set up a monitoring Callback early. Even if you don't build Slack integrations yet, register a Callback that POSTs to a logging endpoint. You will thank yourself the first time a Production build fails silently at 3 AM.
When You Should Not Use the Reactor API
Honest answer: most AEP Tags teams shouldn't touch the Reactor API at all.
- If your property has under 50 rules and one person manages it, the UI is faster than any API workflow.
- If you don't have a developer on the team who can maintain authentication, error handling, and occasional SDK upgrades, an API integration will rot within 18 months.
- If you're evaluating whether AEP Tags is the right platform at all, start with the complete guide to AEP Tags (Adobe Launch) and the question of whether you need tag management help before investing in automation.
- If you're a small team that mostly runs Google Analytics 4 and GTM, with AEP Tags on the side for one legacy property, consider moving the legacy property to GTM Server-Side instead of investing in Reactor API expertise.
The API is an investment. It rewards teams that have enough AEP Tags work to amortize the setup cost.
Frequently Asked Questions
What is the difference between the Adobe Launch API and the Reactor API?
They are the same API. "Adobe Launch API" is what teams called it between 2018 and 2021, when the product was named Adobe Launch. When Adobe rebranded the product to "AEP Tags" in 2021, the API kept its internal name, Reactor. The endpoint (reactor.adobe.io) and the SDK (@adobe/reactor-sdk) never changed. Any documentation or code referring to the "Adobe Launch API" applies unchanged to the Reactor API today.
How do I authenticate to the Reactor API today?
Use OAuth Server-to-Server credentials from the Adobe Developer Console (console.adobe.io). Create a Project, add the Adobe Experience Platform Tags API, generate OAuth Server-to-Server credentials, and exchange them for a 24-hour access token at ims-na1.adobelogin.com/ims/token/v3. JWT Service Account authentication was deprecated on January 1, 2025, and no longer works.
What is the Reactor API rate limit?
120 requests per minute per integration. When you exceed it, the API returns a 429 status with a Retry-After header. The official @adobe/reactor-sdk handles retries automatically. Plan for 120 RPM even though bursts occasionally pass through without throttling.
Can I use the Reactor API to back up an AEP Tags property?
Yes, and this is one of the most common legitimate use cases. A backup script queries all properties, rules, data elements, rule components, extensions, and libraries, then writes the JSON to a Git repository or cloud storage. Restoring is harder because delegate IDs shift between Extension installations, but the export side is straightforward and well worth running weekly on any production property.
What programming languages work with the Reactor API?
Any language with an HTTP client. Adobe ships an official Node.js SDK (@adobe/reactor-sdk) which is the most convenient. Teams I've worked with have built production integrations in Python (using the requests library), Go, and PowerShell for one Windows-based enterprise. There's no language lock-in, it's a plain REST API.
Do I need to pay extra for the Reactor API?
No. API access is included with any Adobe Experience Platform Tags license. What you pay is engineering time to build and maintain the integration. A simple backup script is a few days of work. A full CI/CD pipeline is 2-4 weeks.
Conclusion
The Reactor API is the same Adobe Launch API teams have been using since 2018, under the new AEP Tags brand. If you have fewer than 50 rules and no dedicated developer, stick with the UI. If you're managing hundreds of rules, multiple properties, or a migration, the API is the difference between a weekend of clicking and an afternoon of scripting.
The three highest-value use cases are CI/CD tag publishing, cross-property audits, and mass migrations. Each one pays for the setup cost within the first engagement if your team has the volume. Start by setting up an OAuth Server-to-Server integration against a sandbox property. Clone a few rules programmatically. When you feel comfortable, scope a concrete project, property backup is the safest first real workload.
Ready to audit whether the Reactor API belongs in your tag management stack? Get in touch for a scoped assessment. I'll review your current AEP Tags setup, identify the automation use cases that actually pay off, and give you a realistic engineering estimate. No pitch deck, no upsell. Just an honest answer on what is worth building.
Meta Elements
```
Meta Title: Reactor API (Adobe Launch API): Complete Guide 2025
Meta Description: Reactor API is Adobe's REST API for AEP Tags (formerly Adobe Launch). Learn authentication, resources, rate limits, and real CI/CD use cases. Full 2025 guide.
Primary Keyword: Reactor API
Secondary Keywords: Adobe Launch API, AEP Tags API, Adobe Experience Platform Tags API, tag management automation, Adobe I/O authentication
URL Slug: /articles/en/reactor-api-adobe-launch-api-guide.html
Internal Links:
- https://piotrlitwa.com/articles/en/adobe-launch-what-is-it-guide.html
- https://piotrlitwa.com/articles/en/aep-tags-help.html
- https://piotrlitwa.com/articles/en/gtm-server-side-what-is-it-guide.html
- https://piotrlitwa.com/services.html#gtm (x3 CTAs)
External Links:
- developer.adobe.com (Reactor API docs)
- console.adobe.io (Adobe Developer Console)
- ims-na1.adobelogin.com (OAuth token endpoint)
Word Count: ~2750
```
Notes for /publish-html
- YouTube embed: recommend either Adobe's official "Introduction to AEP Tags APIs" video if available, or a community video on @adobe/reactor-sdk usage. Placement: after "Core Reactor API Resources" H2.
- Schema: Article + FAQPage (6 Q&A pairs are FAQ-ready). No HowTo (this is a reference guide, not step-by-step).
- PL translation notes: "Rule" → "reguła", "Data Element" → "Data Element" (keep English, industry standard in PL martech). "Property" → "property" (English industry term). Adapt mini-story names if needed (Marek/Agnieszka/Tomasz are already PL-friendly).
Need an honest Reactor API assessment?
I review AEP Tags setups and scope Reactor API work that actually pays off. No slide decks, no upsell.
See my servicesNeed help? Get in touch
Have a question about your analytics setup? Fill out the form, I usually reply within 24 hours.
