> ## Documentation Index
> Fetch the complete documentation index at: https://docs.twine.se/llms.txt
> Use this file to discover all available pages before exploring further.

# Pushing data

> Considerations when writing data through the Twine Public API

<Note>
  Writing is currently supported for the `employee`, `time_report`, `salary_transaction`,
  `competence`, `employee_competence` and `file_transfer` domains.
</Note>

There are several considerations to take into account when writing data to the API:

* To write data, the role being used must have the `create` and/or `update` permissions for the domain you are writing to.
* Following RESTful conventions, `POST` creates new resources, `PUT` updates existing resources, and `PATCH` partially updates existing resources.
* Although `PATCH` does not touch unspecified dated properties, it still replaces **all** entries of the targeted dated properties with the values provided in the request body. To keep existing historical values for a given dated property, include them in the request body. This behavior may change in the future given enough demand.
* If there are incoming domain mappings for the domain you are writing to, avoid updating any properties that are mapped in those integrations. Otherwise it becomes ambiguous which integration is responsible for the data.
* If there is a configured `twine` integration with outgoing domain mappings for that domain, a replication job is created by default to push the changes to the configured integration.
  * For `employee`, suppress replication by adding a condition in the target integration.
  * For `time_report`, control replication per request through `job_options` on create and update (or the equivalent query parameters on delete) — for example, set `queue_job` to `false` to skip it, or scope it with `domain_mapping_id`, `schedule_in`, and `date_range`. See the Time Report endpoints for details.

## Uploading files

Files are written differently from the other domains, because the thing being written is not a record but a document.

* Send the file base64 encoded in `content_base64`. The decoded file may be at most 5 MB.
* Name the destination with `system_integration_id`. The file travels through a file transfer domain mapping that has Twine on the source side, so one must exist for that destination.
* Delivery is asynchronous. The response returns immediately with `status` `pending`; poll the file transfer until it becomes `delivered`, then read `remote_id` for the destination system's identifier for the document.
* Unlike the other write endpoints, `schedule_in` defaults to `0` rather than `60`, since callers are normally waiting on that identifier.
* Twine does not retain the file. The record of the transfer and the destination's identifier are kept indefinitely; the file itself is removed shortly after delivery.

See [File Transfers](/platform/other/file-transfers) for the full flow.