# Upload your knowledge base
Neo.Tax can ingest your internal knowledge base—engineering wikis, design docs, technical blog posts—to strengthen the documentation behind your engagement.
Neo.Tax can ingest your internal knowledge base—engineering wikis, design docs, technical blog posts—to strengthen the documentation behind your engagement. The fastest path is our direct API integration, which connects to platforms like Confluence, Notion, and SharePoint. If a direct connection isn't an option in your environment (for example, due to network or security policy), you can provide the same data as a file export instead. This guide describes the file format we accept.
### What to include
Export the knowledge base folders (also known as spaces, sections, or workspaces, depending on your platform) that are relevant to your engagement with Neo.Tax. Your account team can confirm the list with you.
- Include articles with a status of `PUBLISHED`. You may also include `ARCHIVED` articles if they document relevant past work.
- You don't need to filter out anything else: rows with a status of `DRAFT` or `TRASH` are ignored at ingestion, as are link-stub article types.
### File format
We accept a **CSV file (UTF-8 encoded)** with **one row per article**. A few rules to keep the file valid:
- Use standard CSV quoting (RFC 4180): wrap any field containing commas, quotes, or line breaks in double quotes, and escape embedded double quotes by doubling them (`""`). Article content almost always contains all three, so make sure your export library handles quoting—most standard CSV writers do this automatically.
- Include a header row using the exact column names below. Column order doesn't matter.
- Avoid opening and re-saving the file in Excel before sending it—Excel can silently alter encodings, dates, and long text fields.
- We also accept the same fields as JSONL (one JSON object per line) if that's easier for your team to produce.
### Required columns
| Column | Type | Description |
| --- | --- | --- |
| `article_id` | string | The article's unique ID in your source system. Used to match articles across re-uploads, so it must be stable. |
| `title` | string | The article's title. |
| `content` | string | The article body. HTML is preferred; plain text is also accepted. |
| `author_email` | string | Email address of the article's original author. |
| `status` | string | One of `DRAFT`, `PUBLISHED`, `ARCHIVED`, `TRASH` (case-insensitive). Only `PUBLISHED` and `ARCHIVED` articles are processed. |
| `type` | string | One of `PAGE`, `BLOG_POST` (case-insensitive). |
| `created_at` | datetime | When the article was created in your source system, in ISO 8601 format (e.g. `2025-06-02T14:05:00Z`). |
| `updated_at` | datetime | When the article was last updated, in ISO 8601 format. |
| `url` | string | Link to the article in your source system. Used for provenance and audit trail. |
| `folder_id` | string | The folder (space, section, or workspace) the article belongs to. This is how articles are grouped, so use a consistent identifier per folder. |
### Optional columns
These columns are **truly optional**—leave them out entirely, or leave individual values blank, and your file will process fine.
| Column | Type | Description |
| --- | --- | --- |
| `parent_article_id` | string | The `article_id` of the article this one is nested under, if your knowledge base is hierarchical. |
| `last_edited_by_email` | string | Email address of the most recent editor. |
| `description` | string | A short summary or excerpt of the article. |
| `visibility` | string | One of `PUBLIC`, `INTERNAL`, `RESTRICTED`. |
### Notes on article content
- Provide the **rendered** article body (what a reader sees), not your platform's internal storage markup, which can contain unexpanded macros.
- Embedded images and attachments are not processed—ingestion uses the article text. Image references left in the HTML as URLs pointing back to your instance are fine; we simply don't fetch them.
### Example
A minimal file looks like this (content abbreviated for readability):
```javascript
article_id,title,content,author_email,status,type,created_at,updated_at,url,folder_id
98304,"Motion Planning Service — Architecture Overview","Motion Planning Service
This page describes…
",jane.doe@acmerobotics.example,PUBLISHED,PAGE,2024-03-11T09:42:00Z,2025-06-02T14:05:00Z,https://acmerobotics.example/wiki/spaces/ENG/pages/98304,ENG
102211,"Q2 Firmware Release Retrospective","Q2 Firmware Release Retrospective
Summary of what shipped…
",sam.lee@acmerobotics.example,PUBLISHED,BLOG_POST,2025-07-01T16:20:00Z,2025-07-03T10:11:00Z,https://acmerobotics.example/wiki/spaces/FW/blog/102211,FW
```
Download the template below to start from a working file with all columns included:
[neotax-kb-export-template.csv](https://vaffozzswoq4jjsz.public.blob.vercel-storage.com/help-center/0e5ae1df-b646-4962-a618-119e4c5a12a3/knowledge-base-1.csv)
### Exporting from Confluence
If your knowledge base is Atlassian Confluence, the Confluence REST API provides everything the schema needs. The mapping below uses Confluence Cloud's v2 API (`GET /wiki/api/v2/pages` and `GET /wiki/api/v2/blogposts`, requesting the body with `body-format=export_view`).
| Neo.Tax column | Confluence API field |
| --- | --- |
| `article_id` | `id` |
| `title` | `title` |
| `content` | `body.export_view.value` |
| `author_email` | `authorId`, resolved to an email via the Users API |
| `status` | `status` (`current` → `PUBLISHED`, `draft` → `DRAFT`, `archived` → `ARCHIVED`, `trashed` → `TRASH`) |
| `type` | `PAGE` for pages, `BLOG_POST` for blog posts |
| `created_at` | `createdAt` |
| `updated_at` | `version.createdAt` |
| `url` | `_links.webui`, prefixed with your site's base URL |
| `folder_id` | the space **key** (resolve `spaceId` via `GET /wiki/api/v2/spaces`) |
| `parent_article_id` | `parentId` |
| `last_edited_by_email` | `version.authorId`, resolved via the Users API |
On **Confluence Data Center / Server**, the equivalent endpoint is `GET /rest/api/content?expand=body.export_view,history,version,space`, and the same fields are available under slightly different paths (`history.createdBy` for the author, `space.key` for the folder).
See Atlassian's documentation for details: [Confluence Cloud REST API v2](https://developer.atlassian.com/cloud/confluence/rest/v2/intro/) · [Confluence Data Center REST API](https://developer.atlassian.com/server/confluence/rest/).
### Sending your file to Neo.Tax
Share the file with your Neo.Tax account team through the secure file-transfer channel established for your engagement. If a channel hasn't been set up yet, your account team will arrange one with you.
If a single file is very large (over ~1 GB), split the export into multiple files—one file per folder works well. All files should use the same schema. We suggest naming files `neotax-kb-export-{folder}-{YYYYMMDD}.csv` so re-uploads are easy to tell apart, but any naming is fine.
### Updating your data
If you send an updated export later, include **all** articles, not just the ones that changed. Each file is treated as a full snapshot of the exported folders: existing articles are updated in place by `article_id`, and new articles are added. Articles missing from a later file are not deleted.
Your account team will confirm the refresh cadence that makes sense for your engagement — for most engagements this is once or twice per cycle, not a continuous sync.
### What we do with this data
Knowledge base data you share with us is used solely to prepare the deliverables for your engagement. Access is restricted to the team working on your account, the data is never shared with third parties, and it is retained and deleted according to the data-handling terms of your engagement agreement. If you have questions about data handling, your account team can walk you through the specifics.