Migrate from API v2 to API v3

API v3 gives your integrations access to more of Stack Internal Community: Collections, Communities, user groups, subject matter experts, content import, and API usage reporting. Its OpenAPI schema also makes it easier to explore requests, generate a client, and give an AI coding assistant the details it needs to update your application.

This guide compares Stack Internal Community Enterprise API v2.3 and API v3. You'll learn how to map common endpoints, update authentication and response handling, estimate additional requests, and test your migration. It covers the Enterprise main site and notes where Private Teams differ. Basic and Business use a different API host and personal access tokens; don't copy the Enterprise authentication setup into those products.

Migration deadline: API v2 reaches end of life on April 28, 2027. Update and test your integrations before that date. See the Community release notes. This article concerns the Enterprise API, not the public Stack Exchange API.

Your site's Swagger documentation is the final reference for the version available to you: open https://[your_site].stackenterprise.co/api/v3 and download https://[your_site].stackenterprise.co/api/v3/swagger.json. An endpoint in a specification doesn't establish that every deployment has that feature enabled.

What changes in API v3

Treat the migration as a change to your API client, not just a replacement of the version in each URL. Most applications need changes in the following areas.

Area	API v2.3	API v3
Enterprise base URL	https://[your_site].stackenterprise.co/api/2.3	https://[your_site].stackenterprise.co/api/v3
Request credentials	Read requests use X-API-Key or key; user-authorized operations also use OAuth credentials	Send the supported credential in Authorization: Bearer …; use a user-authorized OAuth access token for the examples below
Response fields	Usually snake_case, such as creation_date and view_count	Usually camelCase, such as creationDate and viewCount; identifiers also change by model
Dates	Unix timestamps in seconds	ISO 8601 date-time strings; handle UTC offsets and nullable dates
Pagination	page, pagesize, and has_more	Usually page, pageSize, and totalPages; some endpoints use other response shapes
Response customization	Custom filter values select fields and can include related content	Fixed response models; fetch related resources when your workflow needs them
Writes	Action routes such as /questions/add, /edit, and /delete	HTTP methods describe the action: POST, PUT, and DELETE on resource routes
Errors and throttling	Error fields and optional backoff in the response wrapper	Inspect HTTP status, error content, and rate-limit headers; don't assume every error body is JSON

API v3 doesn't support v2 custom response filters. It still supports query parameters that narrow results, including search text and endpoint-specific author, tag, date, and status criteria. Selecting records and customizing the returned fields are different operations.

Set up authentication

For a user-authorized integration, register an API application and use the OAuth authorization-code flow with Proof Key for Code Exchange (PKCE). PKCE binds the authorization code to the client that requested it. Keep application secrets on the server and store tokens in your application's secret store. Follow Secure API Token Generation with OAuth and PKCE.

Send the resulting access token in an HTTP header:

Authorization: Bearer YOUR_ACCESS_TOKEN
User-Agent: community-migration-example/1.0

Request only the permissions your integration needs. write_access permits write operations; access_team selects a Private Team context. Other operations can require private_info, manage_users, content_import, or read_inbox, together with the relevant user role. A scope doesn't grant administrator privileges to a non-admin.

Application key or access token? Current API v3 supports bearer API keys as well as OAuth access tokens, but their identity and permissions differ. Some routes need a user identity: /for-you, for example, accepts a user API key or an OAuth token with read_inbox, and rejects application keys. Use the credential type documented for each endpoint. Don't substitute an application secret for a bearer credential, and don't assume that a key that works for one route will work for every route.

A Community service application has persistent application ownership, which helps integrations survive staff changes. It doesn't make a user-authorized token independent of its user. Community API applications are also distinct from Organization Service Accounts for the separate Stack Internal platform. See Community API v3 for application setup.

Token renewal: Current OAuth implementation supports offline_access and refresh-token exchange at /oauth/access_token/json with grant_type=refresh_token. Store the replacement access and refresh tokens together, and serialize refresh attempts: refresh tokens are single-use, and replay can invalidate related tokens. Confirm support on your deployed version. The supplied Swagger scope list omits offline_access, so it isn't a complete description of token lifecycle support. Swagger UI's temporary token expires after 24 hours; don't use it as an unattended production credential.

Map your existing endpoints

The routes below are relative to each version's base URL. {questionId}, {answerId}, and similar values are placeholders. V2 often accepts several semicolon-separated IDs in a path; v3 usually uses a single resource ID or an endpoint-specific array query parameter. Check the v3 schema instead of copying v2 batching syntax.

Task	API v2.3 route or operation	API v3 route and migration detail
List questions	GET /questions	GET /questions; update parameter names and response parsing
Retrieve questions by ID	GET /questions/{ids}	GET /questions/{questionId} for one full resource; GET /questions also accepts a questionId array for summaries
Search questions	GET /search/advanced?q=…	GET /search?query=…; search can return questions, answers, and Articles. Use is:question when you need question results
Search titles or find similar content	/search with intitle, or /similar	Review /search query syntax and test matching behavior. These aren't identical request contracts
Read answers	/answers, /answers/{ids}, /questions/{ids}/answers	GET /questions/{questionId}/answers and GET /questions/{questionId}/answers/{answerId}; keep the parent question ID. No site-wide /answers route appears in the supplied spec
Read a user's answers	GET /users/{ids}/answers	GET /users/{userId}/answers; one user at a time, with parent-question context
Read comments	/comments, /posts/{ids}/comments, and question/answer comment routes	GET /questions/{questionId}/comments, GET /questions/{questionId}/answers/{answerId}/comments, or GET /articles/{articleId}/comments; these return arrays. /users/{userId}/comments is paginated
Create or edit a question	POST /questions/add or /questions/{id}/edit	POST /questions or PUT /questions/{questionId} with the documented JSON body
Create or edit an answer	/questions/{id}/answers/add or /answers/{id}/edit	POST /questions/{questionId}/answers or PUT /questions/{questionId}/answers/{answerId}
Delete content	POST …/{id}/delete	DELETE /questions/{questionId}, DELETE /questions/{questionId}/answers/{answerId}, or DELETE /articles/{articleId}
Vote or accept an answer	Action routes and /undo suffixes	POST adds a vote or acceptance; DELETE on the same /upvote, /downvote, or /accept route removes it
Bookmark a question	/questions/{id}/favorite and /favorite/undo	POST or DELETE /questions/{questionId}/bookmark
Flag content	…/flags/add and …/flags/options	POST …/flags and GET …/flags/options on the question or question-scoped answer route
Read or write Articles	/articles, /articles/{ids}, /articles/add, /edit, /delete	GET or POST /articles; GET, PUT, or DELETE /articles/{articleId}. Basic Article CRUD already existed in v2
Linked questions	/questions/{ids}/linked, /articles/{ids}/linked	/questions/{questionId}/linked, /articles/{articleId}/linked-questions
Read users or the current user	/users/{ids} and /me	/users/{userId} and /users/me; use the correct user-detail model and permission context
List a user's questions	GET /users/{ids}/questions	GET /questions?authorId={userId}; compare status and date criteria before substituting
Look up tags	/tags, /tags/{tags}/info	/tags with exactTagNames or partialName, then /tags/{tagId}; v3 resource routes use numeric tag IDs
Tag leaders and synonyms	/tags/{tag}/top-answerers/{period}, /top-askers/{period}, /tags/synonyms	/tags/{tagId}/top-answerers, /top-askers, /tags/synonyms; inspect period parameters. These are migrated capabilities, not wholly new features
Read badges	/badges, /badges/{ids}, /badges/recipients	/badges, /badges/{badgeId}, /badges/recipients; don't assume every v2 badge subroute has a match

For a Private Team, use the /teams/{team}/… variant only when it appears in your site's schema, and authorize access to that Team. A Community is a topic-based product feature; it isn't the same resource as a Private Team. Main-site-only routes shouldn't receive a Team prefix by guesswork.

Keep Private Teams membership sync working

If you use Private Teams membership sync, update your integration to use /enterprise/usersync before disabling API v2.3. Disabling API v2.3 also disables both /2.2/enterprise/usersync and /2.3/enterprise/usersync.

Use /enterprise/usersync without an API version in the path to keep membership sync working.

Replace /posts with resource-specific requests

API v3 has no generic /posts or /posts/{ids} endpoint. If your v2 integration uses these routes to read questions and answers together, change it to request each content type through its own endpoint. There is no single replacement URL.

For a known question, use GET /questions/{questionId}. For a known answer, use GET /questions/{questionId}/answers/{answerId}; you need both the answer ID and its parent question ID. If your workflow also includes Articles, retrieve them separately with GET /articles/{articleId}. These routes are relative to /api/v3.

For a broader content export, paginate GET /questions, then paginate GET /questions/{questionId}/answers for each question whose answers you need. Paginate GET /articles separately if Articles are part of your dataset. Fetch comments or additional details only when your application needs them, and combine the results in your application. This can require more calls than a v2 posts request with a custom response filter.

If you currently store only a generic post ID, update your data model to retain the content type and, for answers, the parent question ID. Capture that information from your existing data or the supported v3 responses before switching the lookup code. The supplied v3 schema has no generic route that resolves an arbitrary post ID to its resource type and parent.

For keyword-based discovery across content types, use GET /search and inspect each result’s type before requesting details. Search is useful for finding matching content, but it is not a substitute for a complete export. For exports, handle pagination independently for each resource and test that the combined output contains the records your application expects.

New capabilities and endpoint inventory

The following operations appear in the supplied v3 schema and have no directly documented equivalent in the supplied v2.3 reference. This is a semantic comparison: merely changing a URL or HTTP verb doesn't make an existing capability new. The v3 snapshot contains 152 paths and 202 method-and-path operations, including separate main-site and Private Team routes.

In this inventory, Private Team variant means the schema also contains the same path after /teams/{team}. It doesn't imply availability on every plan or permission to call it. All routes are relative to /api/v3.

Capability	New v3 operations	Private Team variant
Article extensions	POST, DELETE /articles/{articleId}/upvote	Yes
Article extensions	POST /articles/{articleId}/publish	Yes
Attributed content import	POST /content-import/questions	Yes
Attributed content import	POST /content-import/questions/{questionId}/answers	Yes
Attributed content import	POST /content-import/articles	Yes
File ingestion	POST /ingest/file	No
Tag expertise and watchers	GET, PUT /tags/{tagId}/subject-matter-experts	Yes
Synonym management	POST /tags/{tagId}/synonyms	Yes
Tag expertise and watchers	GET /tags/{tagId}/tag-watchers	Yes
Tag expertise and watchers	POST /tags/{tagId}/subject-matter-experts/user-groups	Yes
Tag expertise and watchers	POST /tags/{tagId}/subject-matter-experts/users	Yes
Synonym management	DELETE /tags/{tagId}/synonyms/{synonymId}	Yes
Tag expertise and watchers	DELETE /tags/{tagId}/subject-matter-experts/user-groups/{userGroupId}	Yes
Tag expertise and watchers	DELETE /tags/{tagId}/subject-matter-experts/users/{userId}	Yes
Article extensions	GET /articles/{articleId}/comments	Yes
Tag preferences	GET, PUT /users/{user}/tag-preferences	Yes
Tag preferences	POST /users/{user}/tag-preferences/watched-tags	Yes
Tag preferences	DELETE /users/{user}/tag-preferences/watched-tags/{tagId}	Yes
Tag preferences	POST /users/{user}/tag-preferences/ignored-tags	Yes
Tag preferences	DELETE /users/{user}/tag-preferences/ignored-tags/{tagId}	Yes
Watched tags	GET /users/{userId}/watched-tags	Yes
User discovery	GET /users/by-email/{email}	Yes
User discovery	GET /users/by-external-id/{externalId}	Yes
User discovery	GET /users/manage	No
Reputation totals	GET /users/reputation/aggregate	No
User groups	GET, POST /user-groups	Yes
User groups	GET, PUT /user-groups/{userGroupId}	Yes
User groups	POST /user-groups/{userGroupId}/members	Yes
User groups	DELETE /user-groups/{userGroupId}/members/{userId}	Yes
Communities	GET /communities	No
Communities	GET /communities/{communityId}	No
Communities	POST /communities/{communityId}/join	No
Communities	POST /communities/{communityId}/join/bulk	No
Communities	POST /communities/{communityId}/leave	No
Communities	POST /communities/{communityId}/leave/bulk	No
Collections	GET, POST /collections	Yes
Collections	GET, PUT, DELETE /collections/{collectionId}	Yes
Images	GET /images/{imageId}	Yes
Images	POST /images/upload	Yes
Usage reporting	GET /metrics/api-call-volume	No
Usage reporting	GET /metrics/api-call-volume-by-application	No
Test response	GET /stacky	No

For the tag-preference rows only, {user} means both me and {userId}: each displayed operation exists for both paths. Operations on another user require the documented authorization. Content import additionally requires an enabled feature and appropriate administrator permissions; file ingestion is separately feature-gated. The supplied schema documents /users/manage as a read operation, not a general user-write API.

GET /for-you also appears in v3, with a Team variant. Treat it as a new site-local feed contract, not an exact replacement for every v2 inbox or notification route. It requires a user identity, doesn't mark items read, and uses hasMore rather than exact totals. An empty page can still have hasMore=true.

The modern search route, user-answer/comment routes, badge routes, top-tag rankings, and basic Article operations aren't listed as wholly new capabilities because v2 already covered related use cases. They still need client changes.

Update response handling and pagination

Compare the actual models your application consumes. A v3 list response can contain a summary model, while the resource-by-ID route returns a fuller model. Search returns a separate result model.

Data	API v2.3	API v3
Question identifier	question_id	id on question resources; questionId on question search results
Answer's parent	question_id	questionId on answer resources; parentQuestionId on answer search results
Owner identifier	owner.user_id	owner.id; handle absent or nullable owners
Tags	Array of names	Array of tag objects, including identifiers and names
Dates and counts	creation_date, answer_count, view_count	creationDate, answerCount, viewCount
Content	Optional fields selected with a response filter	body is HTML; detail models can also expose bodyMarkdown. A search snippet isn't a full-detail contract
URLs	Commonly link	Model-specific fields such as webUrl, shareUrl, or answer shareLink; don't perform a blind global rename

For paginated v3 question and search results, start at page=1, request an allowed pageSize (15, 30, 50, or 100 in the supplied schema), and continue until page >= totalPages. The larger size can reduce request counts. Don't stop solely because a page contains fewer items than requested.

Don't impose that loop on every route. Question, answer, and Article comment routes return plain arrays without paging parameters. Subject-matter-expert responses contain users and userGroups. /for-you uses hasMore. Build readers for these response shapes rather than one universal parser.

Dates deserve their own migration check. Convert Unix seconds to timezone-aware values, preserve timezone information when reading v3 date strings, and verify what each date filter means. For example, reputation aggregation uses an inclusive from and exclusive to; don't assume all date windows use that boundary rule. Search rankings and content can change between requests, so pagination isn't a snapshot export.

Estimate API calls before cutover

V3's fixed response models can require more calls than a v2 custom filter that embeds answers and comments. The increase depends on what you read. A title-and-link search can still use one request per page; an export of every question, answer, and comment needs additional resource requests.

Worked estimate, not a measured product limit: Suppose a v2 custom filter returns one page of 100 questions with all related data your job needs. In v3, assume the question list already has the required question fields, each question has two answers that fit on one answer page, and every question and answer has comments.

Request type	Calls	Assumption
Question list	1	One page of 100 questions
Answer lists	100	One page per question
Question comments	100	One array response per question
Answer comments	200	One array response per answer
Total	401	Additional detail requests, retries, and other resources are excluded

That example shows why you should budget by workflow, not by endpoint count. It isn't a universal 401-times multiplier. Your v2 filter might not include every field, your data may have fewer comments, or answer lists may need several pages.

To reduce unnecessary calls:

1. Define the fields and relationships your application actually needs. Don't fetch full details for a list that only displays titles and links.
2. Use supported batching and the largest appropriate page size. For questions, consider the questionId array parameter.
3. Skip answer or comment requests when a returned count is zero. Treat a missing count as unknown, not zero; verify count behavior on your deployment.
4. Cache stable lookups such as tag identifiers, and deduplicate requests for the same resource.
5. Checkpoint long-running jobs. Use incremental reads only after verifying that the chosen sort and date filters capture edits and new child content, not just newly created questions.
6. Measure actual calls and elapsed time on representative data, including retries. Compare both content completeness and the finished report or application output.

Administrators can use GET /metrics/api-call-volume and GET /metrics/api-call-volume-by-application to compare v2 and v3 usage. These provide monthly reporting, not immediate per-request diagnostics. The documented reporting history starts July 22, 2026, and is production-only. See API usage metrics.

Handle throttling and errors

V2 clients should honor the response body's backoff before calling that method again and monitor quota_remaining. In v3, use HTTP status and response headers. Keep a descriptive User-Agent on every request.

The API v3 Overview documents default burst throttling of 50 requests per two seconds, plus a token bucket with capacity 5,000 and refill of 100 requests per 60 seconds. Daily limits are separate. Read x-rate-limit, x-rate-limit-calls-left, and x-rate-limit-seconds-until-reset, together with x-burst-throttle-* and x-token-bucket-*. These controls can stop requests independently.

Check your effective limits. Application settings, authentication mode, deployment, and commercial terms can affect the limits that apply. Published pages contain conflicting quota figures. Don't use an old 10,000/50,000 figure, a documented maximum, or a token-bucket calculation as a guaranteed daily allowance. Confirm your configured limits with your administrator or Support, and record headers during a test run.

On 429, honor Retry-After when present and the reset information for the exhausted limiter. Use bounded retries with backoff and jitter for safe reads. If a daily allowance is exhausted, checkpoint and resume after reset rather than retrying rapidly. Don't assume the server always includes Retry-After.

For 401, check the credential and renewal flow. For 403, check scopes, user permissions, and Team access. For 404, verify the parent ID, route, and feature availability. Capture the status and a redacted response for 5xx failures; don't automatically treat them as invalid credentials. Don't blindly retry writes after a timeout, because the first request may have succeeded. V2 documents a request_id duplicate-detection parameter; the supplied v3 schema doesn't advertise a general equivalent. Review the result before retrying a non-idempotent operation.

Compare Python search examples

These examples search for the phrase "How do I install Python" and print matching question titles and URLs. They illustrate the request and response changes using Python and requests. Install the dependency with python -m pip install requests.

Set SOE_SITE to your HTTPS Enterprise site origin, such as https://example.stackenterprise.co. Set SOE_V2_KEY to a v2 read key and SOE_V3_TOKEN to a user-authorized v3 OAuth token. Load those values through your environment or secret manager; don't put real credentials in source code. Run each version separately.

API v2 example

v2 uses the q parameter, pagesize, the X-API-Key header, and has_more. HTML entity decoding keeps the displayed v2 title readable.

import html  
import os  
import time  
import requests

site \= os.environ\["SOE\_SITE"\].rstrip("/")  
phrase \= '"How do I install Python"'  
session \= requests.Session()  
session.headers.update({  
    "X-API-Key": os.environ\["SOE\_V2\_KEY"\],  
    "User-Agent": "community-migration-example/1.0",  
})

page \= 1  
while True:  
    response \= session.get(  
        f"{site}/api/2.3/search/advanced",  
        params={"q": phrase, "sort": "relevance",  
                "page": page, "pagesize": 100},  
        timeout=30,  
    )  
    response.raise\_for\_status()  
    data \= response.json()  
    if "error\_id" in data:  
        raise RuntimeError(data.get("error\_message", "API error"))  
    for question in data\["items"\]:  
        print(html.unescape(question\["title"\]), question\["link"\])  
    if not data\["has\_more"\]:  
        break  
    if data.get("quota\_remaining") \== 0:  
        raise RuntimeError("V2 quota exhausted; save your checkpoint")  
    time.sleep(data.get("backoff", 0))  
    page \+= 1

API v3 example

v3 uses query, pageSize, a bearer token, and totalPages. is:question narrows the search because v3 supports multiple result types. The type check also protects your parser from processing an answer or Article as a question.

import os  
import requests

site \= os.environ\["SOE\_SITE"\].rstrip("/")  
phrase \= '"How do I install Python"'  
session \= requests.Session()  
session.headers.update({  
    "Authorization": f"Bearer {os.environ\['SOE\_V3\_TOKEN'\]}",  
    "User-Agent": "community-migration-example/1.0",  
})

page \= 1  
while True:  
    response \= session.get(  
        f"{site}/api/v3/search",  
        params={"query": f"is:question {phrase}",  
                "sort": "relevance", "page": page, "pageSize": 100},  
        timeout=30,  
    )  
    if response.status\_code \== 429:  
        wait \= response.headers.get("Retry-After", "not supplied")  
        raise RuntimeError(f"Rate limited; Retry-After: {wait}")  
    response.raise\_for\_status()  
    data \= response.json()  
    for hit in data\["items"\]:  
        if hit\["type"\] \== "question":  
            print(hit\["title"\], hit\["webUrl"\])  
    if page \>= data\["totalPages"\]:  
        break  
    page \+= 1

Both examples request literal-phrase matching, but the two search implementations can differ in indexing, ranking, and matching behavior. Verify expected results on your own content. The v3 example stops on throttling so it won't hide a quota problem; add the bounded retry and checkpoint policy described above for a production job. It doesn't implement token refresh.

If your v3 application needs the question's full detail, fetch GET /questions/{hit['questionId']}. If it needs the answers, fetch GET /questions/{hit['questionId']}/answers and paginate that response. This is where a migration can add requests. Don't look for id in the question search result, and don't treat snippet as a guaranteed substitute for body or bodyMarkdown.

Example validation: The request parameters and fields were checked against the supplied schema. Simulated responses were used to check paging, empty results, mixed result types, v2 backoff/quota handling, and v3 throttling. These examples haven't been executed against a customer's live site.

Use AI to help migrate your application

An AI coding assistant can help find API calls, replace routes and parameters, and update model parsing. Stack Overflow has used this approach to migrate internal applications, then checked that the applications still produced the intended results. Treat that experience as a useful starting point, not a guarantee that every integration will convert without further work.

1. Create a branch or a copy of your application and record its current outputs and API call count.
2. Download the v3 Swagger JSON from the site you're migrating to. Give the assistant that schema, the application code, and a description of the workflows you need to preserve. Include your v2 filters and tests so it can see which related data you depend on.
3. Use an approved coding assistant and remove credentials, private records, and unnecessary logs from its input.
4. Ask for an endpoint map and a list of gaps before accepting code changes. Review credentials, scopes, paging, field types, retries, and extra calls.
5. Run tests and compare both the returned data and the application's final output. Test write operations only in a suitable test environment, with explicit control over what gets created or changed.

You can adapt this prompt:

This application uses Stack Internal Community Enterprise API v2, or a mix of v2 and v3. Update it to use only API v3, using the attached Swagger JSON from our target site as the endpoint contract. First inventory every v2 request, custom filter, required response field, and downstream use. Map each workflow to supported v3 operations and flag missing capabilities without inventing endpoints. Preserve the application outputs and permissions. Update authentication, pagination, dates, model fields, rate-limit handling, and error handling. Estimate request counts before and after the change. Add tests for empty and multiple pages, missing data, token expiry, throttling, and the application outputs. Show any behavior changes or unresolved gaps before considering the migration complete. Keep secrets out of code and logs.

For the search example, a useful review question is: "Does the migrated code still return the intended questions for 'How do I install Python', and does it fetch extra resources only when the application needs them?"

Check gaps before you switch

API v3 has broad workflow coverage, but it isn't a route-for-route copy of v2. The supplied schema doesn't document direct replacements for every legacy feature. If your integration uses any of the following, resolve the workflow before cutover:

• Site-wide /events or a complete activity timeline. The site-local /for-you feed isn't a site-wide event stream.
• Site-wide /answers, /comments, or mixed /posts exports, or custom filters that expand all related content into one response.
• Comment creation, editing, deletion, voting, or flagging. The supplied v3 comment routes are reads; don't infer write support from the presence of a Comments section.
• Revision history, suggested-edit workflows, and the v2 reputation-event/history routes. The v3 reputation aggregate is a net total, not an event ledger.
• V2 inbox/notification behavior, badge subroutes, privileges, or specialized user-activity routes without an explicit v3 equivalent.
• General user impersonation. Scoped content import preserves a visible author for supported import operations; it doesn't provide unrestricted actions as another user.

Absence from this snapshot doesn't prove that a capability can never be supported. Check your site's current Swagger schema and contact Support with the exact v2 route, parameters, filter, and required result if you can't find a supported path. Include a redacted example and your call-volume estimate. Don't schedule your migration around an unshipped roadmap item.

Complete the migration

Use this checklist before replacing your production integration.

• Every v2 call has a tested v3 replacement or a resolved workflow change.
• Authentication, scopes, user permissions, and main-site or Private Team context are correct.
• Pagination covers empty, single-page, and multi-page results, including endpoint-specific exceptions.
• Dates, identifiers, tags, null values, content bodies, and URLs reach the application in the expected format.
• The migrated application returns the required records and produces the same intended output.
• Call volume, runtime, and concurrency fit your configured limits. Long jobs can resume after interruption.
• Token renewal and credential ownership are suitable for unattended use.
• Write behavior has been verified without duplicating content or granting unnecessary privileges.
• Monitoring identifies remaining v2 traffic, and you have a rollback plan during the migration period.

Start with a read-only workflow, measure it, and use what you learn to migrate the next one. For help with a missing endpoint or unexpected behavior, contact Support.