What you can export from Portkey before you switch gateways
If a renewal, a pricing change or a data residency requirement is forcing you off Portkey, the first thing to confirm is what the export can actually return. Portkey's documented export covers gateway logs only, is available only on the Enterprise plan, and writes JSONL with selectable fields, capped at 50,000 logs per export job. Self-hosted Enterprise customers must also enable the Data Service before the export works. Check your plan and that setting with Portkey now, because a history of more than 50,000 logs means several jobs that must be run, polled and downloaded in sequence.
The export does not cover everything you have built around the gateway. Prompt templates, virtual keys, budgets, access rules, routing configs and guardrail settings live in the Portkey console, and the logs export does not carry them forward. Make a written inventory of each of these, then export the configs and keys you need to recreate in your new gateway by hand, and record which application uses which key. Also confirm with Portkey how long your logs remain available after your contract ends, and whether any data held by its hosted control plane can be deleted on request.
Start the export early and run it in a test window before the cutover date. Select the fields you need for audit, cost reporting and trace continuity, including the trace ID, timestamps, provider and model, token counts, cost and status code, and confirm that a sample file opens and parses in the tools your finance and security teams use. The asynchronous export API follows a fixed sequence: create a job, start it, poll its status and download the result from a signed URL, so script that sequence and keep the signed files in storage you control, since those links are temporary.
Which Portkey data has a documented export path
This table lists the log fields and export conditions that Portkey documents for its logs export. Read it as a checklist: confirm each field and the plan requirements with Portkey before you plan a migration, since the export covers gateway logs only.
| Item | What Portkey documents | What to confirm before planning |
|---|---|---|
| Plan requirement | Logs export is available only on the Enterprise plan | Whether your current contract includes logs export and the Enterprise export terms |
| Self-hosted Enterprise | Customers must enable the Data Service to use logs export | Whether the Data Service is enabled in your gateway deployment and who owns that setting |
| Output format | JSONL, one JSON object per log entry | How your downstream store will parse nested request and response payloads |
| Trace and timing fields | Trace ID, timestamps and response time | Time zone of timestamps and whether trace IDs match your application telemetry |
| Payload fields | Request and response payloads | Whether payloads are complete for every provider and how prompt data is handled under your data policy |
| Model and cost fields | Provider, model, token counts and cost | Whether cost figures match your invoices and how they are calculated per provider |
| Routing and metadata fields | Status code, config ID, prompt slug and metadata | Whether config IDs and prompt slugs still resolve after you retire the hosted configs |
| Volume limit | Up to 50,000 logs per export job | How many jobs a full history needs, and whether Portkey supports larger exports or retention limits |
What Portkey does not document as exportable and how to cover the gap
The logs export covers request history, but a gateway also holds configuration: keys, budgets, routing and prompts. Those items are not listed among the exportable fields in Portkey's documentation, so plan to capture them from your own sources and confirm with Portkey what it can provide before you cut over.
Virtual keys and their scopes
Virtual keys map each application to a provider credential and its limits. The logs export records which key or config handled a request, but it does not hand you the key set itself. Before cutover, inventory every key, its owning team, the applications that call it and the models it can reach. Ask Portkey in writing whether key metadata and scopes can be exported and in what format, and treat any key secret as something to reissue rather than copy.
Budgets and rate limits
Spend caps and request limits attached to keys, workspaces or users shape how traffic behaves after a switch. Exported logs show cost per request, but they do not reconstruct the budget rules that produced it. Record each limit, its period and its scope in a spreadsheet during the inventory, then reproduce those values in the new gateway's budget configuration. Confirm with Portkey whether budget definitions are available as an export.
Routing configs and fallbacks
Routing configs define load balancing, retries, fallback order and conditional targets. These are usually written in JSON or set in the dashboard, and the logs only show the config ID that applied to each request. Store every config version in your own source control, with a short note on which application uses it. If Portkey can return config definitions through its API or support team, request them as a backup, but do not rely on that as your only copy.
Prompt management content
Prompt templates, versions and variables may live only in Portkey's prompt library, and the logs export carries a prompt slug and metadata rather than the full template history. Rebuild each prompt from a local copy kept in the repository, with its version label and variable names. Compare a sample of exported responses against the rebuilt prompt to confirm that output still matches. Ask Portkey what version history it can provide for prompts that were deployed through the gateway.
Users, workspaces and access rules
Who can view logs, edit configs and rotate keys is governed by roles and workspace membership in Portkey. Those access rules are not part of the logs export, and they will need a new home in whichever gateway replaces it. Export a list of members, roles and workspace assignments from the admin console, map each role to a group in your identity provider, and document who approved each permission so the new access model can be reviewed.
Retention and the data you still need
Logs exported today cover only the fields you selected and only up to the per-job limit, so older records may be spread across several jobs or held only in Portkey. Decide how long you must keep request history for audit or incident work, then store exports in your own object storage with checksums and a retention schedule. Confirm with Portkey how long logs remain available on your plan, so you know which history must be pulled before the account closes.
How the asynchronous export API pulls history in batches
The asynchronous export API follows a four-step sequence: create an export job, start it, poll its status until it finishes, then download the result from a signed URL. Each step is a separate call, so your script or pipeline has to track a job ID across the whole sequence and treat each state as something it can wait on rather than assume. Confirm the exact endpoint paths, request bodies and status values in Portkey's logs export documentation before you write code against them, because the API surface is the part most likely to change between releases.
The 50,000-log cap per job is the reason long histories need several jobs. Portkey documents that it currently supports 50,000 logs per export job, so a year of traffic from a busy gateway will not fit in one pull. Split the history into date ranges small enough that each range is expected to stay under the cap, run one job per range, and keep a manifest that records the range, job ID, row count and file checksum for every job. Ask Portkey whether the cap is fixed for your plan, and whether an export that hits the limit is truncated or rejected, because your reconciliation check depends on the answer.
Two failure modes need planning. A signed URL expires, so the download step should request a fresh URL from the job when a download returns an access error instead of storing the URL for later. A job can also fail or stall, so the poller needs a retry limit, a timeout and an alert that names the failed date range, with a rule to rerun only that range. Before you cut over, export a small test range, count the rows, and compare the totals against the dashboard for the same window, so you know the pipeline is complete before you delete anything on the Portkey side.
The sequence for a complete export and how to verify it
This sequence moves your full Portkey log history into storage you control, in batches that respect the per-job cap, and proves with counts, field checks and sample comparisons that the copy is complete before you rely on it for a gateway switch.
Confirm Enterprise status and Data Service enablement
Confirm with your Portkey account owner that your organization is on the Enterprise plan, since the logs export is available only there. If you run a self-hosted Enterprise deployment, confirm that the Data Service is enabled, because the export depends on it. Record the plan name, the workspace or organization ID and the person who approved access. The step is done when someone with API access can create a test export job in a non-production workspace without an authorization error.
Inventory the fields you need to keep
List the fields you must retain for audit, cost reconciliation and migration. Portkey's export lets you select fields such as trace ID, timestamps, request and response payloads, provider and model, token counts, cost, response time, status code, config ID, prompt slug and metadata. Decide whether request and response payloads are needed at all, since this choice drives the data protection work in the final steps. Save the field list as a versioned file so every batch uses the same selection. The output is a signed-off field schema.
Define date-range batches under the 50,000-log cap
Portkey documents a limit of 50,000 logs per export job. Count your logs for each period in the Portkey dashboard, then split the history into date ranges so that no range is expected to exceed that limit. Use narrow windows for high-traffic periods and wider ones for quiet periods. Keep a batch register with the start time, end time, expected log count from the dashboard and the job ID you assign. The output is a complete, non-overlapping list of batches that covers the whole retention window you need.
Create, start and poll each export job
Use Portkey's asynchronous export API for each batch. The sequence is to create the export job, start it, then poll its status until it reports completion. Do not start the next job until the current one has finished, and log each job ID, status change and timestamp in your batch register. If a job fails or stalls, rerun only that batch rather than the whole history. The output is a completed job for every batch in the register, with no batch left in an unknown state.
Download and store files in your own storage
Download each result from its signed URL promptly, since signed links expire, and write the JSONL files to storage you control, such as an encrypted object store in your own cloud account or data center. Keep the original file names, batch identifiers and the selected field schema alongside each file. Restrict read access to named service accounts and enable versioning or write-once settings if your policy requires them. The output is a complete set of JSONL files stored in your own environment with their metadata.
Reconcile row counts and checksums
For each file, count the JSONL lines and compare the total with the expected count recorded in the batch register, and compare the sum of all files with the count you took from the dashboard for the full range. Calculate a SHA-256 checksum for every file at the moment you store it and record it in a manifest, then recompute the checksums after any copy or transfer. Any mismatch means the batch is rerun, not patched by hand. The output is a manifest that matches file by file and in total.
Verify field completeness and sample payloads
Parse every line and confirm that each record contains every selected field, that timestamps parse and fall inside their batch window, and that token counts, cost and status codes are present where you expect them. Then pick a random sample of records, including errors, fallback events and records from different providers, and compare them against the same entries in Portkey's dashboard. Check trace IDs, models and payload content. Have a second person sign the sample check. The output is a field-level validation report with the sample results attached.
Decide retention for raw payloads containing personal data
Request and response payloads can contain personal data, so decide with your privacy and legal owners how long raw payloads are kept, who can read them and whether they are redacted or dropped before long-term storage. Keep metadata and aggregates separately if the business need is only cost and usage. Document the decision, the legal basis you rely on, and the deletion procedure, and confirm it with your data protection lead. The output is a written retention rule applied to the stored files, with a scheduled review and a record of who approved it.
How the export differs for cloud and self-hosted Enterprise customers
Hosted Enterprise accounts keep logs in Portkey's managed service, so the export runs from the Portkey side against records Portkey already holds. The logs export is available only on the Enterprise plan, so the first step is confirming the workspace is on that plan. No component needs to be deployed in your environment before you start, but the export still has to be planned around the 50,000-log cap per job. Follow the Portkey logs export docs for the exact steps.
- Plan check: Ask your Portkey account team to confirm in writing that the workspace includes logs export.
- Field selection: Choose the fields the new platform needs, such as trace ID, timestamps, provider and model, token counts, cost and status code, before creating the job.
- Job sizing: Split the history into time windows so that each job stays under 50,000 logs, then run one job per window.
- Storage handoff: Decide where the JSONL files will be written and who can read them, because the files leave Portkey's storage once downloaded.
Confirm with the account owner how long Portkey retains logs for your workspace, so you know how much history is still available to export.
Self-hosted Enterprise customers run the Portkey stack in their own infrastructure, and the logs export depends on the Data Service being enabled in that deployment. Until the service is switched on, plan on the export not working, and confirm this with Portkey before scheduling anything. Enabling the service is a platform change, so it should go through the same change process as other production updates and begin with a backup of the existing log store. Your deployment holds the logs, which means your team controls retention and access.
- Enable the Data Service: Turn it on as Portkey's documentation describes, then confirm the export endpoints respond on your build.
- License check: Verify that your Enterprise license covers logs export before the platform team changes the deployment.
- Retention review: Confirm how far back logs are kept in your store, since the export can only return what the deployment still holds.
- Network path: Make sure the machine that runs the export jobs can reach the Portkey endpoints and the download location on your internal network.
- Ownership split: The platform or SRE team enables and operates the service, while the security team approves where the exported files are written.
Ask Portkey which version and Data Service settings your deployment requires, and get the answer in writing before the change window.
In a hybrid deployment the gateway runs in your VPC, and the control plane stays in Portkey's VPC. The gateway calls out over HTTPS to control.portkey.ai, so the export depends on that path staying open for the length of each job. Portkey's documentation for this model is the Portkey hybrid deployment docs, and it should be read before deciding where your exports run. Hybrid is the model where it matters most to confirm which side holds the log records, because that determines where the data sits during the export.
- Outbound access: Keep HTTPS connectivity to control.portkey.ai open for the full duration of the export, including job status checks and downloads.
- Log location: Ask Portkey where log records are stored for hybrid accounts and whether any gateway-side logs remain in your VPC.
- Gateway ownership: The platform team owns the gateway in your VPC, its configuration and any changes made during the cutover.
- Control plane ownership: The Portkey account owner requests the export, confirms the Enterprise terms and approves the job parameters.
- Data path review: Security reviews the route the JSONL files take from download to the destination store.
Get a written statement from Portkey on log location and the export path before you schedule the cutover.
Regardless of deployment model, the export involves several teams, and the handoffs cause most delays. The export API runs in four steps: create an export job, start it, poll its status, then download the result from a signed URL. Each step can be run by a different person, so the owner of each step should be named before the job starts. The signed URL expires, so the download step needs someone available while the job completes.
- Account owner: Confirms the plan, the Data Service status and the retention window with Portkey.
- Platform engineer: Creates, starts and polls the export jobs and records each job ID.
- Security or compliance lead: Approves the field selection, the storage location and the access list for the JSONL files.
- Application owners: Identify which config IDs, prompt slugs and metadata fields their applications depend on, so those fields are included.
- Data team: Validates the files against a sample of known requests before the old logs are retired.
Confirm with each named owner how they will be reached during the job window, since a stalled download can hold up the cutover.
What to plan before the Portkey contract renewal or termination
Exporting logs is a task with a deadline set by your contract, not by the export tool. The cards below cover the decisions to make before the end date, from confirming plan entitlements to deciding where exported data will live after Portkey access ends. Confirm every contractual date directly with Portkey before you rely on it.
Confirm logs export entitlement first
The logs export is available only on the Enterprise plan, so check that your current contract includes it before you negotiate renewal terms or plan a switch. If you are self-hosting Enterprise, also confirm that the Data Service is enabled, because the export depends on it. Ask Portkey to state this in writing, including whether the entitlement continues through any notice or overlap period.
Schedule export runs before the notice deadline
Each export job covers up to 50,000 logs, and the process is asynchronous: you create the job, start it, poll its status, then download the file from a signed URL. Work out how many logs your history contains, then run enough jobs well before your notice date so that any failed or incomplete job still leaves time to rerun. Confirm the notice period and end date with Portkey in writing.
Keep read access through the overlap
Plan for a period in which Portkey and your replacement gateway run side by side. Ask Portkey whether your dashboard and export API access stay active until the final export is complete, and whether that access ends at the contract date or earlier. Do not let the replacement system go live until you have confirmed a complete export of the history you need.
Decide where exported logs will live
Exported JSONL files contain request and response payloads, token counts, cost and metadata, which may include personal or confidential data. Choose the storage location before the first export runs, such as an encrypted volume or object store inside your own environment, and confirm that it meets your data classification rules. Restrict access to the files the same way you restrict the source logs.
Set retention rules for exported history
Decide how long you must keep exported logs for audit, incident review or internal policy, and whether that period differs from your Portkey retention. Record the export date range, field selection and job IDs alongside each file so you can show later what was exported and when. Check with your compliance team whether any records require deletion schedules once the retention period ends.
Assign owners and sign-off steps
Name one owner for the export, one for the storage location and one for approving that the export is complete. Agree a checklist covering the contract dates, the number of jobs, the field list and the integrity check on each file. Ask the procurement team to include the export obligations in any renewal or termination correspondence with Portkey.
Questions teams ask before exporting Portkey logs
Can I export logs from Portkey on a non-Enterprise plan?
No. According to Portkey's documentation, the logs export is available only on the Enterprise plan. If you run Portkey's hybrid or self-hosted Enterprise deployment, you must also enable the Data Service before the export works. Confirm your plan and deployment mode with your Portkey account team before you plan the work, because the answer decides whether you export through Portkey or rebuild history from your own copies of the data, such as application logs or a logging backend you already control. If you have no Enterprise contract, check the alternative sources first, since they determine how much history you can recover at all.
How much effort does a Portkey log export take?
The effort scales with three things: the number of logs, the number of export jobs those logs require, and the fields you choose. Portkey documents a limit of 50,000 logs per export job, so a history of several hundred thousand records means several jobs that each go through the same create, start, poll and download sequence. Each additional job adds scripting, monitoring and verification work. Selecting fewer fields reduces the size of each JSONL file but may drop data you need later, such as request payloads or metadata used for cost allocation. Plan for one pass to define the schema and a second pass to run the full history, and ask Portkey which field set matches your retention requirements.
What does the export need from our team?
The export needs three roles. First, an engineer comfortable with REST APIs, who can script job creation, starting, status polling and downloads from signed URLs, and handle retries when a job fails or a link expires. Second, storage with enough capacity and access controls for JSONL files that may contain prompts, responses and user metadata. Third, a named verification owner who checks record counts, timestamps and field completeness against the source before anyone decommissions the old data path. Without that owner, teams often discover gaps only after the gateway switch, when the history is no longer easy to reproduce.
Can our own engineers run the export without outside help?
Yes, if your engineers have API experience and the Enterprise access needed to create export jobs. Portkey documents the sequence, so a capable team can script it in-house. The work is manageable for a single history pull, but it becomes a recurring task if you need periodic exports during a longer migration. Outside help typically covers the scripting, the verification method and the storage layout, and it can be scoped as a fixed piece of work with written deliverables. DeployOpen plans, implements and documents this kind of work inside your own infrastructure, but it does not operate Portkey on your behalf or change your Portkey contract.
How long does a full Portkey log export take?
The duration depends on your log volume, the number of 50,000-log jobs, the fields selected and how quickly Portkey processes each job on the day you run it. No supplied figure fixes a standard duration, so do not plan from a generic estimate. Run one test job covering a representative date range, time how long creation, processing and download take, then multiply by the number of jobs in your full range. Ask Portkey whether it can give expected processing times for your account size, and build in slack for failed jobs and re-downloads.
What drives the cost of exporting Portkey logs?
The main costs are staff time, storage and the work of verification. Staff time covers scripting, running jobs, monitoring and reconciling counts. Storage covers the JSONL files for the retention period you need, plus the access controls that protect any prompt or response content in them. Verification covers the checks that prove the export is complete. Costs go up with more logs, more jobs, larger payloads and longer retention, and go down when you export fewer fields that you do not need. Portkey's Enterprise contract is a separate, recurring cost that the export itself does not change. When requesting a quote, ask for a written scope covering job count assumptions, field list, storage location, verification method and handover.
Does the export expose sensitive prompts and responses?
It can. Portkey's documented fields include request and response payloads, metadata and the prompt slug, so the JSONL files may contain user content and personal data. Treat every export as sensitive data from the moment it is downloaded. Restrict who can read the files, encrypt them at rest, set a retention period that matches your policy, and log access. Check whether any payload fields contain personal data before you move files to a shared bucket or a third-party tool. If you use a self-hosted replacement gateway, store the exported history in the same controlled environment so you do not create a new copy outside your boundary.
What should we confirm with Portkey before starting?
Confirm five points in writing. First, that your plan includes the logs export and, for self-hosted Enterprise, that the Data Service is enabled. Second, the exact field list available to your account. Third, the current per-job limit, which Portkey's documentation gives as 50,000 logs. Fourth, the retention window for logs in your account, since older history may not be reachable. Fifth, the expected behavior of signed download URLs, including how long they stay valid. Writing these answers down before you script anything prevents rework and gives your verification owner a baseline to test against.
What still needs replacing once the historical logs are safe
An exported JSONL file preserves your history, but it does not replace a live gateway. Once the logs are in your own storage, applications still send every request to Portkey, keys and budgets still live in Portkey, and new traffic still produces logs there. Treat the export as the close of the archive step, and plan the cutover of the gateway as a separate piece of work. The sibling topic on moving from Portkey to LiteLLM covers mapping virtual keys, budgets, routing configs and fallbacks, and cutting over applications that already call an OpenAI-compatible endpoint. The sibling topic on moving from Portkey Cloud to the open-source Portkey Gateway covers which features carry over when you keep Portkey's routing format.
Logging is the step most likely to be missed. Once traffic moves, something must write new request records, and the new log store must accept the exported fields (trace ID, timestamps, provider and model, token counts, cost, response time, status code, config ID, prompt slug and metadata) or your dashboards and cost reports will show gaps at the cutover date. Check the field names and types in your target store, such as Langfuse or an OpenTelemetry pipeline, against a sample export before you switch. Confirm which Portkey fields have no direct equivalent so you can decide whether to rebuild them or accept a break in the series. The sibling topics on replacing hosted logs and on comparing logging destinations describe those choices in more detail.
How DeployOpen scopes and delivers a Portkey data export and exit
DeployOpen plans and delivers the export of Portkey gateway logs as a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before work starts. The work covers pulling history out of Portkey, checking it, and handing it over in a form your team can keep and query.
How we scope
- Confirm whether your Portkey plan includes logs export and whether a self-hosted Enterprise Data Service is required.
- List the log fields to export, such as trace ID, timestamps, provider, model, token counts, cost and config ID.
- Agree the time window and the expected number of logs, since each export job is capped at 50,000 logs.
How we build
- Script the asynchronous export flow: create the job, start it, poll its status, then download from the signed URL.
- Split large histories into multiple jobs within the per-job cap and track each file in a manifest.
- Validate JSONL output against record counts and sample entries before any source data is changed.
How we hand over
- Deliver the exported JSONL files and a runbook describing the export steps, field mapping and checks performed.
- Document where the archive is stored inside your own infrastructure and who holds access to it.
- Provide a reconciliation report showing job IDs, record counts and any gaps for your records owners to review.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the handover.
- Confirm with your compliance team which retention and access rules apply to the archived logs.
- Keep the export scripts available for re-runs if a later gap or audit request needs additional history.
