Skip to main content
Writing is currently supported for the employee, time_report, salary_transaction, competence, employee_competence and file_transfer domains.
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 for the full flow.