script events

Q Does this script's own write reach the event log, and what does one write put there?

Endpoint POST /entity/shots ; PUT /entity/shots/<id> ; DELETE /entity/shots/<id> ; POST /entity/event_log_entries/_search

Docs claim The REST reference does not mention generate_event_log_entries, and documents EventLogEntry as an ordinary entity type. Nothing in the REST surface says a script's own writes can be absent from the log.

Actual

GET /schema/ApiUser/fields/generate_event_log_entries -> 200   default_value False
POST /entity/api_users/_search on its own name        -> 200   generate_event_log_entries=True
PUT /entity/api_users/<own id> {"generate_event_log_entries": True} -> 200   a script can set its own

create: POST /entity/shots, 4 keys sent -> 6 rows, first visible after 0.4s
  Shotgun_Shot_Change  attribute='description'             in_create=True  None -> 'probe 049'
  Shotgun_Shot_Change  attribute='sg_shot_type'            in_create=True  None -> 'VFX'
  Shotgun_Shot_Change  attribute='sg_status_list'          in_create=True  None -> 'wtg'
  Shotgun_Shot_Change  attribute='sg_latest_vendor_status' in_create=True  None -> 'wtg'
  Shotgun_Shot_Change  attribute='code'                    in_create=True  None -> 'zzprobe_049_shot'
  Shotgun_Shot_New     attribute=None   meta.type='new_entity'
  every row: user=<script> 1.0 /ApiUser, session_uuid=None, entity=Shot:<id>

update: PUT sg_status_list 'wtg' -> 'ip'  -> 1 row after 0.3s
delete: DELETE                            -> 2 rows
  Shotgun_Shot_Retirement  meta.type='entity_retirement'
    meta keys: class_name, display_name, entity_id, entity_type, id, retirement_date, type
  Shotgun_Shot_Change      attribute='retirement_date'  None -> '2026-09-04 17:42:34 UTC'

filtering on entity after the delete -> 0 rows (was 7); found by meta.entity_id -> 9
total for one create + one update + one delete: 9 events

Teaches

• generate_event_log_entries on the ApiUser gates the whole feed, and its default is False. While it is off the write still answers 201, the log stays empty, and any webhook scoped to that change has nothing to fire on. Nothing errors, so a client cannot detect it from the response. Read the flag before concluding the API does not log an operation.
• A script can read and set its own flag. PUT /entity/api_users/<own id> with {"generate_event_log_entries": true} answers 200. Turning it on is a one-call fix; it also means a compromised script key can switch its own audit trail off.
• One create costs one row per populated field plus one _New. Four keys sent produced five Shotgun_<Type>_Change rows, because server-set defaults are logged too, and each sets in_create: true. A consumer counting operations must not count events.
• Events are visible 0.3s to 0.4s after the call. There is no lag to design around at this size.
• session_uuid is null on every row this script generated, and set on the rows the web interface generated. It does not group a script's calls into a session.
• A delete logs two rows and orphans all the others in the same instant. Shotgun_<Type>_Retirement puts retirement_date and display_name in meta, and every earlier row for that entity drops its entity link at once, so the history is reachable only through meta.entity_id, which is unfilterable (probe 025). Capture the id before deleting or lose the trail.

Python equivalent

# probe 049: is this script even logging? check before trusting an empty feed
me = sg.find_one("ApiUser", [["firstname", "is", SCRIPT_NAME]], ["generate_event_log_entries"])
if not me["generate_event_log_entries"]:
    sg.update("ApiUser", me["id"], {"generate_event_log_entries": True})