}
{caption && !thumbnail && {caption}{src && Select the image to view it full size.}}
;
};
Moving information into Kato starts with a decision: what does your team need to
work on here? Choose a useful starting set, such as active clients or current
projects, and give it a clear home before adding more.
## Choose how to add data
| Route | Good for | Where to begin |
| ---------------------- | ---------------------------------------------- | ------------------------------------------------------------------------- |
| Create records by hand | A few clients, projects, or other items | Open an object and choose **New** followed by its record name. |
| Import Timely projects | Projects from a connected Timely account | Open Projects, then **Import / Export → Import from Timely**. |
| Use the API | A custom migration or repeatable external sync | Follow the [objects and records API](/api-reference/objects-and-records). |
Kato does not currently offer a general CSV upload flow. If your source is a
spreadsheet, use it to prepare the data for manual entry or an API migration.
The **Import / Export** menu includes CSV export of the current view.
## Prepare a small sample
1. Choose the destination [object](/documentation/data/objects).
2. Match each source column to a Kato [attribute](/documentation/data/attributes).
3. Check names, dates, select options, and required values for consistency.
4. Identify records that already exist so you can avoid adding them twice.
5. Try a handful of records and check their values before continuing.
For example, an active-project spreadsheet might contain a project name, status,
and target date. Decide which attributes hold those details before moving the rows.
## Example: map a spreadsheet before moving it
Suppose the source has these columns. Build or inspect the destination attributes
before entering records or asking a developer to migrate them.
| Source column | Kato destination | Preparation |
| ------------- | ---------------------------------------- | -------------------------------------------------------------------------- |
| Project | A writable name/text attribute | Use a recognizable name and check for existing projects. |
| Stage | A Select attribute | Normalize values such as “In flight” and “Active” into agreed choices. |
| Deadline | A Date attribute | Resolve ambiguous dates such as 04/05 before moving them. |
| Client | A relationship to a client record | Identify the corresponding client record; a text name alone is not a link. |
| Source ID | Your migration's stable identity mapping | Keep the same mapping when updating the item again. |
Use a sample that includes a normal row, one missing an optional value, and one
with an existing client. These reveal different problems than testing three
perfect, unrelated rows.
## Check the sample before the full transfer
Open each sample record and compare it with the source. Check the status option,
date, client link, and any required fields. Then view it through the same table
or board the team will use. A successful API response alone does not prove that
the resulting structure is useful to readers.
For a repeated API sync, run the same sample twice using the intended stable-ID
strategy. Confirm it updates the intended records instead of creating a second
set. Keep a record of source IDs and Kato IDs so failures can be investigated.
If rows fail, separate formatting problems from access or schema problems.
Correct a value that does not match the field's type; inspect permissions or
field definitions when the destination itself is unavailable. Avoid retrying a
whole batch blindly when only a few records need correction.
## Import from Timely
The Timely import option appears for the Projects object when Timely is connected.
The dialog lists projects and marks those already imported. Review the selection,
choose the projects to bring over, and select **Import**. Associated clients are
created and linked as part of this flow.
Read the results after the import. If any projects report an error, inspect those
results before retrying. Open a created project to confirm that its details and
client link match what you expected.
## Plan an API migration
Have the person building the migration inspect your workspace's object and field
definitions first. Use a stable record ID for repeated updates, and test how missing
or invalid values are handled. The [record sync recipe](/recipes/sync-client-records)
explains the approach.
## Continue learning
Understand the structure behind the records you add.
## Related topics
- [Recipes](/recipes/overview.md)
- [Start with Kato](/introduction.md)
- [Introduction](/documentation/introduction.md)
- [Raycast](/integrations/raycast.md)
- [Changelog](/changelog.md)
: