> ## 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)

**1. 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](/unified-apis/guides/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).

**2. 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.

**3. 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.

## Updating resources (PATCH)

**1. 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.

**2. 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.

**3. 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.

> [!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`](/unified-apis/accounting/concepts/journal-entry/vat)). Check the connector's coverage page before relying on a field being mutable.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.