How to export your data from ThreatConnect before the contract ends
If a renewal, a price change, a residency requirement or an exit decision has put a deadline on your ThreatConnect contract, start by treating the export as a project with a written inventory. Data leaves ThreatConnect through its documented v2 and v3 REST APIs, paged and filtered, and only for the owners your account is permitted to read. The v2 API covers threat intelligence data, custom metrics, notifications and Playbooks, while the v3 API covers case management and increasingly the intelligence features of v2. The ThreatConnect REST API quick start is the starting point for authentication and request structure.
Results are paged with resultStart and resultLimit, can be sorted, and v3 requests can be narrowed with the tql parameter using ThreatConnect Query Language. Two defaults will affect completeness. The /v3/indicators endpoint returns only active indicators unless you change that behavior, and associated groups and tags appear only when you request them through the fields parameter. The owner parameter reaches indicators held in a Community or Source rather than your Organization, so a plain query can silently return less than you hold. Ask your ThreatConnect contact which owners, sources and communities your account can read, and which are covered by the sharing agreements you signed, before you script the pull.
The public documentation does not settle every question an exit depends on, including the full set of objects exposed for export, how cases and their attachments are returned, rate limits on large pulls and whether historical or inactive records are retrievable. Confirm these in your own tenant with a test export of a known sample, then compare record counts against the platform's view before you rely on the output. Keep the export logs and checksums, since they become the evidence for any migration to OpenCTI or MISP and for any later audit of what left the platform.
Which ThreatConnect data the documented APIs can export
This table maps each ThreatConnect data type to the API path or version that serves it, the export method, the response format and the controls that limit what you receive. Read the limits column before writing a script, because the default indicator response returns only active indicators and several limits must be confirmed for your tenant.
| Data type | API path or version | Export method | Limits and controls |
|---|---|---|---|
| Indicators | GET /v3/indicators | Paged JSON requests using resultStart and resultLimit, with optional sorting | Returns only active indicators by default. The fields parameter adds associated groups and tags. The owner parameter targets Communities or Sources rather than your Organization. |
| Indicator filtering | GET /v3/indicators with the tql parameter | ThreatConnect Query Language filter applied server side before paging | Narrows results by attributes such as type or owner. Confirm the supported TQL fields and operators in the REST API reference for your tenant. |
| Threat intelligence objects and groups | v2 API (v3 covers more of these over time) | Paged JSON requests through the v2 endpoints for groups and threat intelligence data | Check in your tenant which group types and fields are exposed by v3 before you build against it. Confirm the paging maximum and rate limits in the REST API reference. |
| Cases | v3 API (case management) | Paged JSON requests against the v3 case endpoints, with tql filtering where supported | Confirm which case fields, tasks and artifacts are returned by default and which need extra parameters. Confirm the maximum page size. |
| Owners (Organization, Communities, Sources) | Owner parameter on v3 requests | Separate requests per owner, run under an account that holds access to each owner | You can only export owners your credentials can read. Confirm sharing permissions for each Community or Source with your ThreatConnect administrator. |
| Export file formats | Not defined by the documented API pages supplied | JSON responses from the REST API; bulk file exports depend on your tenant | Confirm with ThreatConnect whether bulk file exports or other formats are available for your plan, and whether they cover all data types above. |
How paging, TQL filters and extra fields shape a complete pull
A complete export depends on walking the full result set, and that starts with paging. ThreatConnect returns results in pages controlled by the resultStart and resultLimit query parameters. Your script should request one page, read the returned count, advance resultStart by the number of records received, and stop only when a page comes back short or empty. Do not assume a fixed total. Record the count of each run and compare it with the number your ThreatConnect console reports for the same filter, so you can spot a silent gap early. Sorting matters here too. If records change while you page, an unsorted result set can shift between requests and cause some indicators to appear twice and others to be skipped. Sort on a stable field, such as the record ID, before you start, and confirm in the API documentation which sort fields your tenant accepts.
Filters decide what the pull covers, and they are where most export errors start. On v3 endpoints, the tql parameter accepts ThreatConnect Query Language, which lets you narrow a request by date, indicator type or status. Write the filter once, store it with the export job, and log the exact string used, because an export you cannot reproduce is hard to defend during a migration review. Two defaults need explicit attention. GET /v3/indicators returns only active indicators unless you ask otherwise, so an export that omits an inactive-status filter will silently leave out retired indicators that your SIEM or blocking rules may still reference. Decide with your threat intelligence owner whether inactive records belong in the target platform, then add a filter that includes them and check the counts for active and inactive records separately. Also confirm the owner parameter for each Community or Source you intend to export, since the default targets your own Organization.
The fields parameter controls what each record carries. Without it, an indicator record may come back with its core attributes but without the associated groups and tags that give it context. A pull that omits these fields keeps the indicator value and loses the relationships that make it useful: which report or campaign it belongs to, which tags drive its classification, and which owner shared it. Those relationships are hard to rebuild later from the indicator list alone. Before running a full export, request a small sample with the fields you need, open the JSON, and confirm that group associations and tags are present. Keep the sample as a fixture for your import tests. Then run the full pull with the same field list, so every batch has the same shape.
What the documented APIs do not export, and the workarounds
The v2 and v3 REST APIs cover indicators, groups and cases well, but several kinds of account data sit outside the documented export paths. Each gap below needs a confirmed answer from ThreatConnect before migration planning, plus a substitute you can build in your own environment.
Playbook definitions and run history
Playbooks are the automation layer that moves indicators through enrichment, tasking and notification in ThreatConnect. The documented indicator and case endpoints return the objects those playbooks act on, not the playbook logic or the record of past runs. Ask ThreatConnect whether playbook exports exist in your edition. Until you know, document each playbook manually: trigger, inputs, decision branches, external calls and owners. Keep that document with the migration plan so the replacement automation has a written specification to match.
Custom metrics and notification settings
Custom metrics and notification rules tell you what the team watches and who gets alerted when it changes. The v2 API covers custom metrics and notifications as features, but the supplied documentation does not show a clear export of their configuration. Confirm with ThreatConnect which settings can be read through the API and which need a screen capture or an admin export. Record thresholds, recipients and delivery channels in a spreadsheet, then rebuild them as MISP feeds, OpenCTI notifications or your alerting tool, and test each one against a known sample.
User accounts and role assignments
Accounts, roles and group memberships control who can read, edit and share each owner's data. These records are rarely the same as the data itself, and the documented indicator and group endpoints do not return the full permission model. Ask ThreatConnect what an administrator can export for users and roles, and whether SSO group mappings travel with the account. In the target platform, recreate the roles from a written matrix of who needs which owner, which sharing level and which edit rights. Keep identity in your own directory so access is revoked in one place.
Audit and activity logs
Audit logs record who changed an indicator, who viewed a case and when a playbook ran. For regulated teams they often serve as evidence in investigations and assessments, and the documented APIs do not present them as an export. Confirm with ThreatConnect whether audit history is available, for how long and in what format. Regardless of the answer, start forwarding your own copy to an external log archive now, using the platform's logging or a SIEM, so that history before the cutover remains available after it. Set retention to match your records policy.
Inactive indicators and unreadable owners
GET /v3/indicators returns only active indicators by default, so expired or inactive records are silently left out of a naive export. The owner parameter also reaches Communities and Sources, but only where your account has read access. Records in owners your account cannot read will not appear, and they will not show an error. Before exporting, request inactive indicators explicitly, and compare counts per owner against the platform interface. List every Community and Source your team depends on, confirm read access for each, and record gaps as open items in the migration plan.
The export sequence, from owner inventory to verified copy
This sequence moves ThreatConnect indicators, groups and cases into a copy you can prove is complete and accurate. Each step produces a checkable output, so the export can be repeated, audited and handed to a migration team without relying on memory of how it was run.
Inventory the owners your API account can read
The export starts with a list of every owner the API account can see: your Organization, any Communities and any Sources it has access to. Ask the ThreatConnect administrator to confirm which owners the account is permitted to read, because access is set per account and not every owner is visible to every user. Record each owner's name and ID in a spreadsheet, along with the record types you expect to find in it. The step is done when you have a written owner list that the platform administrator has reviewed and signed off.
Define scope with TQL filters and inactive records
For each owner and record type, write down the scope of the export as a TQL filter where the endpoint supports one. Remember that GET /v3/indicators returns only active indicators by default, so inactive indicators must be requested explicitly if they are in scope for your migration or retention needs. Confirm with your records or compliance owner whether inactive and expired items must be kept. The step is complete when each owner and record type has a documented filter and a statement about inactive records.
Run a small test pull and inspect fields
Run a test request with a low resultLimit against one owner and one record type, using the same filter you defined in the previous step. Inspect the returned fields carefully, and request the fields parameter for associated groups and tags so you can see whether they arrive in the response. Note any field that is missing, empty or formatted differently from what your target platform expects. The output is a short test report that lists the fields you will keep, the fields you need extra requests for, and any surprises in the data.
Run the full paged pull with page logging
Run the full export using resultStart and resultLimit to page through each owner and record type in turn. Sort results consistently so that paging does not skip or repeat records between requests. Log every page with the request URL, the timestamp, the number of records returned and the highest identifier seen, so a failed or interrupted run can be resumed from a known position. The step is done when each owner and record type reaches the end of its pages and the log shows no gaps.
Verify counts per owner and type
Compare the number of records you exported for each owner and record type with the counts shown in the ThreatConnect interface for the same filter. Investigate any difference before going further, and note whether it comes from inactive records, owner access, or filters that do not match the view. Ask your ThreatConnect administrator to confirm the platform-side counts if your account cannot see them directly. The output is a count reconciliation table that is signed off for each owner and type.
Compare sampled records field by field
Select a sample of records from each owner and record type, weighted toward items that have many associations or tags, and compare them field by field against the platform view. Pay particular attention to associations to groups, tags, dates, and ownership fields, because these are the fields most likely to be lost or flattened in an export. Record each mismatch and its cause. The step is done when every sampled mismatch is explained or fixed and re-exported.
Store the raw export with hashes and a manifest
Store the raw response files exactly as received, without transformation, in a restricted location controlled by your organization. Generate a cryptographic hash for each file and write a manifest that lists the file names, hashes, owners, record types, filters, record counts and export timestamps. Keep the manifest with the page log so the export can be validated later. The output is a verifiable archive that another person can check without access to the original API account.
Repeat the pull before cutover
Shortly before the cutover to the new platform, repeat the full export using the same filters, owners and verification steps, and compare the new manifest with the previous one. The difference shows which indicators, groups and cases changed while the migration was being prepared. Confirm with the migration team which changes must be carried over and which can be ignored. The step is done when the final manifest is archived and the migration team has accepted it as the source of record.
Which owners you can export, and how each one is reached
Your Organization is the default scope for indicator requests against the ThreatConnect REST API. When you call GET /v3/indicators without an owner parameter, the results come from the organization tied to your API credentials. This is the scope most teams start with, and it is the one your own administrators can usually approve without involving a third party.
- Default scope: Requests without the owner parameter return data held by your organization, so the first export test should confirm which owner the results actually come from.
- Active only by default: GET /v3/indicators returns only active indicators unless the request is changed, so inactive or expired records need an explicit query before you count them as exported.
- Account role: Ask the platform administrator which role the API user holds, because the role determines whether reads of groups, indicators and associations are permitted within your organization.
- Extra fields: Associated groups and tags are only returned when the fields parameter asks for them, so request them explicitly if the destination needs them.
- Internal approval: Your own data governance owner usually approves exporting organization data, but confirm whether internal classification rules restrict copies outside the platform.
Before you start, check the role and the owner scope on a small sample so you know exactly what the export contains.
Communities are shared spaces where several organizations exchange intelligence. You reach community content by setting the owner parameter on requests, and your account can only read communities it belongs to. Membership is granted by the community itself, so access depends on the community's own approval process rather than on your organization's settings.
- Membership first: Confirm with the community owner that your account is a member and that the membership covers read access to the data you want.
- Owner parameter: Target a community explicitly with the owner parameter, because community data is not included in a default organization request.
- Sharing agreements: Review the trust terms or sharing agreement for each community, since they may prohibit re-sharing, export to third parties or storage outside specified systems.
- Attribution and handling: Some communities require that exported indicators keep their source and handling markings, so check whether your destination platform can preserve them.
- Who approves: Your legal or information sharing lead should sign off, and the community administrator should confirm in writing that the export is allowed.
If a community agreement does not clearly permit export, treat the data as restricted until the community confirms otherwise.
Sources are external feeds or data providers whose indicators are ingested into ThreatConnect. Like communities, a source is reached through the owner parameter, and your account only sees the sources that have been granted to it. The license or subscription with the feed provider often controls what can be stored, redistributed or exported, which can be more restrictive than the platform permissions.
- Grant-based access: Your account sees only the sources explicitly granted to it, so ask the platform administrator for the list of granted sources before you request data.
- Owner parameter: Use the owner parameter with the source identifier when you need indicators from a feed rather than your organization.
- Feed licensing: Read the terms of each commercial or open feed, because many forbid redistribution even when the platform lets you read the data.
- Account role: Confirm the role that the API user holds on the source, since read access may be separate from the access that the organization has.
- Who approves: The source owner or your procurement and legal team usually approves, and the feed agreement should be checked before any export leaves the environment.
Confirm the feed terms before exporting, because a technically successful request can still breach a license.
What to plan before renewal or termination
Exporting from ThreatConnect is only as complete as the access and agreements around it. The cards below cover the decisions and documents to settle with ThreatConnect and your own team before the subscription ends, so the copy you take out is complete and provably so.
Confirm the export window
Ask ThreatConnect in writing how long your organization keeps read access after notice is given, and which tenant, owners and API endpoints remain available during that period. Record the answer as the export window that governs your plan. Also confirm whether the window differs for indicators held in your Organization and for content held in Communities or Sources, because access to shared owners is often granted separately. Keep the confirmation with the project file so it can be referenced if access changes.
Create a dedicated API account
Request a separate API user with documented read permissions for the owners you need, and do not reuse an analyst's personal credentials. Obtain the written list of permissions the account holds, then remove the account and its API keys once the export is verified. Keeping the account narrow makes the access trail for the export easy to audit and avoids leaving a standing credential behind after the contract ends.
Review data ownership and retention terms
Read the contract clauses on data ownership, export rights and retention, paying attention to content your organization received from communities or sources rather than created itself. Ask for the terms that apply to that shared content in writing, since the right to copy it out may be narrower than the right to copy your own indicators. Decide early which records you can migrate, which you can only reference, and which must stay in ThreatConnect under the agreed terms.
Agree handling of deleted and inactive records
Agree with ThreatConnect how deleted records, expired indicators and inactive items will be treated during the export. By default the v3 indicators endpoint returns only active indicators, so inactive records will not appear unless you request them. Obtain a written decision on whether inactive and deleted data will be made available, and in what form, so your copy reflects the history you need for audit and detection tuning.
Schedule a test export early
Run a full test export against a sample of owners, groups and cases well before the end date, using the same paging, filters and fields you will use in production. The test shows how long a complete run takes, where pagination or rate limits interfere, and whether associations and tags come through. Record the test results and the gaps found, so the production run is a repeat of a method you have already checked.
Record the completeness sign-off
Name the person who signs off that the copy is complete, and the evidence they will review, such as record counts per owner and type, checksums of exported files and a reconciliation of the sample against the source. Keep the signed record with the export manifest. Without a named approver and a written reconciliation, it becomes hard to show later that the data your detection and sharing processes depend on was fully transferred.
Questions buyers ask before exporting ThreatConnect data
What drives the effort of a ThreatConnect data export?
The effort depends on four things: how much data you hold, how many owners it sits under, how much custom metadata you need to carry across, and how many relationships between indicators, groups and cases have to be rebuilt in the target platform. Volume affects how many paged API calls you run and how long the extraction and validation take. Owners matter because indicators held in a Community or Source are only reachable when you have access to that owner, and each one needs its own confirmation. Custom fields and associations are the items most often missed, since a plain indicator list does not carry them unless you request the extra fields explicitly. Ask the team to inventory these four areas before any work starts, because that inventory is what turns a vague export into a scoped one.
Can an internal team export ThreatConnect data without outside help?
Yes, an internal team can usually do the export alone if it has engineers comfortable with REST APIs, paging, filter syntax and data transformation, and if it has confirmed permissions for every owner it needs. The harder part is verification rather than extraction. Someone has to check that counts match between ThreatConnect and the export, that inactive indicators were handled deliberately, and that associations and tags survived the move. Teams that run this once often underestimate the time spent on those checks and on coordinating access with other owners. A useful test is whether the team can name who approves access to each community or source and who will sign off on the result.
How long does a ThreatConnect export take?
The duration depends mainly on data volume and on how quickly owner access is confirmed, so no fixed timeline applies across environments. Extraction itself is often the shorter step when access is in place. Owner approvals, schema mapping decisions and validation rounds tend to take longer and are outside the export code. Ask for a written scope that lists the owners, object types, date ranges and fields in scope, along with the milestones and the points where your team must respond. A scope written this way makes timing comparable between proposals and shows where delays would come from.
What does the client need to provide for an export?
Before work starts, the client typically needs to provide:
- API credentials for the ThreatConnect environment, scoped to the owners being exported
- Written approvals from each community or source owner whose data will leave the platform
- A staging environment, either a non-production ThreatConnect instance or a test copy of the target platform, for dry runs
- A named business owner and a named technical owner who can sign off on counts, mappings and the final cut-over
Also confirm who is accountable for data handling during transfer, since the exported files contain threat intelligence that may be shared under agreements with other organizations. Missing any of these items usually stops the work at the point where it is most expensive to restart.
When does a team need a partner for a ThreatConnect export?
A partner is worth considering when owner access is unclear, when some data belongs to sharing communities whose terms you have not reviewed, or when the data has to be mapped into a second platform such as OpenCTI or MISP. Mapping is where most complexity sits, because ThreatConnect owners, tags and associations do not map one to one onto other data models. DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, and runs fixed-scope engagements where scope, deliverables and timelines are agreed in writing before work starts. A partner does not replace the owner approvals or sign-off your organization must give.
What should we ask for in a quote for a ThreatConnect export?
Ask for a quote that is built from a written scope rather than a flat headline figure. The quote should list the owners and object types in scope, the fields to be extracted including associations and tags, the target format and platform, the validation method and acceptance criteria, and the sign-offs required. It should separate one-time work, such as scripting, mapping and validation, from any recurring work, such as ongoing synchronization or support retainers. Also ask what is excluded, for example owner negotiations, target platform hosting or analyst retraining. DeployOpen does not publish a price list, so compare proposals on the scope and assumptions each one states.
Which ThreatConnect API settings change what gets exported?
Several settings change the result, so confirm them before trusting any export. Indicators returned by GET /v3/indicators are active only by default, so inactive indicators need an explicit decision. The fields parameter adds data such as associated groups and tags, and without it those items are missing from the output. The owner parameter targets indicators held in a Community or Source rather than your Organization, so each owner needs its own pass. Results are paged with resultStart and resultLimit, and filtering with ThreatConnect Query Language through the tql parameter should be tested on a small set first. Record the exact parameters used for each run so the counts can be reproduced during verification.
How DeployOpen scopes and delivers a ThreatConnect data export
DeployOpen approaches a ThreatConnect data export as a fixed-scope engagement inside your own environment. We agree in writing which owners, object types and fields are in scope, then build and verify the extraction so the exported data can be loaded into your chosen self-hosted platform.
How we scope
- Inventory which owners (your Organization, Communities and Sources) your API credentials can read before any export starts.
- Define which object types to export: indicators, groups and cases, with their associations and tags.
- Agree in writing how active and inactive indicators are handled, since the default v3 indicator call returns only active ones.
How we build
- Write paginated extraction scripts using resultStart and resultLimit so large datasets are pulled completely.
- Apply TQL filters through the tql parameter and add the fields parameter for associated groups and tags.
- Test each export against a sample owner and compare record counts with the ThreatConnect console before a full run.
How we hand over
- Deliver the extraction scripts, configuration and a run book stored in your own infrastructure.
- Provide a field mapping document showing how ThreatConnect owners, tags and associations map to the target format.
- Record the export results, gaps and owners that could not be read, so your team can confirm them independently.
How we support
- Engagements are fixed-scope, and any follow-up work is agreed in a separate written scope.
- Ongoing support, upgrades and re-runs of exports are available as a retainer.
- Confirm with ThreatConnect the API access levels and rate limits that apply to your account before the work begins.
