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

# Good practice - Create and Update requests

Chift's unified API exposes two verbs for writes: **POST** to create a resource, and **PATCH** to update one. There is no PUT endpoint — updates are always partial, never a full replace.

## Creating resources (POST)

<Steps>
  <Step title="Always send an idempotency key">
    Include a unique `x-chift-client-requestid` header on every POST. If a network timeout or retry causes the same request to be sent twice, Chift returns `REQUEST_ALREADY_PROCESSED` instead of creating a duplicate.

    See [Idempotency](/developer-guides/advanced/idempotency) for the full mechanism, and use [Transaction Monitoring](/api-reference/endpoints/connections/get-transaction-information) to check the outcome of a request whose response you never received (e.g. after a client-side timeout).
  </Step>

  <Step title="Read the created_entity_id back">
    A successful POST returns the created resource. For long-running or asynchronous operations, the transaction monitoring endpoint also exposes `created_entity_id`, so you don't need a separate lookup to find what was created.
  </Step>

  <Step title="Expect connector-specific rejections">
    The same payload can be valid for one target system and invalid for another (e.g. a required tax field, an account that must pre-exist). Treat validation errors as expected, not exceptional, and surface `error_code` + `detail` to your own users rather than a generic failure.
  </Step>
</Steps>

## Updating resources (PATCH)

<Steps>
  <Step title="Send only the fields you're changing">
    PATCH bodies are partial by design — every field is optional. Only include the fields you actually want to modify; omitted fields are left untouched on the target system.

    Do **not** re-send a full resource read back from a GET as your PATCH body. If the resource has fields you didn't set yourself (defaults, computed values, connector-specific extras), re-submitting them can overwrite state you didn't intend to touch.
  </Step>

  <Step title="Don't use PATCH for read-modify-write increments">
    If a field represents a running total or counter, fetch the current value and PATCH the new absolute value — don't assume the API will "add" to it. PATCH sets fields; it doesn't apply deltas.
  </Step>

  <Step title="Apply the same idempotency key discipline">
    The `x-chift-client-requestid` header works the same way on PATCH as on POST — use it when a retry must not risk being applied twice.
  </Step>
</Steps>

<Warning>
  **PATCH is per-connector, not per-field-universal**

  A field accepted by one connector's PATCH schema may be silently ignored by another if the target software doesn't support updating it after creation (this is the same pattern as `vat_account` in [`tax_info`](/developer-guides/api-guides/accounting/vat-on-journal-entry-lines)). Check the connector's coverage page before relying on a field being mutable.
</Warning>