Einblick Docs

Resources that your key has write grants for can be modified with standard HTTP methods. Writes go through the same domain logic as the Einblick app — validation, slug handling, related-table updates, and permission checks all apply.

Method	Path	Success
`POST`	`/api/v1/{resource}`	`201` with the created record
`PATCH`	`/api/v1/{resource}/{record}`	`200` with the updated record
`DELETE`	`/api/v1/{resource}/{record}`	`200` with the final record state, or `204`

CMS resources use the same methods under /api/v1/cms/{collection}.

Request body

Writes use a JSON:API document so reads and writes feel like one API. The body must contain a data object whose type equals the resource slug; attributes carries the writable fields:

curl -X POST https://actions.einblick.xyz/api/v1/events \
  -H "Authorization: Bearer api_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "data": {
      "type": "events",
      "attributes": {
        "title": "Open House 2026",
        "startsAt": "2026-09-12T09:00:00.000Z"
      }
    }
  }'

Updating sends only the fields you want to change:

curl -X PATCH https://actions.einblick.xyz/api/v1/events/open-house-2026 \
  -H "Authorization: Bearer api_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "data": {
      "type": "events",
      "attributes": { "title": "Open House Vienna 2026" }
    }
  }'

If you include data.id on a PATCH, it must match the record identifier in the path. Deletes take no body:

curl -X DELETE https://actions.einblick.xyz/api/v1/events/open-house-2026 \
  -H "Authorization: Bearer api_YOUR_KEY"

Whether DELETE removes or archives a record depends on the resource — the response returns the resulting record state when one exists.

Writable fields

Only fields granted as writable to your key are accepted. The write schemas in GET /api/v1/schema (…WritableAttributes) list them per resource and action; meta.fields[].writable in read responses mirrors the same information. Unknown or non-writable fields are rejected with 422 Unprocessable Entity.

Idempotency

Retried writes can be deduplicated with an Idempotency-Key header:

curl -X POST https://actions.einblick.xyz/api/v1/events \
  -H "Authorization: Bearer api_YOUR_KEY" \
  -H "Idempotency-Key: 4f9d36c4-0a11-4c1e-9f68-2f0f1cdb6a55" \
  -H "Content-Type: application/json" \
  -d '{ "data": { "type": "events", "attributes": { "title": "Open House" } } }'

Use a fresh unique value (for example a UUID) per logical operation and reuse it for retries of that same operation.

Write errors

Status	Code	Meaning
`400`	`bad_request`	Malformed request syntax
`401`	`unauthorized`	Missing or invalid API key
`403`	`forbidden`	Key lacks the resource/action/field grant
`404`	`not_found`	Resource or record does not exist for this key
`405`	`method_not_allowed`	The resource does not support this action
`409`	`conflict`	The write conflicts with current state (e.g. duplicate slug)
`422`	`unprocessable_entity`	Valid JSON, invalid field values

Error responses use the standard error document.