Migrate an OpenAI-Compatible App to Token360: 10 Compatibility Checks
Migrate an OpenAI-compatible app to Token360 with 10 checks for endpoints, streaming, tools, state, billing, and rollback. Includes a reusable test pack.
To migrate an OpenAI-compatible app to Token360, first identify the endpoint and features your application uses. Configure the target credentials, base URL, and verified model ID, then replay a fixed set of application tests before moving traffic. A successful text response is the beginning of validation, not proof that streaming, tools, conversation state, and billing behave as your app expects.
This guide provides a Token360-specific preflight, ten reusable test cases, and release criteria. It focuses on the boundary between your existing application contract and the target route, rather than treating migration as a universal search-and-replace operation.
Prepared by Token360. Public documentation checked October 23, 2026. The test pack is an original evaluation design. A user-run, non-streaming curl request has now returned HTTP 200 and READY; the screenshot evidence is summarized below. Application-parser validation, the other compatibility cases, baseline comparisons, and billing remain unverified. This is not a completed application migration or reliability benchmark.
Inventory the endpoint before changing the provider
Record what the application actually sends and reads: endpoint, SDK version, model identifier, message roles, output parser, streaming handler, tools, structured-output schema, conversation state, timeout policy, and usage accounting. Start with one bounded user flow, such as a support-answer generator.
Chat Completions and Responses are different contracts. OpenAI's Responses migration guide describes differences in input and output structure, state handling, tools, and streaming events. A client that reads Chat Completions choices cannot automatically consume a Responses output array. Keep the existing endpoint family during your first provider comparison when the target route supports it.
Separate two experiments: changing the provider route and changing the model or protocol. If you change all three, you can evaluate the resulting application, but you cannot attribute an improvement or regression to the provider alone. Preserve the original configuration as a named baseline.
Check Token360's documented boundaries
Token360's response protocol compatibility document distinguishes endpoint support from model capabilities. As checked on October 23, 2026, it documents the following Responses boundaries:
Feature
Documented boundary
Migration decision
Chat Completions / Responses
Separate compatible contracts; selected model/SKU must support the endpoint.
Verify your exact route before testing optional features.
previous_response_id and store
Continuation is supported and pinned to the originating provider route; explicit storage values are preserved.
Test your conversation lifecycle on the intended route.
conversation
Not currently supported.
Block this flow or redesign its state handling.
background: true
Not currently supported.
Do not transfer this setting unchanged.
Retrieve, cancel, or delete /v1/responses/{response_id}
Not currently supported.
Resolve lifecycle dependencies before rollout.
These are documented capabilities and limits, not results from our test account. Recheck the source before deployment. A flow with an unsupported required operation is blocked even if its first text call succeeds.
Passing one compatibility gate does not clear the others.
Make the smallest configuration change
The Token360 overview specifies https://api.token360.ai/v1 as the base URL. Use a Token360 credential and a public model ID verified in the current catalog. Do not assume your original provider's alias identifies an identical model version or SKU on the target.
Keep configuration separate from the prompt and parser:
Migration configuration — values to verify, not a live result
baseline:
base_url: your current provider's configured URL
credential: existing server-side secret reference
model: recorded baseline model ID
endpoint_family: application's existing contract
candidate:
base_url: https://api.token360.ai/v1
credential: separate Token360 server-side secret reference
model: verified Token360 catalog ID
endpoint_family: same contract, if the route supports it
Use a staging configuration and retain the baseline. Pin the client dependency version during the comparison. If an SDK upgrade is necessary, test that change separately so a parser regression is not confused with a provider issue.
Use the Token360 quickstart for the first authenticated request. Its example response demonstrates the expected basic shape; it is not evidence that your own route, permissions, application fields, or billing configuration have passed.
One live text request: what we verified
On October 23, 2026, the tester submitted a non-streaming request from a Mac terminal to https://api.token360.ai/v1/chat/completions, using the model ID gpt-6.1-sol and the prompt below. The supplied terminal screenshot shows the request and its returned result. We transcribed the visible fields; we did not independently execute this call or receive the complete machine-readable response.
This is one successful authenticated text smoke check. The elapsed time is curl's client-observed total transfer time, including connection and response delivery; it is not isolated model inference latency or time to first token. No SDK was used, and the curl version was not captured.
A separate Playground screenshot showed READY with 23 prompt tokens, 5 completion tokens, 28 total tokens, and a displayed time of 1.99 seconds. Its full request and timing definition were not captured. Keep that observation separate: the two runs have different reported input usage and do not establish a speed comparison.
The API sample supplies partial evidence for T01: HTTP success, visible content, and a terminal finish reason. It does not exercise the application's production parser. T02–T10 and all baseline cases remain unrun. Earlier attempts with other model IDs returned errors, so this single successful route should not be generalized to the whole catalog.
Run ten fixed cases against the application contract
The ten-case migration test pack below contains proposed inputs, acceptance criteria, partial T01 screenshot evidence, and pending fields for the remaining checks. It does not send requests. Run the same applicable cases through your application’s normal adapter, not only through an isolated API console. The complete JSON specification is included after the table so it can be copied into a local file.
ID / case
Fixed input or setup
Acceptance criterion
T01 · Text parsing
“Return exactly READY and nothing else.”
Successful response parses; trimmed text equals READY; terminal state is recorded.
T02 · Multi-turn state
Set a fictional project code to ALDER, then ask for that code on the next turn.
App sends the intended context and receives ALDER through its chosen state mechanism.
T03 · Unicode stream
“Return exactly: Café — 你好 — 🌊” with streaming enabled.
Reconstructed text is correct; no broken characters or duplicated deltas.
T04 · Interrupted stream
Inject a connection interruption before normal completion.
App marks partial output incomplete and avoids silently appending a restarted answer.
T05 · Tool round trip
Ask for inventory of SKU DEMO-01; use a local read-only lookup fixture returning 7.
Valid arguments and matching call ID reach the fixture; returned data reaches the final answer.
T06 · Structured output
Extract {sku, quantity} from “DEMO-01: 7 units” using the app's schema feature.
Parsed output matches the schema and values; extra fields and coercions are checked.
T07 · Output limit
Request a long list with a deliberately small supported output limit.
App recognizes truncation or the route's explicit outcome instead of presenting incomplete data as complete.
T08 · Invalid model
Use a deliberately nonexistent ID in staging.
A non-success response reaches the error path; no hidden fallback or successful empty answer.
T09 · Rate-limit handling
Inject a documented rate-limit response into the adapter.
Retries are bounded and honor applicable retry instructions; UI remains truthful.
T10 · Rollback and state
Start a test conversation on the candidate, then switch routing to the baseline.
New work follows policy; existing conversation state remains usable or is explicitly restarted.
The prompts are intentionally small so failures are easy to inspect. Replace or extend them with sanitized examples from your own workload before making a release decision. If tools or structured output are required but unsupported on the chosen route, that case is blocked—not “not applicable” merely to improve the score.
Classify every case as passed, failed, blocked, not run, or genuinely not applicable. Separate injected faults from live-provider observations. One pass per case is a smoke test, not a reliability estimate; repeat representative cases and test application-level quality before moving important traffic.
Copyable migration test specification
Save the following as blog58-migration-test-pack.json. Evidence labels and pending fields are preserved from the local test record.
Inspect streams and tools beyond the first successful response
A streaming parser must reconstruct protocol events, not treat each network read as a complete message. Network boundaries can split an event; an event may carry metadata instead of text. Preserve the distinction between receiving content and observing a successful terminal outcome.
OpenAI's Chat Completions streaming reference documents incremental deltas and finish reasons, including ordinary completion, output limits, and tool calls. Use the endpoint's event contract rather than assuming every chunk contains a printable string. Test your actual parser with fragmented input.
For T05, the tool fixture should be read-only and deterministic. Validate arguments before invoking it, record the call ID, and return the fixture result using the matching protocol. A model merely mentioning “7” in text does not prove the tool round trip worked. If the route supports a forced tool choice, you can use that for a protocol check; also test natural tool selection separately when your application depends on it.
For T06, distinguish “valid JSON” from “correct structured data.” A syntactically valid object can omit a required property, invent a SKU, or encode quantity as the wrong type. Validate against the exact schema consumed by the next component.
Record quality, timing, and cost separately
For each attempt, retain the case ID, timestamp, route/model, SDK version, request ID, redacted settings, outcome, output usage, and application acceptance result. Keep credentials and private user content out of a public test report.
Measure time to first content separately from time to completed output. An early empty or role-only event is not the first user-visible token. Report the timing method and environment; a handful of samples does not establish stable tail latency or a production SLA.
Use actual billed amounts when comparing cost. Token360's billing documentation describes request-level reconciliation at GET /v1/billing/requests/{request_id} and distinguishes estimates from final charges. A provider's advertised price is not automatically the applicable Token360 route price.
Observed accepted-task cost = total recorded charges / accepted tasks
Keep separate:
- input/output usage and any other applicable billing units
- retries and failed attempts with their actual charging treatment
- task acceptance and generated output length
- time to first content and time to completion
If a candidate is less expensive because it omits half the requested answer, it has not delivered an equivalent saving. If no task passes, report the spend and zero accepted tasks rather than a finite cost-per-accepted-task figure. This article has no billed comparison, so it makes no claim that migrating to Token360 is cheaper.
Set release gates and a rollback plan
Agree on release criteria before reading the results. A useful starting gate is that all required contract cases pass, no required lifecycle feature is blocked, application-quality review is acceptable, and the agreed cost and latency limits are met. Those limits should come from the application, not an invented industry benchmark.
Expand only after the required evidence is available.
Run a bounded canary with a defined owner and stop conditions. Avoid sending sensitive production conversations to a second provider merely to collect comparison data; use authorized evaluation data and the applicable data-handling policy. Shadowing can add cost and must not execute side-effecting tools twice.
Rollback requires more than switching a URL. Preserve the baseline configuration and decide what happens to in-flight requests, partial streams, and provider-bound conversation state. Keep existing sessions on their original route where necessary, or rebuild context using an explicitly supported application strategy. Do not assume a continuation ID from one provider works on another.
Next step: check the Token360 compatibility boundaries, choose a verified route, and complete the test pack for one user flow. Leave the remaining flows on the baseline until their own requirements pass.
FAQ
Is changing the base URL enough to migrate to Token360?
It may establish the connection for a supported basic flow. You still need a valid credential and model ID, plus tests for every endpoint feature and response behavior the application requires.
Will my existing model ID work unchanged?
Do not assume that. Confirm the public ID, endpoint support, and available options in the current catalog. Matching names also do not establish identical upstream versions or outputs.
Can I move a Responses application without changing its state handling?
Check its exact dependencies first. The documented limitations above matter if the application uses conversation objects, background execution, or response lifecycle operations. Resolve required unsupported features before rollout.
How do I test streaming compatibility?
Check event parsing, Unicode reconstruction, terminal outcomes, interruptions, and any streamed tool arguments your app uses. Test fragmented input and partial output, not just a short successful answer.
Does a lower token price guarantee lower application cost?
No. Compare actual charges for accepted tasks, including applicable retries and output differences. Similar prompts can produce different output lengths and acceptance rates.
Has this ten-case pack been run against Token360?
Only a basic non-streaming curl smoke check has succeeded: gpt-6.1-sol returned HTTP 200 and READY. That is partial T01 evidence, not a production-parser test. The remaining nine cases and all baseline comparisons are pending.
Tutorial
Tutorial
Tutorial